Kennisbank

Que dependência mantém o resto do plano travado

Um plano Day 100 não consiste em cem tarefas isoladas. Consiste num pequeno número de decisões das quais muito depende, e um grande número de tarefas que só podem começar a partir do momento em que essas decisões existam. A escolha do sistema para a administração financeira é uma dessas decisões. A estrutura das linhas de reporte é outra. Enquanto estas não estiverem fixadas, uma série de outras tarefas fica à espera — por vezes de forma visível, mais frequentemente de forma invisível, porque ninguém acompanha a fila de espera.

A pergunta "que dependências bloqueiam o resto" não é, portanto, uma questão de desenhar um planeamento com setas. É uma questão de determinar quais os nós que são realmente nós, e quais as tarefas que apenas parecem estar à espera umas das outras porque ninguém as desligou.

O que torna uma dependência num bloqueio

Nem toda a ordem é uma dependência. Algumas tarefas estão colocadas uma após a outra num planeamento porque isso pareceu conveniente, não porque uma precise da outra. Um bloqueio real satisfaz um critério simples: a tarefa B só pode começar, ou só pode começar bem, a partir do momento em que a decisão A for tomada. O inverso também se aplica — se B também puder avançar sem A, com uma suposição temporária, não é um bloqueio mas uma escolha de esperar.

Essa distinção é exatamente a razão pela qual quais decisões pertencem aos primeiros cem dias é uma pergunta que precede esta. Uma lista de cem tarefas sem distinção entre bloqueante e não bloqueante resulta num planeamento que sugere igual pressão em todo o lado. Isso raramente é verdade. Normalmente, um punhado de decisões bloqueia um múltiplo de tarefas, e o resto pode avançar em paralelo.

O que custa esperar, e porque isso não é igual em todo o lado

Nem toda a decisão adiada custa o mesmo. Uma decisão sobre identidade visual pode esperar meses sem que nada se quebre. Uma decisão sobre quem pode assinar contratos com clientes pode, dentro de semanas, levar a uma paralisação num departamento que está à espera disso. A questão não é apenas o que uma decisão bloqueia, mas o que custa não a tomar — e esse custo não é igual em todo o lado, mesmo entre decisões que parecem igualmente relevantes no papel.

Por isso, tem sentido não ordenar decisões por importância, mas pelo que a incerteza custa enquanto está em aberto. Como ordena as decisões pelo custo da incerteza descreve essa ordenação: não o que a decisão em si custa, mas o que custa ainda não a ter. Essa distinção muda muitas vezes a ordem. Uma decisão que é substancialmente pesada mas bloqueia pouco mais pode ficar para o fim. Uma decisão que parece leve mas deixa três equipas à espera deve vir primeiro.

Quem vigia isso, e porque isso não é automaticamente alguém

Uma dependência que ninguém acompanha não se torna menos bloqueante — apenas se torna visível mais tarde, geralmente no momento em que o atraso já se acumulou. A vigilância não é uma tarefa que fique automaticamente a cargo de uma das equipas envolvidas, pois ambas as equipas só veem o seu próprio lado da dependência. A equipa que espera sabe que está a esperar. A equipa de cuja decisão isso depende, muitas vezes não sabe que alguém está à espera dela.

Essa vigilância é a tarefa central do gabinete de integração: não executar, mas ver quem espera por quem, e manter isso visível enquanto for relevante. Como esse gabinete permanece funcional sem se tornar ele próprio numa camada que atrasa, está descrito em como mantém o gabinete de integração funcional. E porque as dependências estão muitas vezes ligadas a pessoas — uma assinatura, uma aprovação —, é também uma questão de quem na organização pode realmente desatar esses nós, o que se relaciona com quem são as suas pessoas-chave numa aquisição.

O reverso da medalha: nem tudo precisa de ser desatado

A cada dependência corresponde uma pergunta que é facilmente ignorada: este componente realmente precisa de ser fundido. Resolver um bloqueio integrando dois sistemas não é necessariamente melhor do que deixar o bloqueio existir mantendo os sistemas separados. Por vezes, a solução mais económica não é desatar, mas não fundir. Essa pergunta deve ser feita em cada nó, não como excepção mas como parte fixa da ponderação — caso contrário, integrar torna-se um fim em si mesmo em vez de um meio.

O que significa efetivamente uma data Day 100 não cumprida, e quem é então responsável por isso, está relacionado com a forma como esses bloqueios foram acompanhados. Isso está desenvolvido em o que faz quando o Day 100 não é alcançado e quem vigia isso. E a incerteza que surge enquanto as decisões ainda estão em aberto tem um lado humano que não cabe num planeamento: porque é que as pessoas saem nos meses de incerteza descreve o que a espera custa às pessoas, não apenas às tarefas.

O mergerintegration.net está em construção. Quem quiser usar os geradores e o gabinete de integração assim que estiverem disponíveis pode inscrever-se na lista de espera.

Uma vez identificadas as dependências, permanece a questão de quem executa efetivamente o trabalho assim que os nós estiverem desatados. Muitas das tarefas que esperam por uma decisão — transferência de dados, controlo de documentos, estruturação de reportes — consistem em passos que se repetem a partir do momento em que as regras estão fixadas. O scan de trabalho da FTE TO AI calcula, por tarefa, que parte desse trabalho pode ser assumida pela IA, tornando claro onde as pessoas continuam a ser necessárias e onde surge capacidade para as decisões que não podem prescindir dela.