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

O fracasso do "Cover Oregon"/Oracle em perspectiva

Posted on em Uncategorized

Doug Hadden, VP de Produtos

O "Cobertura do Oregon" O fracasso do intercâmbio de cuidados de saúde provocou alguns sensacional "cópia" - começando com o "jogo da culpa" - e, agora, acções judiciais de ambas as partes. O contratante, a Oracle, alegando difamação por parte do Estado do Oregon. O Estado, alegando extorsão e facturação falsa por parte da Oracle. Uma equipa federal SWAT detectou incompetência na gestão da Cover Oregon, enquanto a Oracle "atirou corpos e não conjuntos de competências" para o projecto. Existe um relatório "denunciante" e algumas alegações de contornar lei estatal. Como Michael Krigman salienta "Nestes projectos complexos de TI, na maioria das vezes, é praticamente impossível dizer que a culpa ou a responsabilidade recai completamente sobre um ou outro lado..”

Tem havido uma falta de perspectiva nas reportagens sobre o fracasso deste projecto, devido à atenção dada aos aspectos sensacionalistas da história. Gostaria de acrescentar mais alguma perspectiva:

  1. Alguns factos sobre a "Solução Oracle"
  2. Os custos reais para o Estado
  3. O que o $240M+ compra na indústria de software
  4. O impacto do $240M nos cuidados de saúde no Oregon
  5. O que poderia ter evitado este fiasco

1. Cobertura do Oregon é muito mais do que um sítio Web

  • Tem-se falado muito sobre os problemas com as soluções Obamacare desenvolvidas à medida e as soluções Oracle COTS (Commercial-Off-The-Shelf) Cover Oregon como "sítios Web" - não se trata de simples "sítios Web", mas de intercâmbios que exigem uma quantidade significativa de funcionalidades de back-office, fluxo de trabalho e integração
  • A execução é de 2 projectos: "HIX-IT" e "Modernização dos serviços sociais"
  • A principal aplicação utilizada foi a Siebel Public Sector Case Management com Automação de políticas Oracle que tem um conector Siebel

A FreeBalance é um parceiro de middleware da Oracle. No entanto, o FreeBalance concorre com a Oracle nas implementações de gestão financeira governamental, mas não com o conjunto de CRM Siebel utilizado para Cobertura do Oregon. A FreeBalance não fornece uma aplicação de software de intercâmbio de cuidados de saúde. Não é habitual eu opinar sobre concorrentes/parceiros pelo nome neste blogue, mas penso que esta 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 nas suas acção judicial:

  • "A Oracle é uma empresa com uma história de 30 anos de sucesso no desenvolvimento e implementação 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 estes sistemas. A afirmação também implica que a Oracle desenvolveu muitas bolsas de seguros de saúde bem sucedidas. Em que estados? Foi utilizado o produto Siebel? Foi utilizada a base de dados Oracle e isso é apresentado como um sucesso? A única coisa relevante aqui é o tempo em que a mesma solução foi utilizada 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-vindos ao mundo real - o software de aplicação é o elemento visível - e, posso dizer-vos, o fornecedor da aplicação será responsabilizado por erros de integração de sistemas, middleware, hardware e rede. Ou o pessoal 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 empreendeu assim um projecto multipartes de dimensão e complexidade sem precedentes para o qual não tinha conhecimentos especializados". Alguém apontou uma arma à cabeça da Oracle? Se fosse verdade, deveria ter sido tão óbvio na altura como é agora. Porque é que a Oracle aceitou o contrato? É evidente que a falta de conhecimentos por parte do Estado foi uma condição pré-existente.
  • A Oracle fez uma apresentação dois meses antes da data prevista para o lançamento, indicando que os requisitos não estavam prontos. Aparentemente, nem todos os requisitos foram concluídos, sendo que as funções de IU e de segurança não estavam prontas. Há requisitos que são "show-stoppers" - talvez houvesse. Digamos que isto é verdade. Uma "apresentação" é o local adequado para isso? Certamente a Oracle deveria estar a comunicar através de muitos outros canais antes desta data. 
  • A Oracle alega que o director executivo da Cover Oregon estava mais preocupado com o "sizzle than the steak". É ingénuo pensar que isto não aconteceria - é altamente previsível que isto aconteça em projectos de front-office no sector 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 o momento. No entanto, a Oracle continuou a trabalhar a pedido da Cover Oregon, tentando levar o projecto a uma conclusão". Isto parece implicar que a Oracle estava a fazer algum barulho sobre o projecto, mas não comunicou o nível de urgência. É normal ouvir uma empresa de implementação apresentar riscos para os proteger caso as coisas corram mal. O Estado considerou que a Oracle estava em modo "CYA"? 
  • A Oracle defende que o contrato de "tempo e materiais" era apropriado neste caso. A Oracle alega que "sem um âmbito fixo para o projecto - o equivalente a plantas arquitectónicas - não se poderia razoavelmente esperar que nenhum contratante aceitasse trabalhar numa base de taxa fixa". Isto vindo de uma empresa que, teoricamente, já fez uma "meia dúzia" destes projectos e tem uma solução pronta a usar. Será que a Oracle decidiu aproveitar a falta de capacidades de gestão de projectos do Estado para prolongar o tempo e os materiais? 
  • Como ponto adicional - o QUASE NUNCA obter "projectos de arquitectura" no governo R
    PFs para contratos de preço fixo utilizando software de prateleira. Por vezes, obtém-se o fluxo de trabalho do processo ("como está" e "a ser") e modelos de bases de dados. Por vezes, há diagramas UML. Estes mudar sempre durante a execução.

