A classe "Cover Oregon"/Fracasso da Oracle em perspectiva=

O "Cover Oregon"/Oracle Failure in Perspective

Posted on em Uncategorized

Doug Hadden, VP de Produtos

O "Cobertura do Oregon" O fracasso do intercâmbio de serviços de saúde gerou alguns sensacional "cópia" - começando com "jogo da culpa" - e, agora, ações judiciais de ambas as partes. A contratada, a Oracle, alegando difamação por parte do Estado de Oregon. O estado alegando extorsão e faturamento falso por parte da Oracle. Uma equipe federal da SWAT constatou incompetência no gerenciamento da Cover Oregon, enquanto a Oracle "lançou corpos em vez de conjuntos de habilidades" no projeto. Há um relato de "denunciante" e alguns supostos desvios de lei estadual. Como Michael Krigman destaca "Com esses projetos complexos de TI, na maioria das vezes é praticamente impossível dizer que a culpa ou a responsabilidade recai totalmente sobre um lado ou outro..”

Houve uma falta de perspectiva nas reportagens sobre o fracasso desse projeto devido ao foco nos aspectos sensacionalistas da história. Gostaria de acrescentar um pouco mais de perspectiva:

  1. Alguns fatos sobre a "Solução Oracle"
  2. Os custos reais para o Estado
  3. O que o $240M+ compra no setor de software
  4. O impacto do $240M no setor de saúde do Oregon
  5. O que poderia ter evitado esse fiasco

1. Cobertura do Oregon é muito mais do que um site da Web

  • Muito se tem falado sobre os problemas com as soluções desenvolvidas sob medida para o Obamacare e as soluções COTS (Commercial-Off-The-Shelf) da Oracle para o Cover Oregon como "sites da web" - não se trata de simples "sites", mas de trocas com uma quantidade significativa de funcionalidades de back-office, fluxo de trabalho e integração necessários
  • A implementação é de dois projetos: "HIX-IT" e "Modernização dos serviços sociais"
  • O principal aplicativo usado foi o Siebel Public Sector Case Management com Automação de políticas Oracle que tenha um conector Siebel

O FreeBalance é um parceiro de middleware da Oracle. No entanto, a FreeBalance compete com a Oracle em implementações de gerenciamento financeiro do governo, mas não com o pacote Siebel CRM usado para Cobertura do Oregon. A FreeBalance não fornece um aplicativo de software de intercâmbio de serviços de saúde. Não é comum que eu opine sobre concorrentes/parceiros pelo nome neste blog, mas acho que essa perspectiva pode ajudar no debate. É muito provável que ambas as partes tenham algumas explicações a dar.

