El fracaso de "Cover Oregon"/Oracle en perspectiva class=

El fracaso de "Cover Oregon"/Oracle en perspectiva

Publicado el en Sin categoría

Doug Hadden, Vicepresidente de Productos

El "Portada Oregón"el fracaso de la bolsa sanitaria ha sensacional "copia" - empezando por el "juego de culpar"y, ahora, demandas por ambas partes. El contratista, Oracle, alegando difamación por parte del Estado de Oregón. En estado alegando chantaje y facturación falsa por parte de Oracle. Un equipo SWAT federal encontró incompetencia en la gestión de Cover Oregon, mientras que Oracle "arrojó cuerpos en lugar de conjuntos de habilidades" en el proyecto. Existe un informe "denunciante"y algunas supuestas ley estatal. En Michael Krigman señala "En estos proyectos informáticos complejos, la mayoría de las veces es prácticamente imposible decir que la culpa o la responsabilidad recaen completamente en un lado o en otro Los dos lados están muy entrelazados durante la ejecución del proyecto."

Ha habido una falta de perspectiva en la información sobre el fracaso de este proyecto debido a la atención prestada a los aspectos sensacionalistas de la historia. Me gustaría añadir algo más de perspectiva:

  1. Algunos datos sobre la "Solución Oracle
  2. Los costes reales para el Estado
  3. Qué compra $240M+ en la industria del software
  4. La repercusión del $240M en la sanidad de Oregón
  5. Lo que podría haber evitado este fiasco

1. Portada Oregón es mucho más que un sitio web

  • Se ha hablado mucho de los problemas con el Obamacare desarrollado a medida y las soluciones Oracle COTS (Commercial-Off-The-Shelf) Cover Oregon como "sitios web"No se trata de simples "sitios web", sino de intercambios que requieren una gran cantidad de funciones administrativas, flujos de trabajo e integración.
  • La aplicación es de 2 proyectos: "HIX-IT" y "Modernización de los servicios sociales"
  • La aplicación clave utilizada fue Siebel Public Sector Case Management con Automatización de políticas de Oracle que tiene un conector Siebel

FreeBalance es socio de Oracle en middleware. Sin embargo, FreeBalance compite con Oracle en implantaciones de gestión financiera gubernamental, pero no con la suite Siebel CRM utilizada para Cubre Oregón. FreeBalance no proporciona una aplicación de software de intercambio de asistencia sanitaria. No es habitual que opine sobre competidores/socios por su nombre en este blog, pero creo que la perspectiva puede ayudar en el debate. Es muy probable que ambas partes tengan que dar explicaciones.