O Estado também efectuou algumas afirmações interessantes:

  • 'A Oracle mentiu ao Estado sobre a "Solução Oracle". A Oracle mentiu quando disse que a "Solução Oracle" podia satisfazer ambas as necessidades do Estado com produtos Oracle que funcionavam "prontos a usar". A Oracle mentiu quando disse que os 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 no que respeita à funcionalidade total necessária para o Oregon". O ponto de partida para a discussão parece ser a alegação de vendas. Parece-me que se pode argumentar, relativamente a outras soluções, que o software satisfaz muitas dessas alegações. O ponto-chave é a medida em que o código-fonte teve de ser modificado - o que elimina toda a confusão sobre o que as pessoas entendem por "flexível" ou "integrado".
  • Parece que a Oracle decidiu chamar "scripts" de "configuração". O Estado afirma, com razão, que "a configuração não exige que um programador de software escreva código informático para alcançar a funcionalidade". A Oracle esclareceu que classificou a sua resposta aos requisitos do DHS com um "4" se os seus produtos satisfizessem os requisitos "prontos a utilizar sem modificação ou através de configuração de rotina utilizando os conjuntos de ferramentas fornecidos com as aplicações * * *". A Oracle alegou que a "configuração de rotina" podia ser efectuada por analistas empresariais e não exigia que os engenheiros de software escrevessem código ou scripts de software. De acordo com a Oracle, a "personalização" envolvia a escrita de scripts para criar novas funcionalidades. Os scripts são código de software que é executado em cima de aplicações de software.' Scripting é a programação de macros numa aplicação Office, JavaScript, procedimentos armazenados ou scripts de interface. No entanto, "a Oracle classificou mais de 95% dos requisitos do DHS com um "4", indicando que a "Solução Oracle" era 95% "pronta a utilizar"". 
  • A Oracle alegou progressos ao longo do projecto até perto do fim, quando o âmbito foi reduzido. Isto parece contradizer a noção de que foram introduzidos todos os tipos de alterações de última hora. É quase como se a Oracle e a Cover Oregon não estivessem no mesmo projecto.
  • O Estado afirma que "no final de Setembro, no entanto, a Oracle não conseguiu demonstrar um sítio Web funcional". 1 ou 2 semanas antes do lançamento é demasiado tarde para reparar nisto. (Parece estranho que a solução não estivesse no QA final nesta altura em que o número de bugs resolvidos excedia o número de novos bugs descobertos).
  • Cúram Software, adquirido pela IBMA IBM era o único concorrente no processo de aquisição e retirou-se do processo (talvez devido ao facto de as conversações com a IBM terem tornado a sua proposta original inválida porque a entidade empresarial estava prestes a mudar). Os outros fornecedores tinham conhecimento da oportunidade? O processo foi verdadeiramente competitivo? Os outros fornecedores estavam bem cientes dos problemas esperados do projecto?
  • "Em Novembro, os executivos da Oracle continuaram a afirmar à Cover Oregon que o sistema estava quase pronto a ser lançado." Há aqui uma grande desconexão na percepção e na comunicação. 
  • A queixa do Estado é muito pormenorizada. Uma das alegações é que "Maximus, o consultor externo de garantia de qualidade da Cover Oregon, também descobriu que o trabalho da Oracle estava abaixo dos padrões da indústria. No seu relatório de Outubro de 2013, a Maximus afirmou que os "processos da Oracle não cumprem as normas da indústria. A análise de impacto, a revisão do código, as normas de codificação e as técnicas adequadas de desenvolvimento paralelo são ad hoc e aplicadas ou compreendidas de forma inconsistente". Se esta afirmação for verdadeira, os erros poderiam facilmente entrar num projecto que tivesse uma excelente articulação de processos empresariais.
  • É de notar que as empresas de ERP apresentam as soluções como totalmente integradas e flexíveis. Como salienta Michael Krigsman: "Qualquer pessoa que conheça software empresarial sabe que estes não são termos absolutos.”

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

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