A Oracle fez algumas afirmações enganosas em seu ação judicial:

  • "A Oracle é uma empresa com 30 anos de história de desenvolvimento e implementação bem-sucedidos de alguns dos sistemas técnicos mais complexos do mundo, incluindo as bolsas de seguros de saúde de pelo menos meia dúzia de estados." - Há uma grande diferença entre "desenvolver" e "implementar". Oráculo raramente implementa esses sistemas. A afirmação também implica que a Oracle desenvolveu muitas bolsas de seguro-saúde bem-sucedidas. Em quais estados? O produto Siebel foi usado? O banco de dados Oracle foi usado e isso é apresentado como um sucesso? A única coisa relevante aqui é o tempo em que a mesma solução foi usada com sucesso.
  • A Oracle alega que "os funcionários públicos optaram por não dar uma resposta ponderada e totalmente informada", culpando a Oracle. Bem-vindo ao mundo real - o software aplicativo é o elemento visível - e, posso lhe dizer, o fornecedor do aplicativo será responsabilizado por erros de integração de sistemas, middleware, hardware e rede. Ou a equipe de suporte interno que não segue as instruções sobre patches de segurança ou procedimentos de manutenção. 
  • A Oracle alega que o "estado, portanto, empreendeu um projeto de várias partes de tamanho e complexidade sem precedentes para o qual não tinha experiência". Alguém apontou uma arma para a cabeça da Oracle? Se for verdade, deveria ter sido tão óbvio na época quanto é agora. Por que a Oracle aceitou o contrato? Está claro que a falta de conhecimento do estado foi um problema. condição pré-existente.
  • A Oracle fez uma apresentação dois meses antes do lançamento programado, indicando que os requisitos não estavam prontos. Parece que nem todos os requisitos foram concluídos, sendo que as funções de interface do usuário e de segurança não estavam prontas. Existem requisitos que são impeditivos - talvez existam. Digamos que isso seja verdade. Uma "apresentação" é o local adequado para isso? Certamente, a Oracle deveria estar se comunicando em muitos outros canais antes dessa data. 
  • A Oracle alega que o diretor executivo da Cover Oregon estava mais preocupado com o "brilho do que com o bife". É ingênuo pensar que isso não ocorreria - é altamente previsível que isso aconteça em projetos de front-office nos setores público e privado. E a Oracle já deveria saber disso.
  • A Oracle alega que o estado "continuou a frustrar os esforços da Oracle a todo momento. No entanto, a Oracle continuou a trabalhar a pedido da Cover Oregon, tentando levar o projeto a uma conclusão". Isso parece implicar que a Oracle estava fazendo algum barulho sobre o projeto, mas não comunicou o nível de urgência. É normal ouvir uma empresa de implementação apresentar riscos para protegê-la caso as coisas deem errado. A Oracle foi vista pelo estado como estando no modo "CYA"? 
  • A Oracle argumenta que o contrato de "tempo e materiais" era apropriado nesse caso. A Oracle alega que "sem um escopo fixo para o projeto - o equivalente a plantas arquitetônicas - não se poderia razoavelmente esperar que nenhum contratado concordasse em trabalhar em uma base de taxa fixa". Isso vem de uma empresa que, teoricamente, já realizou "meia dúzia" desses projetos e tem uma solução pronta para uso. Será que a Oracle decidiu aproveitar a falta de recursos de gerenciamento de projetos do estado para estender o tempo e os materiais? 
  • Como um ponto adicional - você QUASE NUNCA obter "projetos arquitetônicos" no governo R
    FPs para contratos de preço fixo usando software pronto para uso. Às vezes, você obtém o fluxo de trabalho do processo ("como está" e "como será") e modelos de banco de dados. Às vezes, há diagramas UML. Esses sempre mudar durante a implementação.

O estado também fez algumas afirmações interessantes:

  • 'A Oracle mentiu para o Estado sobre a "Solução Oracle". A Oracle mentiu quando disse que a "Solução Oracle" poderia atender a ambas as necessidades do Estado com produtos Oracle que funcionavam "prontos para uso". A Oracle mentiu quando disse que seus produtos eram "flexíveis", "integrados", funcionavam "facilmente" com outros programas, exigiam pouca personalização e podiam ser configurados rapidamente. A Oracle mentiu quando afirmou que tinha "a solução mais abrangente e segura com relação à funcionalidade total necessária para a Oregon". O ponto de partida para o argumento parece ser sobre as alegações de vendas. Parece-me que é possível argumentar, em relação a outras soluções, que o software atende a muitas dessas alegações. O ponto principal é a extensão em que o código-fonte precisou ser modificado, o que elimina toda a confusão sobre o que as pessoas entendem como "flexível" ou "integrado".
  • Parece que a Oracle decidiu chamar os "scripts" de "configuração". O estado afirma, com razão, que "a configuração não exige que um desenvolvedor de software escreva código de computador para obter a funcionalidade". A Oracle esclareceu que classificou sua resposta aos requisitos do DHS como "4" se seus produtos atendessem aos requisitos "prontos para uso sem modificação ou por meio de configuração de rotina usando os conjuntos de ferramentas fornecidos com os aplicativos * * *". A Oracle alegou que a "configuração de rotina" poderia ser realizada por analistas de negócios e não exigia que os engenheiros de software escrevessem códigos ou scripts de software. De acordo com a Oracle, a "personalização" envolvia escrever scripts para criar novas funcionalidades. Scripts são códigos de software que são executados sobre aplicativos de software". Scripting é a programação de macros em um aplicativo do Office, JavaScript, procedimentos armazenados ou scripts de interface. No entanto, "a Oracle classificou mais de 95% dos requisitos do DHS como "4", indicando que a "Solução Oracle" era 95% "pronta para uso"". 
  • A Oracle alegou progresso durante todo o projeto até perto do final, quando o escopo foi reduzido. Isso parece contradizer a noção de que todo tipo de mudança de última hora foi introduzida. É quase como se a Oracle e a Cover Oregon não estivessem no mesmo projeto.
  • O estado alega que "no final de setembro, no entanto, quando a Oracle não conseguiu demonstrar um site funcional". Uma ou duas semanas antes do lançamento é tarde demais para perceber isso. (Parece estranho que a solução não estivesse no controle de qualidade final nesse momento em que o número de bugs resolvidos excedeu o número de novos bugs descobertos).
  • Cúram Software, adquirido pela IBMA IBM era a única concorrente no processo de aquisição e se retirou do processo (talvez porque as negociações com a IBM tornaram sua oferta original inválida, pois a entidade comercial estava prestes a mudar). Os outros fornecedores estavam cientes da oportunidade? O processo foi realmente competitivo? Os outros fornecedores estavam cientes dos problemas esperados do projeto?
  • "Em novembro, os executivos da Oracle continuaram a afirmar à Cover Oregon que o sistema estava quase pronto para ser lançado." Há uma desconexão significativa aqui na percepção e nas comunicações. 
  • A alegação do estado é muito detalhada. Uma das alegações é que "a Maximus, consultora externa de garantia de qualidade da Cover Oregon, também descobriu que o trabalho da Oracle estava abaixo dos padrões do setor". Em seu relatório de outubro de 2013, a Maximus afirmou que os "processos da Oracle não atendem aos padrões do setor. A análise de impacto, a revisão de código, os padrões de codificação e as técnicas adequadas de desenvolvimento paralelo são ad hoc e inconsistentemente aplicados ou compreendidos". Se essa afirmação for verdadeira, os erros se infiltrariam facilmente em um projeto que tivesse uma excelente articulação de processos de negócios.
  • Deve-se observar que as empresas de ERP apresentam as soluções como totalmente integradas e flexíveis. Como aponta Michael Krigsman: "Qualquer pessoa que conheça software corporativo sabe que esses não são termos absolutos.”