Oracle ha hecho algunas afirmaciones engañosas en su demanda:

  • "Oracle es una empresa con un historial de 30 años desarrollando e implantando con éxito algunos de los sistemas técnicos más complejos del mundo, incluidos los intercambios de seguros sanitarios de al menos media docena de estados." - Hay una gran diferencia entre "desarrollar" e "implantar". Oracle rara vez aplica estos sistemas. La afirmación también implica que Oracle ha desarrollado con éxito muchos intercambios de seguros sanitarios. ¿En qué estados? ¿Se utilizó el producto Siebel? ¿Se utilizó la base de datos Oracle y esto se presenta como un éxito? Lo único relevante aquí es si se utilizó con éxito la misma solución.
  • Oracle afirma que "los funcionarios públicos optaron por no dar una respuesta mesurada y plenamente informada" culpando a Oracle. Bienvenidos al mundo real: el software de aplicación es el elemento visible y, se lo aseguro, se culpará al proveedor de aplicaciones de los errores de integración de sistemas, middleware, hardware y red. O al personal de soporte interno que no siga las instrucciones sobre parches de seguridad o procedimientos de mantenimiento. 
  • Oracle alega que "el Estado emprendió así un proyecto en varias partes de un tamaño y una complejidad sin precedentes para el que no tenía experiencia". ¿Alguien puso una pistola en la cabeza de Oracle? De ser cierto, debería haber sido tan obvio entonces como lo es ahora. ¿Por qué aceptó Oracle el contrato? Está claro que la falta de conocimientos por parte del Estado era una razón de peso. afección preexistente.
  • Oracle hizo una presentación 2 meses antes de la fecha prevista indicando que los requisitos no estaban listos. Parece que no se completaron todos los requisitos en los casos en que las funciones de interfaz de usuario y seguridad no estaban listas. Hay requisitos que son "show-stoppers" - quizás los había. Supongamos que esto es cierto. ¿Es una "presentación" el lugar adecuado para ello? Seguramente Oracle debería haber estado comunicando en muchos otros canales antes de esta fecha. 
  • Oracle afirma que el Director Ejecutivo de Cover Oregon estaba más preocupado por el "chisporroteo que por el filete". Es ingenuo pensar que esto no ocurriría - es altamente predecible que esto ocurra en proyectos de front-office en el sector público y privado. Y Oracle ya debería saberlo.
  • Oracle afirma que el Estado "siguió frustrando los esfuerzos de Oracle en todo momento. No obstante, Oracle siguió trabajando a petición de Cover Oregon, intentando llevar el proyecto a buen puerto". Esto parece implicar que Oracle hacía ruido con el proyecto, pero no comunicaba el nivel de urgencia. Es normal que una empresa de implantación presente riesgos para protegerse en caso de que las cosas vayan mal. ¿El Estado consideró que Oracle estaba en modo "CYA"? 
  • Oracle argumenta que el contrato "tiempo y materiales" era apropiado en este caso. Oracle alega que "sin un alcance fijo para el proyecto -el equivalente a los planos arquitectónicos- no se podía esperar razonablemente que ningún contratista aceptara trabajar sobre una base de honorarios fijos". Y esto lo dice una empresa que, en teoría, ha realizado "media docena" de proyectos de este tipo y dispone de una solución estándar. ¿Decidió Oracle aprovechar la falta de capacidades estatales de gestión de proyectos para ampliar el plazo y los materiales? 
  • Además, usted CASI NUNCA obtener "planos arquitectónicos" en el gobierno R
    FP para contratos de precio fijo que utilizan software comercial. A veces se obtienen flujos de trabajo de procesos ("tal cual" y "por hacer") y modelos de bases de datos. A veces hay diagramas UML. Estos cambiar siempre durante la aplicación.

El Estado también ha afirmaciones interesantes:

  • Oracle mintió al Estado sobre la "Solución Oracle". Oracle mintió cuando dijo que la "Solución Oracle" podía satisfacer las dos necesidades del Estado con productos Oracle que funcionaban "listos para usar". Oracle mintió cuando afirmó que sus productos eran "flexibles", estaban "integrados", funcionaban "fácilmente" con otros programas, requerían poca personalización y podían configurarse rápidamente. Oracle mintió cuando afirmó que tenía "la solución más completa y segura en cuanto a la funcionalidad total necesaria para Oregón"'. El punto de partida de la discusión parece ser sobre las reclamaciones de ventas. Me parece que se puede argumentar, en relación con otras soluciones, que el software cumple muchas de estas afirmaciones. El punto clave es hasta qué punto hubo que modificar el código fuente: eso elimina toda la palabrería sobre lo que la gente entiende por "flexible" o "integrado".
  • Parece que Oracle decidió llamar "configuración" a los "scripts". El Estado afirma con razón que "la configuración no requiere que un desarrollador de software escriba código informático para lograr la funcionalidad". 'Oracle aclaró que puntuaba con un "4" su respuesta a los requisitos del DHS si sus productos cumplían el requisito "listos para usar sin modificaciones o mediante configuración rutinaria utilizando los conjuntos de herramientas suministrados con las aplicaciones * * *". Oracle alegó que la "configuración rutinaria" podía ser realizada por analistas de negocio y no requería que los ingenieros de software escribieran código de software o scripts.' Según Oracle, la "personalización" implicaba escribir scripts para crear nuevas funcionalidades. Los scripts son código de software que se ejecuta sobre aplicaciones de software.' Los scripts son programación, ya sean macros en una aplicación de Office, JavaScript, procedimientos almacenados o scripts de interfaz. Sin embargo, 'Oracle puntuó más de 95% de los requisitos del DHS con un "4", lo que indica que la "Solución Oracle" estaba 95% "lista para usar"'. 
  • Oracle afirmó haber progresado a lo largo del proyecto hasta casi el final, cuando se redujo el alcance. Esto parece contradecir la idea de que se introdujeron todo tipo de cambios de última hora. Es casi como si Oracle y Cover Oregon no estuvieran en el mismo proyecto.
  • Sin embargo, el Estado afirma que "a finales de septiembre, Oracle no pudo demostrar que el sitio web funcionaba". 1 o 2 semanas antes del lanzamiento es demasiado tarde para darse cuenta de esto. (Parece extraño que la solución no estuviera en la fase final de control de calidad en ese momento, cuando el número de fallos resueltos superaba al de nuevos fallos descubiertos).
  • Cúram Software, adquirida por IBM, era el único competidor en el proceso de adquisición, y se retiró del proceso (quizá porque las conversaciones con IBM invalidaron su oferta original porque la entidad empresarial estaba a punto de cambiar). ¿Estaban otros vendedores al tanto de la oportunidad? ¿Era el proceso realmente competitivo? ¿Conocían los demás vendedores los problemas previstos para el proyecto?
  • "En noviembre, los ejecutivos de Oracle siguieron afirmando a Cover Oregon que el sistema estaba casi listo para su lanzamiento". Aquí hay una desconexión significativa en la percepción y las comunicaciones. 
  • La reclamación del Estado es muy detallada. Una de las afirmaciones es que "Maximus, el consultor externo de garantía de calidad de Cover Oregon, también descubrió que el trabajo de Oracle estaba por debajo de los estándares del sector". En su informe de octubre de 2013, Maximus afirmó que los "procesos de Oracle no cumplen las normas del sector. El análisis de impacto, la revisión del código, los estándares de codificación y las técnicas adecuadas de desarrollo paralelo son ad hoc y se aplican o comprenden de forma incoherente."' De ser cierta esta afirmación, los errores se colarían fácilmente en un proyecto que tuviera una excelente articulación de los procesos de negocio.
  • Hay que tener en cuenta que las empresas de ERP presentan las soluciones como totalmente integradas y flexibles. Como señala Michael Krigsman "Cualquiera que conozca el software empresarial sabe que no se trata de términos absolutos.”