3. $240M compra muito desenvolvimento de software

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

  • $240M compra 1.000 pessoas-ano de desenvolvimento de software, assumindo um custo de $20.000 por mês por pessoa, que inclui salários, benefícios, equipamento, formação e espaço. Isto é mais do que suficiente para construir software COTS para ambas as funções a partir do zero.
  • $240M cobre cerca de 1/24 do custo para a Oracle da aquisição da Siebele, mesmo considerando os lucros sobre Cobertura do OregonO montante de $5,5B reclamado pelo Estado é quase igual ao custo de aquisição da Siebel. O montante de $5,5B reclamado pelo Estado é quase igual ao custo de aquisição da Siebel.
  • $240M excede os $110M angariado pela Salesforce.com quando da abertura do capital e, eventualmente, poderia cobrir o montante pago pela A Infor vai adquirir a Saleslogix - pelo que é lógico que o Estado poderia ter comprado um fornecedor de CRM.
  • $240M é cerca de 10 vezes o custo de aquisição de um sistema de gestão financeira de base para um população de 3,9 milhões no mercado internacional, estimado em $6 por pessoa. É claro que as implementações num país desenvolvido são mais sofisticadas - mas não 10 vezes mais sofisticadas, e não para uma escala mais pequena de funcionalidade.
  • $240M cobre o dobro dos custos totais de implementação do ERP para Zâmbia 14,3 milhões de pessoas (inicialmente $26M, que passou para $42M) e Vietname 89,7 milhões de pessoas (originalmente $40M, aumentou para $71M).

4. O $240M+ tem um impacto significativo nos cuidados de saúde no Oregon

  • O PIB do Oregon foi estimado em $168,6B em 2010 com custos totais de cuidados de saúde estimados em 17.9% nos Estados Unidos o que corresponde a uma despesa total de mais de $30B ou cerca de $7.750 por residente e por ano - aproximadamente o custo total do apoio a 31.000 habitantes do Oregon.
  • $240M cobre quase metade do orçamento do estado para a "saúde pública". 
  • $240M é mais do que as receitas de bilheteira do filme "Patch Adams" estimado em mais de $202M a nível mundial.
  • O pedido de $5,5B do Estado contribuirá em grande medida para equilibrar o orçamento