2. $240M não é o custo total

"$240 milhões" é o valor mais frequentemente divulgado, mas isso não representa o custo total para o estado.

3. O $240M compra muito desenvolvimento de software

$240M+ compra uma quantidade significativa de desenvolvimento de software - É difícil justificar esse custo, mesmo que o software funcionasse.

  • $240M compra 1.000 anos de desenvolvimento de software por pessoa, considerando um custo de $20.000 por mês por pessoa, que inclui salários, benefícios, equipamentos, treinamento e espaço. Isso é mais do que suficiente para criar software COTS para ambas as funções a partir do zero.
  • O $240M cobre cerca de 1/24 do custo para a Oracle adquirir a Siebele, mesmo considerando os lucros sobre Cobertura do OregonO valor de $5.5B reivindicado pelo estado é quase igual ao custo de aquisição da Siebel. A reivindicação de $5,5 bilhões feita pelo estado é quase igual ao custo de aquisição da Siebel.
  • O $240M excede a $110M captado pela Salesforce.com ao abrir o capital e possivelmente poderia cobrir o valor pago pela Infor adquire a Saleslogix - portanto, é lógico que o estado poderia ter comprado um fornecedor de CRM.
  • O valor de $240M é cerca de 10 vezes o custo para adquirir um sistema de gerenciamento financeiro central para uma população de 3,9 milhões no mercado internacional, estimado em $6 por pessoa. É claro que as implementações em um país desenvolvido são mais sofisticadas - mas não 10 vezes mais sofisticadas, e não para uma escala menor de funcionalidade.
  • O $240M cobre o dobro dos custos totais de implementação do ERP para Zâmbia 14,3 milhões de pessoas (originalmente $26M, aumentado para $42M) e Vietnã 89,7 milhões de pessoas (originalmente $40M, aumentado para $71M).

4. O $240M+ tem um impacto significativo sobre a assistência médica no Oregon

  • O PIB do Oregon foi estimado em $168,6 bilhões em 2010 com custos totais de saúde estimados em 17.9% nos Estados Unidos o que resulta em um gasto total de mais de $30B ou cerca de $7.750 por residente por ano - aproximadamente o custo total de sustentar 31.000 habitantes do Oregon.
  • O $240M cobre quase a metade do orçamento do estado para "saúde pública". 
  • $240M é mais do que a receita de bilheteria do filme "Patch Adams", estimado em mais de $202M em todo o mundo.
  • A reivindicação de $5.5B pelo estado ajudará muito a equilibrar o orçamento

