Pedro Ferreira Queimado, founder & Senior Efficiency consultant da KronoLog Solutions, analisa a recente polémica em torno da classificação digital dos exames nacionais e como este problema se pode relacionar com a área da logística, uma vez que a robustez operacional na transição de projetos-piloto para implementações em larga escala apresenta-se como um fator crítico de sucesso na transformação organizacional.
Nos últimos dias, a polémica em torno da classificação digital dos exames nacionais tem sido apresentada sobretudo como um problema do sistema educativo, da plataforma informática ou da relação entre o Ministério da Educação e os professores classificadores. É natural que assim seja. Estamos a falar de provas que condicionam o acesso ao ensino superior e de milhares de alunos que aguardam classificações decisivas.
Mas, para quem trabalha em logística, operações e transformação organizacional, este caso levanta uma questão que ultrapassa largamente o contexto dos exames nacionais. O que estamos a assistir reúne muitos dos sinais típicos de um projeto de implementação tecnológica que funciona bem em piloto, mas revela fragilidades quando é escalado.
Em 2025, o exame nacional de Filosofia foi utilizado como projeto-piloto para classificação totalmente digital. Mais de vinte mil provas foram abrangidas e, ainda assim, registaram-se dificuldades técnicas, alterações de prazos, provas que desapareciam temporariamente, imagens ilegíveis e folhas que não surgiam corretamente associadas. Um ano depois, o Ministério afirmou que essas fragilidades tinham sido corrigidas e que o piloto tinha sido positivo.
É legítimo perguntar se o piloto serviu para testar verdadeiramente a robustez do processo ou apenas para confirmar que a solução podia avançar. Um piloto não demonstra que uma solução está preparada para ser escalada. Demonstra apenas que funcionou num determinado contexto, com um volume específico, um grupo reduzido de utilizadores e acompanhamento permanente da equipa de projeto. Quando o processo é generalizado, essas condições desaparecem: o volume aumenta, as exceções multiplicam-se e a variabilidade passa a fazer parte do funcionamento diário.
Quem trabalha em operações sabe que a diferença entre um processo robusto e um processo aparentemente funcional está na forma como responde quando as condições deixam de ser ideais. O que acontece quando falta uma página? Quando uma imagem não é carregada? Quem deteta a anomalia? O processo impede que alguém conclua a tarefa com informação incompleta ou limita-se a permitir que o erro siga em frente?
É aqui que entram os controlos operacionais, tantas vezes vistos como burocracia enquanto tudo corre bem. Numa operação crítica, o sistema deve confirmar que todas as páginas foram recebidas, que cada resposta está associada ao aluno e ao item corretos e que nenhuma classificação pode ser concluída enquanto existir informação inconsistente. Não sabemos quais destes mecanismos existiam neste caso, mas os relatos públicos demonstram precisamente a importância de desenhar processos que previnam o erro, em vez de dependerem apenas da atenção dos utilizadores.
Esta situação expõe também um equívoco recorrente sobre transformação digital. Digitalizar não significa transformar, e transformar não significa necessariamente melhorar. Uma organização pode substituir papel por uma plataforma informática e continuar a executar exatamente o mesmo processo, apenas num formato diferente.
Na operação física, uma folha em falta é imediatamente visível. Num processo digital, essa ausência pode surgir apenas como um ecrã em branco ou uma informação que parece simplesmente não existir. Se o sistema não diferencia claramente uma indisponibilidade temporária de uma inexistência efetiva da informação, está a criar condições para decisões erradas.
O mesmo acontece com um WMS. Um piloto pode decorrer sem incidentes numa área limitada do armazém e concluir-se que a solução funciona. Só mais tarde, quando surgem códigos de barras danificados, diferenças de inventário, devoluções, integrações que falham ou volumes muito superiores aos previstos, aparecem fragilidades que nunca tinham sido colocadas à prova.
A pergunta mais importante deixa então de ser “o piloto correu bem?”. Passa a ser: Que fragilidades foram encontradas? Que evidências existem de que ficaram verdadeiramente resolvidas? Foram realizados testes com carga máxima? Simularam-se exceções? Existiam mecanismos automáticos para impedir que um utilizador concluísse uma tarefa com informação incompleta?
Estas perguntas não procuram antecipar todas as falhas possíveis. Procuram perceber se o sistema consegue reconhecer quando deixa de reunir condições para operar com segurança.
Há ainda outro problema que os rollouts costumam revelar. A escala raramente cria defeitos novos. Limita-se a ampliar aqueles que já existiam. Uma falha que ocorre em apenas 0,1% dos casos pode parecer irrelevante durante um piloto. Quando o volume aumenta vinte vezes, essa mesma taxa traduz-se num número significativo de ocorrências. O mesmo acontece com a utilização simultânea da plataforma, com os pedidos de suporte e com a necessidade de resolver exceções que nunca tinham surgido durante os testes.
Escalar um processo não significa repetir muitas vezes aquilo que funcionou em pequena escala. Significa operar um sistema sujeito a níveis completamente diferentes de pressão e variabilidade. Por isso, um rollout exige critérios objetivos de passagem entre fases, indicadores de qualidade, mecanismos claros de escalada e regras igualmente claras para decidir quando avançar, quando parar e quando recuar.
Existe também uma tendência frequente nas organizações: preparar cuidadosamente o cenário de sucesso e dedicar muito menos atenção ao cenário de falha. Há pressão para cumprir calendários, justificar investimentos e mostrar resultados. Nestas circunstâncias, é fácil interpretar um piloto bem-sucedido como prova suficiente de que a solução está pronta. Muitas vezes, porém, aquilo que o piloto demonstra é apenas que, com acompanhamento permanente e esforço adicional das equipas, foi possível compensar manualmente aquilo que o processo ainda não conseguia garantir por si próprio.
Essa é outra lição importante. Quando um piloto depende de intervenção constante da equipa de projeto, de decisões manuais ou de apoio excecional, esses recursos fazem parte da solução e não podem desaparecer silenciosamente quando chega o rollout. Um processo que só funciona porque existe uma equipa permanentemente disponível para resolver problemas ainda não está estabilizado. É um processo assistido.
Também não devemos cair no erro oposto e concluir que a digitalização foi uma má decisão. A classificação digital pode trazer ganhos muito relevantes em rapidez, uniformização, rastreabilidade e distribuição do trabalho. Da mesma forma, um WMS, uma automação ou um novo modelo de outsourcing podem transformar positivamente uma operação. Na maioria das vezes, o maior problema não está na tecnologia. Está na forma como desenhámos o processo que a suporta.
Por isso, a discussão mais útil não é tentar provar que a tecnologia falhou ou que o modelo anterior era melhor. É perceber o que esta implementação nos ensina sobre a forma como conduzimos projetos críticos. Que problemas foram registados durante o piloto? Como foram classificados? Que ações corretivas foram implementadas? Como foi validada a sua eficácia? Que critérios sustentaram a decisão de avançar? Que mecanismos existem para impedir que as mesmas falhas se repitam?
Estas não são perguntas dirigidas apenas ao Ministério da Educação ou ao IAVE. São perguntas que qualquer administração, direção de operações ou equipa de projeto deveria fazer antes de generalizar uma transformação. O objetivo não deve ser apenas concluir um projeto. Deve ser demonstrar, com evidência, que as fragilidades conhecidas foram compreendidas, tratadas e novamente testadas em condições próximas da realidade.
Na supply chain aprendemos, muitas vezes da forma mais difícil, que um processo não se torna robusto por sobreviver a um piloto. A robustez constrói-se através da antecipação de exceções, da definição de controlos, da capacidade de interromper o processo quando os dados deixam de ser fiáveis e da humildade para reconhecer que uma experiência bem-sucedida não elimina o risco da implementação seguinte.
Talvez essa seja a principal reflexão deste caso. O verdadeiro objetivo de um piloto nunca deveria ser provar que a solução escolhida estava certa. Deveria ser descobrir tudo aquilo que ainda pode correr mal antes de escalar. Porque um piloto serve para aprender. Um rollout serve para confirmar se aprendemos.
E o verdadeiro teste de qualquer transformação começa precisamente no dia em que deixamos de lhe chamar projeto e passamos a chamar-lhe operação.