5. O que poderia ter evitado este fiasco

  1. Software escrito para o sector privado tem problemas quando aplicado no sector público. Os fabricantes de software que operam em muitas indústrias vêem muitas vezes as semelhanças nas necessidades do sector público, mas raramente compreendem as diferenças - e as complexidade destas diferenças. E estes fabricantes aproveitam-se do mito de que "o governo deve funcionar mais como uma empresa.” Os compradores governamentais devem esperar uma hipérbole quando os fornecedores cujos produtos foram criados para o sector privado afirmam ter uma funcionalidade "pronta a usar".
  2. Muitos problemas ocorrem nas implementações governamentais quando o fornecedor de software não faz parte da estrutura de governação. Em geral, a plena participação do fornecedor de software, como empresa de consultoria, é um bom sinal. É um bom sinal se o fornecedor estiver a utilizar a experiência para actualizar o software de modo a satisfazer as necessidades específicas de uma bolsa de saúde. Os fornecedores de software, em geral, não têm um incentivo para acumular receitas de serviços porque isso desvaloriza a empresa. No entanto, o $240M é uma gota no balde para a Oracle. E a Oracle pode não ter estado empenhada em mudar o produto, mas sim em aumentar as receitas associadas ao contrato de tempo e materiais. "A Oracle não dispunha de uma estrutura de responsabilização para garantir que a concepção do sítio Web era exequível dentro dos prazos atribuídos e que os prazos estavam efectivamente a ser cumpridos.”As licenças parecem ter sido estimadas em $7M. Os compradores governamentais não devem celebrar contratos de tempo e materiais para além dos protótipos e devem esperar que os fornecedores de software alterem os produtos e não os personalizem.
  3. Digamos que havia demasiada incerteza para esperar um contrato de preço fixo. Temos de aceitar que as noções de funcionalidade "out of the box" e "flexibilidade" apregoadas pela Oracle eram uma hipérbole. O tempo e os materiais não parecem ser o veículo contratual adequado, porque não existe o tipo de incerteza associado a colocar alguém na lua. Ou a incerteza em torno do famoso McDonnell Douglas A-12 ou Avro Canada CF-105 Arrow projectos. Um contrato de desempenho poderia ter sido mais adequado neste caso, em que a Oracle poderia ser paga com base nos resultados. Isso poderia ter alterado os incentivos. Os compradores governamentais têm de seleccionar o método de contrato mais adequado com base no risco e na incerteza.
  4. A constatação de que havia 1.198 erros no período de teste de aceitação é preocupante. Parece tratar-se de um número fenomenal de erros. Pode ser que não tenha havido uma reengenharia de processos em que o pessoal do governo estivesse à espera de pouca ou nenhuma mudança de comportamento em relação ao sistema antigo. Ou então, o pessoal não articulou completamente os requisitos à partida. Isto aponta para uma falta de experiência do vendedor no domínio. A articulação e análise das necessidades ("as-is" e "to-be") não deve ser um processo genérico liderado por especialistas em software - deve ser liderado por especialistas no domínio. Por outras palavras, pessoal da Oracle que fosse especialista em seguros, cuidados de saúde, direito (para compreender o Obamacare) e finanças públicas. A Oracle precisava de trazer mais para a mesa do que a experiência em software Siebel (ou seja: porque 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 públicos devem insistir em especialistas no domínio.
  5. Os projectos de implementação deparam-se frequentemente com problemas. O stress envolvido faz com que o cliente e o fornecedor entrem frequentemente na espiral de adicionar mais pessoal para tentar cumprir os prazos. Esta abordagem é quase sempre incorrecta. Aumentar o tamanho da equipa reduz a eficiência, uma observação feita na década de 1960 com o Mês do Homem Mítico. (Existe também a tendência para evitar ideias inovadoras e para se comprometer cada vez mais com um processo falhado). Nunca, nunca, nunca se deve atirar mais pessoas para um projecto que está a falhar.
  6. A Oracle alega que a gestão do projecto do Estado foi incompetente, tal como a revisão federal. Está bem. A gestão de projectos no sector público tende a ser inferior à do sector privado. A Oracle sabe disso. Eles conhecem o risco. A Oracle procurou criar capacidade? Tentaram persuadir o Estado a fornecer as informações necessárias? Realizaram workshops de gestão da mudança? INão importa se a gestão do projecto é deficiente por parte do governo - cabe ao fornecedor criar capacidade para ultrapassar 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 cerca de 18 meses. Trata-se de um calendário apertado, mas razoável, para um projecto deste tipo quando se utiliza software COTS. É o tipo de cronograma que precisa de estratégias de detecção e mitigação de riscos. (E precisa de uma gestão mais ágil para testar protótipos e regras de negócio antecipadamente. Caso contrário, acaba-se por entregar algo que parece cumprir as especificações, mas que não satisfaz as necessidades - o infame problema do "as designed". Os métodos de implementação em cascata são ineficazes em prazos apertados. 
  8. O Estado alega que "A presidente da Oracle afirmou que a bolsa estava pronta para ser lançada em Fevereiro de 2014. A sua afirmação em causa própria foi desmentida por avaliações efectuadas por peritos independentes." É razoável pensar que Sra. Catz não tinha conhecimento da situação real com base no feedback da equipa de implementação - uma situação demasiado comum nas grandes organizações. É difícil esconder o facto de um cliente não estar disposto a pagar. Talvez a equipa da Oracle tenha decidido
    A equipa da Oracle devia ter lançado a arma grande nesta altura. A equipa da Oracle deveria ter lançado a grande arma muito mais cedo no processo, assim que o contrato foi adjudicado. Os executivos precisam de estar actualizados sobre contratos grandes, invulgares ou altamente políticos - certamente quando se trata dos 3. A Oracle pode ser aconselhada a usar Software Oracle Risk Management e as melhores práticas de gestão de riscos. Imaginem se a Sra. Catz tivesse contactado o Estado quando os primeiros problemas se tornaram evidentes. Os compradores governamentais e os parceiros fornecedores necessitam de processos eficazes de gestão do risco para os grandes contratos.
  9. A Oracle não funciona como uma organização "centrada no cliente". Esta não é uma posição descabida para uma empresa de tecnologia. No entanto, existem muitas ferramentas disponíveis para as empresas de tecnologia colaborarem com as organizações - algumas tradicionais como a Primavera Enterprise Project Management Suite propriedade da Oracle - alguns baseados em redes sociais como o suite propriedade da Oracle. A Oracle utilizou estas ferramentas para a gestão de projectos e o envolvimento dos clientes? Se não, porquê? Os fornecedores de software precisam de comer a sua própria comida de cão.
  10. O Estado alega que a Oracle exibiu uma "padrão de actividade de extorsão." Este é 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á a criar cartéis em que os fornecedores terceiros estão a alinhar-se com os fornecedores de nível 1. A cadeia de valor ERP para grandes implementações tem sido predominantemente capturada por estes dois fornecedores. Os compradores governamentais têm de compreender o risco de não terem qualquer influência sobre os grandes fornecedores - trata-se de uma batalha assimétrica em que os fornecedores não precisam de receitas, têm acesso a mais recursos e informações e têm melhores advogados.

Será que estas más relações públicas vão prejudicar a Oracle?

É pouco provável que esta acção judicial prejudique a Oracle de uma forma material a curto prazo:

  • A Oracle tem conseguido aproveitar a narrativa de que as TI governamentais carecem de competência, tal como os governos em geral
  • A Oracle enche o ciberespaço com mensagens de marketing em geral e promove os seus pontos de vista, pelo que é apenas uma questão de tempo até que a controvérsia seja dominada pelo ruído
  • A Oracle não parece ter sido afectada por anteriores falhas de alto nível na administração pública

É provável que a acção judicial, em conjugação com factores ambientais do ERP, como a computação em nuvem, a falta de penetração no mercado das PME e os métodos de apropriação/aluguer por parte dos clientes, prejudique a empresa a longo prazo:

No entanto, "é incongruente que uma empresa mundialmente respeitada como a Oracle permita que os seus empregados produzam um produto tão deficiente. De facto, o Estado vai ao ponto de acusar a Oracle de "um padrão de actividade de extorsão que custou ao Estado e à Cover Oregon centenas de milhões de dólares.”

E, como Tim Brugger salienta "não é provável que a Oracle seja responsabilizada por $5,5 mil milhões neste caso, independentemente da sua culpa na confusão do Obamacare no Oregon. Mas à medida que mais pormenores forem sendo revelados e os respectivos processos judiciais forem decorrendo, qual será a receptividade de outros governos e grandes entidades privadas para contratar a Oracle?”

 

Tópicos

Contacto