5. O que poderia ter evitado esse fiasco

  1. Software escrito para o setor privado tem problemas quando aplicado no setor público. Os fabricantes de software que operam em muitos setores frequentemente veem as semelhanças nas necessidades do setor público, mas raramente entendem as diferenças - e as complexidade dessas diferenças. Além disso, esses fabricantes se aproveitam do mito de que "O governo deve funcionar mais como uma empresa.” Os compradores do governo devem esperar uma hipérbole quando os fornecedores cujos produtos foram criados para o setor privado afirmam ter uma funcionalidade "pronta para uso".
  2. Muitos problemas ocorrem em implementações governamentais quando o fornecedor de software não faz parte da estrutura de governança. Em geral, a participação total do fornecedor de software, como empresa de consultoria, é um bom sinal. É um bom sinal se o fornecedor estiver usando a experiência para atualizar o software para atender às necessidades exclusivas de um intercâmbio de saúde. Os fornecedores de software, em geral, não têm incentivo para acumular receita de serviços porque isso desvaloriza a empresa. No entanto, o $240M é uma gota d'água para a Oracle. E a Oracle pode não ter se comprometido a mudar o produto, mas sim a aumentar a receita associada ao contrato de tempo e materiais. "A Oracle não tinha uma estrutura de responsabilidade para garantir que o design do site fosse viável dentro dos prazos designados e que os prazos realmente estivessem sendo cumpridos..”As licenças parecem ter sido estimadas em $7M. Os compradores governamentais não devem se envolver em contratos de tempo e materiais além dos protótipos e devem esperar que os fornecedores de software alterem os produtos, não os personalizem.
  3. Digamos que havia incerteza demais para esperar um contrato de preço fixo. Temos que aceitar que a funcionalidade "pronta para uso" e as noções de "flexibilidade" divulgadas pela Oracle eram uma hipérbole. Tempo e materiais não parecem ser o veículo de contrato apropriado porque não há o tipo de incerteza associada a colocar alguém na lua. Ou a incerteza em torno do famoso McDonnell Douglas A-12 ou Avro Canada CF-105 Arrow projetos. Um contrato de desempenho pode ter sido mais apropriado nesse caso, em que a Oracle poderia ser paga com base nos resultados. Isso poderia ter mudado os incentivos. Os compradores governamentais precisam selecionar o método de contrato mais adequado com base no risco e na incerteza.
  4. A observação de que havia 1.198 erros no período de teste de aceitação é preocupante. Esse parece ser um número fenomenal de erros. Pode ser que não tenha havido reengenharia de processos quando a equipe do governo estava buscando pouca ou nenhuma mudança de comportamento em relação ao sistema legado. Ou a equipe não articulou totalmente os requisitos desde o início. Isso aponta para uma falta de conhecimento especializado do fornecedor no domínio. A articulação e a análise das necessidades ("como está" e "como será") não devem ser um processo genérico liderado por especialistas em software - devem ser lideradas por especialistas no domínio. Em outras palavras, a equipe da Oracle era especialista em seguros, assistência médica, direito (para entender o Obamacare) e finanças do governo. A Oracle precisava trazer para a mesa mais do que a experiência em software da Siebel (por exemplo: por que não aproveitar a aquisição da Skywire ou o quadro de advogados que vão atrás de Empresas de manutenção terceirizadas?). Os compradores governamentais devem insistir em especialistas no domínio.
  5. Os projetos de implementação geralmente enfrentam problemas. O estresse envolvido muitas vezes faz com que o cliente e o provedor entrem na espiral de adicionar mais funcionários para tentar cumprir o prazo. Essa abordagem quase sempre está errada. Aumentar o tamanho da equipe reduz a eficiência, uma observação feita na década de 1960 com o Mês do Homem Mítico. (Há também a tendência de evitar ideias inovadoras e experimentar um compromisso cada vez maior com um processo fracassado). Nunca, mas nunca mesmo, coloque mais pessoas em um projeto que está fracassando.
  6. A Oracle alega que o gerenciamento de projetos do estado foi incompetente, assim como a revisão federal. Certo. O gerenciamento de projetos no setor público tende a ser inferior ao do setor privado. A Oracle sabe disso. Eles conhecem o risco. A Oracle procurou criar capacidade? Eles tentaram persuadir o estado a fornecer as informações necessárias? Eles realizaram workshops de gerenciamento de mudanças? INão importa quão ruim seja o gerenciamento do projeto por parte do governo, cabe ao fornecedor desenvolver a capacidade de superar o problema. Trata-se de dinheiro público.
  7. O período de implementação de junho de 2011 a 1º de outubro de 2013 é de aproximadamente 18 meses. Esse é um cronograma apertado, mas razoável, para um projeto desse tipo quando se usa software COTS. É o tipo de cronograma que precisa de estratégias de detecção e mitigação de riscos. (E precisa de um gerenciamento mais ágil para testar protótipos e regras comerciais antecipadamente. Caso contrário, você acaba entregando algo que parece atender à especificação, mas não atende à necessidade - o famoso problema "conforme projetado". Os métodos de implementação em cascata são ineficazes em cronogramas apertados. 
  8. O estado alega que "A presidente da Oracle alegou que a bolsa estava pronta para ser lançada em fevereiro de 2014. Sua afirmação pessoal foi desmentida por avaliações realizadas por especialistas independentes." É razoável pensar que Sra. Catz não tinha conhecimento da situação real com base no feedback da equipe de implementação - uma situação muito comum em grandes organizações. É difícil esconder o fato de que um cliente não está disposto a pagar. Talvez a equipe da Oracle tenha decidido ro
    A equipe da Oracle deveria ter lançado a grande arma neste momento. A equipe da Oracle deveria ter lançado a grande arma muito antes no processo, assim que o contrato foi concedido. Os executivos precisam estar atualizados sobre contratos grandes, incomuns ou altamente políticos - certamente quando se trata dos 3. A Oracle pode ser aconselhada a usar Software Oracle Risk Management e práticas recomendadas de gerenciamento de riscos. Imagine se a Sra. Catz tivesse entrado em contato com o estado quando o primeiro conjunto de problemas se tornou evidente. Os compradores governamentais e os parceiros fornecedores precisam de processos eficazes de gerenciamento de riscos para grandes contratos.
  9. A Oracle não opera como uma organização "centrada no cliente". Essa não é uma posição irracional para uma empresa de tecnologia. No entanto, há muitas ferramentas disponíveis para que as empresas de tecnologia colaborem com as organizações - algumas tradicionais, como a Primavera Enterprise Project Management Suite de propriedade da Oracle - alguns baseados em redes sociais, como o suíte de propriedade da Oracle. A Oracle usava essas ferramentas para gerenciamento de projetos e engajamento de clientes? Se não, por que não? Os fornecedores de software precisam comer sua própria ração.
  10. O estado alega que a Oracle exibiu um "padrão de atividade de extorsão." Esse é o tipo de hipérbole que se usa em processos judiciais. No entanto, tem havido uma preocupação com a consolidação de fornecedores que está criando cartéis em que os fornecedores terceirizados estão se alinhando com os fornecedores de nível 1. A cadeia de valor do ERP para grandes implementações tem sido predominantemente capturada por esses dois fornecedores. Os compradores governamentais precisam entender o risco de não ter influência sobre os grandes fornecedores - é uma batalha assimétrica em que os fornecedores não precisam de receita, têm acesso a mais recursos e informações e têm advogados melhores.

Essa má reputação prejudicará a Oracle?

É improvável que essa ação judicial prejudique a Oracle de alguma forma material a curto prazo:

  • A Oracle conseguiu aproveitar a narrativa de que a TI do governo carece de competência, assim como os governos em geral
  • A Oracle preenche o ciberespaço com mensagens de marketing em geral e promove seus pontos de vista, portanto, é apenas uma questão de tempo até que a controvérsia seja dominada pelo ruído
  • A Oracle não parece ter sido afetada por falhas anteriores de alto perfil no governo

É provável que a ação judicial, combinada com fatores ambientais do ERP, como computação em nuvem, falta de penetração no mercado de PMEs, métodos de propriedade do cliente/busca de aluguel, prejudique a empresa no longo prazo:

No entanto, "é incongruente que uma empresa mundialmente respeitada como a Oracle permita que seus funcionários produzam um produto tão deficiente. De fato, o estado chega ao ponto de acusar a Oracle de "um padrão de atividade de extorsão que custou ao estado e à Cover Oregon centenas de milhões de dólares.”

E, como Tim Brugger destaca "não é provável que a Oracle seja responsabilizada por $5,5 bilhões nesse caso, independentemente de sua culpa pela bagunça do Obamacare no Oregon. Mas, à medida que mais detalhes forem revelados e os respectivos processos judiciais seguirem seu curso, qual será a receptividade de outros governos e grandes entidades privadas em contratar a Oracle?”

 

Tópicos

Contato