2. $240M no es el coste total

"$240 Millones" es la cifra más frecuente, pero no representa el coste total para el Estado.

3. $240M compra mucho desarrollo de software

$240M+ compra una cantidad significativa de desarrollo de software - es difícil justificar este coste aunque el programa funcionara.

  • $240M compra 1.000 años-persona de desarrollo de software suponiendo un coste de $20.000 al mes por persona que incluye salarios, prestaciones, equipamiento, formación y espacio. Eso es más que suficiente para construir software COTS para ambas funciones desde cero.
  • $240M cubre aproximadamente 1/24 del coste para Oracle de adquirir Siebele, incluso si se consideran los beneficios Portada Oregónes una cantidad importante para recuperar los gastos de adquisición. Los $5,5B reclamados por el Estado son casi tanto como el coste de adquisición de Siebel.
  • $240M supera el $110M recaudados por Salesforce.com al salir a bolsa y posiblemente podría cubrir la cantidad pagada por Infor adquiere Saleslogix - por lo que es lógico que el Estado pudiera haber comprado un proveedor de CRM.
  • $240M es aproximadamente 10 veces el coste de adquisición de un sistema básico de gestión financiera para un 3,9 millones de habitantes en el mercado internacional, estimado en $6 por persona. Por supuesto, las implantaciones en un país desarrollado son más sofisticadas, pero no 10 veces más sofisticadas, y no para una menor escala de funcionalidad.
  • $240M cubre el doble de los costes totales de implantación del ERP para Zambia 14,3 millones de personas (originalmente $26M, se amplió a $42M) y Vietnam 89,7 millones de personas (originalmente $40M, ampliado a $71M).

4. $240M+ tiene un impacto significativo en la asistencia sanitaria en Oregón

  • El PIB de Oregón se estimó en $168,6B en 2010 con unos costes sanitarios totales estimados en 17,9% en Estados Unidos lo que supone un gasto total de más de $30B o alrededor de $7.750 por residente y año, aproximadamente el coste total de mantener a 31.000 oregoneses.
  • $240M cubre casi la mitad del presupuesto del estado para "salud pública". 
  • $240M es más que la recaudación de la película "Patch Adams"estimado en más de $202M en todo el mundo.
  • Los $5,5B reclamados por el Estado servirán para equilibrar el presupuesto

