PORTFÓLIO / PROCESSOS · OPERAÇÕES · COORDENAÇÃO
E quando todo mundo está fazendo a própria parte – e o processo continua parado?
A catraca parecia o problema.
Não era.
Tecnologia, nutrição, fornecedor, equipe técnica externa e processo interno tinham pedaços da resposta. O que faltava era organizar o espaço entre eles.
Quando esse espaço virou parte explícita do trabalho, a implantação conseguiu avançar.
02 / O PONTO DE PARTIDA
Organogramas dividem responsabilidades. Problemas reais nem sempre respeitam essa divisão.
Em uma operação hospitalar de grande porte, algumas entregas dependiam de áreas técnicas, fornecedores e lideranças que não respondiam diretamente entre si.
Cada parte tinha uma responsabilidade legítima.
O problema começava quando o resultado dependia do encaixe entre essas responsabilidades.
- Tecnologia
- Nutrição
- Fornecedor
- Equipe técnica externa
- Processo interno
O problema não estava dentro de uma área. Estava nas interfaces.
03 / O CONTEXTO
Em operações grandes, o organograma explica quem responde por cada parte. Não explica quem responde pelo espaço entre elas.
Em uma operação hospitalar de grande porte, eu trabalhava num contexto com áreas técnicas, lideranças, fornecedores, contratos e restrições institucionais que não obedeciam a uma linha simples de comando.
Alguns problemas podiam ser resolvidos dentro de uma área. Outros dependiam de gente que não respondia diretamente entre si.
Foi nesse tipo de ambiente que comecei a perceber uma diferença importante entre responsabilidade formal e responsabilidade pelo resultado.
Quanto mais o problema atravessava fronteiras, menos útil era perguntar apenas: “de quem é isso?”
04 / A CENA
A catraca parecia ser o problema.
Havia uma implantação ligada ao refeitório que estava travada havia bastante tempo.
O equipamento era a parte visível. Por isso, era fácil tratar o caso como se fosse um problema técnico.
Só que a catraca não decidia nada sozinha.
O objeto estava na frente de todo mundo. O problema estava nas relações entre quem precisava fazê-lo funcionar.
05 / O PROBLEMA REAL
Cada área tinha uma parte da resposta. Ninguém tinha a resposta inteira.
Tecnologia precisava conversar com tecnologia externa. Nutrição precisava validar a operação. O fornecedor dependia de definições internas. Testes precisavam acontecer numa sequência coerente.
Não faltava necessariamente competência dentro das áreas.
Faltava coordenação entre as dependências.
integração e validação técnica
regra de uso e funcionamento
dependências e testes
sequência e aceite
Alguns processos ficam parados justamente porque todo mundo consegue explicar por que a própria parte depende da parte de outra pessoa.
06 / A DECISÃO
Em vez de procurar um culpado, eu tratei a interface como parte do trabalho.
Foi preciso reunir as áreas, explicitar dependências, transformar dúvidas em acordos e organizar uma sequência de testes.
A coordenação não veio de autoridade direta sobre todos os envolvidos.
Veio de tornar visível o que cada parte precisava receber, entregar e validar para que a próxima pudesse avançar.
O trabalho deixou de ser “cobrar a catraca” e passou a ser organizar o sistema necessário para que ela pudesse entrar em operação.
07 / DA DEPENDÊNCIA À EXECUÇÃO
O processo começou a andar quando a sequência passou a pertencer a alguém.
Com as áreas conectadas, o teste deixou de ser um evento isolado e passou a fazer parte de uma sequência.
A implantação avançou para execução definitiva.
A evidência deste caso não é um produto novo nem uma tela. É um processo antes travado que conseguiu atravessar as interfaces necessárias para ser implantado.
Às vezes, construir é criar o caminho entre partes que já existiam.
08 / O QUE ISSO PROVA
Coordenação também é uma forma de construção.
Não houve um sistema novo para mostrar.
Não houve uma única área que pudesse reivindicar sozinha o resultado.
O que existiu foi articulação entre especialidades, fornecedor, operação e tecnologia até que o conjunto funcionasse.
Esse tipo de resultado é menos fotogênico. Também é muito mais comum em operações reais.
09 / QUANDO ESTAR CERTO NÃO BASTA
Uma solução tecnicamente defensável ainda pode fracassar na parte que não aparece na planilha.
Em outra iniciativa, tentamos aumentar o controle de um processo de alimentação em áreas fechadas e reduzir desperdício.
A proposta fazia sentido tecnicamente. Havia uma estimativa preliminar de oportunidade econômica, mas ela não deve ser confundida com economia realizada.
A mudança, porém, alterava comportamento, conforto, acesso, responsabilidade e relações dentro da organização. A resistência apareceu.
Eu tinha entendido o processo. Não tinha entendido suficientemente bem o sistema humano que o processo alterava.
10 / O QUE PASSEI A FAZER DIFERENTE
Hoje eu tento mapear também quem perde alguma coisa quando a solução entra.
Uma mudança quase sempre melhora alguma coisa para alguém e piora alguma coisa para outra pessoa.
Pode ser custo. Autonomia. Acesso. Conforto. Poder. Responsabilidade.
Ignorar isso não torna a mudança mais racional. Só torna a resistência mais surpreendente.
Implementação não começa quando a solução está pronta. Começa quando entendemos o sistema que ela vai mexer.
11 / O QUE FICOU
Organogramas dividem responsabilidades. Problemas reais nem sempre respeitam essa divisão.
Alguns problemas existem dentro de uma área.
Outros só aparecem quando duas ou mais áreas precisam funcionar juntas.
Nesses casos, otimizar cada parte separadamente pode não produzir movimento nenhum.
Os problemas mais importantes geralmente vivem nas interfaces.
12 / ONDE ESSA LÓGICA REAPARECEU
Depois disso, comecei a procurar menos pelo dono do problema e mais pelas dependências que mantinham o problema vivo.
Essa leitura reaparece quando finanças encontra operação, quando marketing encontra caixa, quando produto encontra tecnologia e quando uma clínica precisa fazer aquisição, atendimento e processo conversarem.
As ferramentas mudam.
A pergunta permanece parecida: o que precisa se conectar para que o resultado finalmente aconteça?
finanças, educação, produto, aquisição e tecnologia precisaram funcionar como partes de uma mesma operação
modelo econômico, acesso, estrutura física e jornada digital precisaram ser ajustados juntos
regras, permissões, aprendizagem, comunidade e arquitetura precisaram ser organizadas antes de virarem interface
Nem todo problema entre áreas precisa virar sistema. Mas quase todo problema entre áreas precisa primeiro virar uma visão compartilhada do que está travando.
13 / O QUE O CASO PROVA
Coordenação também é uma forma de construção.
Nem todo projeto precisa terminar em produto.
Alguns resultados existem porque alguém conseguiu tornar dependências visíveis, organizar acordos e conduzir a sequência até a execução.
Cada área tinha uma parte legítima do trabalho, mas o resultado dependia do encaixe entre elas.
A condução precisou acontecer sem autoridade direta sobre todos os envolvidos.
A implantação avançou quando teste, validação e sequência deixaram de ser eventos desconectados.
A evidência não é uma tela. É um processo antes travado que chegou à implantação.
14 / STATUS
O episódio terminou. O aprendizado continuou trabalhando.
O processo principal avançou para implantação definitiva.
Outro episódio no mesmo contexto mostrou o limite oposto: uma solução tecnicamente defensável pode encontrar resistência quando altera relações, conforto, acesso, autonomia ou responsabilidade.
As duas experiências passaram a fazer parte da mesma leitura: processo e sistema humano precisam ser tratados juntos.15 / SEM PRODUTO PARA VENDER
Este caso existe porque nem toda evidência termina em sistema.
Ele não aponta para uma solução comercial específica.
Mostra uma parte do repertório que nasceu antes dos produtos atuais: coordenar problemas que atravessam especialidades, interesses e responsabilidades.
17 / O QUE FICOU
Estar tecnicamente certo é só uma parte do trabalho.
Uma solução também precisa sobreviver às pessoas, incentivos e relações que ela altera.
É por isso que, hoje, eu tento mapear não apenas o que a mudança resolve – mas quem ela move, o que ela exige e onde pode encontrar resistência.