Este caso segue o nosso processo estabelecido de verificação de casos públicos, e não um novo formato de demonstração, e nenhum modo de produto específico para o caso foi adicionado. Com base no estudo de caso público oficial da IBM Consulting, primeiro isolamos as respostas da fase final e, em seguida, reconstruímos apenas as informações disponíveis no momento da decisão num conjunto de dados de ensino. O Minerva Advisor concluiu uma execução ao vivo paga, e este vídeo é uma repetição verificada de uma Decision Room real. Trata-se de uma simulação de ensino independente, construída a partir de uma fonte pública. Isto não implica que a IBM Consulting tenha utilizado, revisto, endossado, patrocinado, certificado ou encomendado o Minerva Advisor, nem representa correspondência real ou resultados reais de clientes.

O caso começa com um grande retalhista cuja infraestrutura de comércio legada já não conseguia suportar de forma fiável o tráfego, depois de a procura impulsionada pela pandemia ter feito o volume passar de cerca de sete mil visitantes por minuto para um pico de dezanove mil. Foi pedido ao Minerva que ponderasse dois caminhos: comprometer-se de imediato com uma modernização da plataforma em grande escala, com uma única transição, ou executar primeiro um período delimitado e interrompível de estabilização de capacidade e um controlo de evidências de migração, para determinar o âmbito antes de avançar.

A execução deixa um recibo de trabalho auditável, com cinco itens. Primeiro, baseia-se numa única fonte verificada. Segundo, identifica quatro funções consultivas distintas. Terceiro, separa factos confirmados de inferências e de questões em aberto. Quarto, compara exatamente dois caminhos concorrentes, lado a lado. Quinto, preserva três explicações alternativas e uma condição explícita de reversão, para que cada julgamento possa ser rastreado até ao que era conhecido, ao que era assumido e ao que ficou em aberto.

Eis o que era conhecido e desconhecido no momento da decisão. Conhecido: a infraestrutura legada, o aumento da procura online e a falha no período de pico. Desconhecido: em que medida cada fator, capacidade, atualização de versões, carga da base de dados, integração, pesquisa, checkout ou monitorização, contribuiu para essa falha, quais as dependências que podiam ser isoladas, se existia um caminho de recuperação viável e quanto tempo a estabilização de curto prazo poderia realisticamente ganhar antes do próximo pico.

O sistema preserva o seu contra-argumento mais forte. A falha poderia resultar de vários fatores a interagir em simultâneo, pelo que o controlo de evidências poderia nunca isolar uma única camada clara e corrigível. A condição de reversão é explícita: se as medidas de estabilização não conseguirem resistir de forma fiável durante a próxima janela de pico e não se obtiver qualquer ganho de diagnóstico sobre quais os subsistemas verdadeiramente responsáveis, a decisão deve mudar de imediato para uma modernização faseada, em vez de continuar a aguardar.

A resposta publicada foi excluída da informação recebida pelo Minerva. O relato da fase final da IBM Consulting descreve a metodologia Garage, o IBM Cloud e o Red Hat OpenShift, mais de um ano de construção e testes, uma transição de infraestrutura e de versões concentrada num único fim de semana, zero incidentes, suporte para mais de vinte e sete mil visitantes em pico, e um crescimento de receita ao longo de dois anos superior a cento e quinze por cento. Nada disto entrou na informação de decisão. O Minerva não teve conhecimento da pilha tecnológica escolhida nem do resultado alcançado.

Três consultores verificam depois um único julgamento a partir de ângulos diferentes. Marcus define a verdadeira decisão como saber se é possível estabelecer um controlo de estabilização fiável antes do próximo pico. Sofia analisa as consequências para o comércio digital, a fiabilidade da plataforma, as operações com clientes e os decisores. Evelyn questiona se a estabilização de curto prazo se limita a adiar o problema arquitetónico subjacente, salientando que os problemas de capacidade, base de dados, pesquisa e checkout se podem amplificar mutuamente, pelo que exigir uma única causa-raiz antes de expandir a migração arrisca perder por completo a janela de oportunidade. Os três convergem na mesma recomendação: adotar primeiro o controlo de estabilização e evidências, delimitado no tempo e interrompível.

É aqui que o sistema mostra se o input do executivo altera o julgamento. O executivo introduz uma condição: primeiro, quantificar a próxima janela de pico e o nível de falha tolerável; se a estabilização de curto prazo não conseguir cobrir essa janela, acelerar sem demora uma migração de âmbito limitado e recuperável. O Minerva regista um recibo formal de resposta. A recomendação subjacente mantém-se inalterada, mas a condição de reversão é reforçada e passa a ser explicitamente delimitada no tempo.

Comparando diretamente as duas opções: a modernização imediata em grande escala enfrenta de frente o problema arquitetónico, mas, com dependências e caminhos de recuperação ainda pouco claros, uma única transição de grande dimensão comporta um risco elevado para os clientes. A estabilização de capacidade, com um controlo de evidências de migração, permite basear as decisões de âmbito em evidências faseadas, ao custo de uma pressão contínua no período de pico a curto prazo. O executivo seleciona o caminho de estabilização, preservando explicitamente uma saída de migração acelerada caso as evidências se voltem contra essa opção.

A ação assumida: no prazo de três semanas, as equipas de comércio digital e de fiabilidade da plataforma devem quantificar as causas-raiz da falha, definir a próxima janela de pico, mapear dependências e confirmar caminhos de recuperação, servindo tudo isto como limiar para decidir se se deve avançar para uma migração completa. O Minerva não afirma que uma plataforma cloud tenha sido selecionada, que qualquer transição tenha ocorrido, ou que resultados de crescimento tenham sido alcançados.

Este caso público da IBM Consulting passou em dez de dez verificações de qualidade de decisão. A Decision Room utilizou quatro chamadas de modelo, entregando a sua primeira decisão em 17.762 segundos e concluindo a verificação cruzada completa dos três consultores em 24.513 segundos, cumprindo o limiar de trinta segundos para a primeira decisão e o limiar de quarenta e cinco segundos para o resultado completo. Tanto a qualidade como a velocidade da decisão foram aprovadas, mas isto continua a ser um teste de caso único, não equivalente a padrões de serviço de nível de produção ou a resultados reais de clientes.