5. Qué podría haber evitado este fiasco

  1. Software escrito para el sector privado experimenta problemas cuando se aplica en el sector público. Los fabricantes de software que operan en muchas industrias a menudo ven las similitudes en las necesidades del sector público, pero rara vez entienden las diferencias - y el complejidad de estas diferencias. Y, estos fabricantes aprovechan el mito de que "el gobierno debería funcionar más como las empresas.” Los compradores de la administración pública deben esperar hipérboles cuando los proveedores cuyos productos se crearon para el sector privado afirman tener una funcionalidad "lista para usar".
  2. En las implantaciones gubernamentales surgen muchos problemas cuando el proveedor de software no forma parte de la estructura de gobierno. En general, la plena participación del proveedor de software, como empresa consultora, es una buena señal. Es una buena señal si el proveedor aprovecha la experiencia para actualizar el software y adaptarlo a las necesidades específicas de un intercambio sanitario. Los proveedores de software, en general, no tienen incentivos para acumular ingresos por servicios porque esto devalúa la empresa. Sin embargo, el $240M es una gota en el océano para Oracle. Y es posible que Oracle no se haya comprometido a cambiar el producto, sino a aumentar los ingresos asociados al contrato de tiempo y materiales. "Oracle carecía de una estructura de rendición de cuentas que garantizara que el diseño del sitio web era factible dentro de los plazos asignados y que los plazos realmente se cumplían..”Las licencias parecen haber sido estimadas en $7M. Los compradores gubernamentales no deben comprometerse en contratos de tiempo y materiales más allá de los prototipos y deben esperar que los proveedores de software cambien los productos, no que los personalicen.
  3. Digamos que había demasiada incertidumbre como para esperar un contrato a precio fijo. Tenemos que aceptar que la funcionalidad "lista para usar" y las nociones de "flexibilidad" pregonadas por Oracle eran una hipérbole. El contrato por tiempo y materiales no parece ser el vehículo contractual adecuado, porque no existe el tipo de incertidumbre asociada a poner a alguien en la luna. O la incertidumbre en torno al famoso McDonnell Douglas A-12 o Avro Canada CF-105 Arrow proyectos. Un contrato de rendimiento podría haber sido más apropiado en este caso, en el que Oracle podría cobrar en función de los resultados. Eso podría haber cambiado los incentivos. Los compradores públicos deben seleccionar el método de contratación más adecuado en función del riesgo y la incertidumbre.
  4. La observación de que había 1.198 errores en el periodo de pruebas de aceptación es preocupante. Parece un número fenomenal de errores. Podría ser que no hubiera una reingeniería de procesos y que el personal de la Administración buscara pocos o ningún cambio de comportamiento con respecto al sistema heredado. O bien, el personal no articuló plenamente los requisitos por adelantado. Esto apunta a una falta de experiencia del proveedor en el campo. La articulación y el análisis de las necesidades ("como son" y "como serán") no debe ser un proceso genérico dirigido por expertos en software, sino por expertos en la materia. En otras palabras, personal de Oracle experto en seguros, sanidad, derecho (para entender el Obamacare) y finanzas públicas. Oracle tenía que aportar algo más que la experiencia en software de Siebel (por ejemplo: ¿por qué no aprovechar la adquisición de Skywire o el grupo de abogados que se dedican a perseguir a los clientes? Empresas de mantenimiento externas?). Los compradores públicos deben insistir en los expertos en la materia.
  5. Los proyectos de implantación suelen tener problemas. El estrés que conlleva suele sumir al cliente y al proveedor en la espiral de añadir más personal para intentar cumplir los plazos. Este planteamiento es casi siempre erróneo. Aumentar el tamaño de los equipos reduce la eficacia, una observación que ya se hizo en los años 60 con la Mes del Hombre Mítico. (También se tiende a evitar las ideas innovadoras y a experimentar un compromiso cada vez mayor con un proceso fallido). Nunca, nunca eches más gente a un proyecto que fracasa.
  6. Oracle alega que la gestión estatal del proyecto fue incompetente, al igual que la revisión federal. De acuerdo. La gestión de proyectos en el sector público tiende a ser inferior que en el privado. Oracle lo sabe. Conocen el riesgo. ¿Intentó Oracle crear capacidad? ¿Intentaron persuadir al Estado para que facilitara la información necesaria? ¿Han organizado talleres de gestión del cambio? Io importa lo deficiente que sea la gestión del proyecto por parte del gobierno: es el vendedor quien debe crear capacidad para superar el problema. Es dinero público.
  7. El plazo de ejecución de junio de 2011 a 1 de octubre de 2013 es de unos 18 meses. Es un calendario ajustado, pero razonable para un proyecto de este tipo en el que se utiliza software COTS. Es el tipo de calendario que necesita estrategias de detección y mitigación de riesgos. (Y necesita una gestión más ágil para probar prototipos y reglas de negocio por adelantado. De lo contrario, se acaba entregando algo que parece cumplir las especificaciones, pero que no satisface las necesidades: el infame problema de "como se diseñó". Los métodos de implantación en cascada son ineficaces en plazos ajustados. 
  8. El Estado alega que "La presidenta de Oracle afirmó que el intercambio había estado listo para lanzarse en febrero de 2014. Su afirmación interesada fue desmentida por las evaluaciones realizadas por expertos independientes." Es razonable pensar que Sra. Catz desconocía la verdadera situación basándose en los comentarios del equipo de implementación, una situación demasiado común en las grandes organizaciones. Es difícil ocultar que un cliente no está dispuesto a pagar. Tal vez, el equipo de Oracle decidió ro
    a sacado la artillería pesada en este momento. El equipo de Oracle debería haber sacado la artillería pesada mucho antes, en cuanto se adjudicó el contrato. Los ejecutivos deben estar al día sobre los contratos grandes, inusuales o altamente políticos, sobre todo cuando se trata de los tres. Se podría aconsejar a Oracle que utilizara Software Oracle Risk Management y las mejores prácticas de gestión de riesgos. Imaginemos que la Sra. Catz se hubiera puesto en contacto con el Estado cuando se hicieron evidentes los primeros problemas. Los compradores y proveedores de la Administración necesitan procesos eficaces de gestión de riesgos para los grandes contratos.
  9. Oracle no funciona como una organización "centrada en el cliente". No es una postura poco razonable para una empresa tecnológica. Sin embargo, hay muchas herramientas disponibles para que las empresas tecnológicas colaboren con las organizaciones - algunas tradicionales como la Primavera Enterprise, paquete de gestión de proyectos propiedad de Oracle, algunas basadas en redes sociales como la suite propiedad de Oracle. ¿Utilizó Oracle estas herramientas para la gestión de proyectos y la captación de clientes? En caso negativo, ¿por qué no? Los proveedores de software tienen que comerse su propia comida.
  10. El Estado alega que Oracle mostró una "patrón de actividad de crimen organizado." Es el tipo de hipérbole que se utiliza en los pleitos. Sin embargo, ha habido una preocupación por la consolidación de proveedores que está creando carteles donde los proveedores externos se están alineando con los proveedores de primer nivel. La cadena de valor de ERP para grandes implantaciones ha sido capturada predominantemente por estos dos proveedores. Los compradores públicos deben comprender el riesgo de no tener influencia sobre los grandes proveedores: se trata de una batalla asimétrica en la que los proveedores no necesitan los ingresos, tienen acceso a más recursos e información y cuentan con mejores abogados.

¿Las malas relaciones públicas perjudicarán a Oracle?

Es poco probable que esta demanda perjudique a Oracle de forma material a corto plazo:

  • Oracle ha sabido aprovechar la idea de que las TI gubernamentales carecen de competencia, al igual que los gobiernos en general.
  • Oracle llena el ciberespacio de mensajes de marketing en general y promueve sus puntos de vista, por lo que es sólo cuestión de tiempo que la controvesia se vea desbordada por el ruido
  • Oracle no parece haberse visto afectada por anteriores fracasos de alto nivel en la administración pública.

Es probable que la demanda, en combinación con factores del entorno ERP como la computación en nube, la falta de penetración en el mercado de las PYME, los métodos de propiedad de los clientes / búsqueda de alquiler perjudiquen a la empresa a largo plazo:

Sin embargo, "es incongruente que una empresa respetada en todo el mundo como Oracle permita a sus empleados fabricar un producto tan deficiente. De hecho, el Estado llega a acusar a Oracle de "un patrón de actividad de crimen organizado que ha costado al Estado y a Cover Oregon cientos de millones de dólares...".."

Y, como Tim Brugger señala "no es probable que Oracle tenga que pagar 1.500 millones en este caso, independientemente de su culpabilidad en el lío del Obamacare de Oregón. Pero a medida que se vayan descubriendo más detalles y las respectivas demandas sigan su curso, ¿hasta qué punto serán receptivos otros gobiernos y grandes entidades privadas a contratar a Oracle?”

 

Temas

Contacto