Pillado por un proveedor

Estar pillado por un proveedor o estar "casado con un proveedor" es lo que le pasa a una institución pública o empresa que no ha puesto los medios para evitar que ese proveedor realice sistemas informáticos incompatibles con a estándares y técnicas de desarrollo abiertos, mantenibles y reutilizables.

Con el paso de los meses y los años la única empresa capacitada para dar soporte es el proveedor original y el cliente u organismo público debe aceptar las condiciones que le imponga este proveedor, aunque sean draconianas e inmorales.

Con las metodologías y librerías de software existentes hoy en día, esto no debería pasar, es una señal habitual de proyectos pésimamente gestionados que ocurran este tipo de problemas.

Casos públicos conocidos

• Cualquier organismo que esté usando SAP
  • SAP TRM en Barcelona
  • SAP-TRM en Madrid

• Indra e Ibermática con el Gobierno Vasco por el sistema JustiziaBat.

"¿Por qué les contratamos nuevamente? Si no se nos caería la informática judicial. Es un sistema cautivo. Sólo ellos saben los códigos. Perderíamos muchos millones de euros [en empezar de cero]", ha subrayado.

• Avalon con Lexnet entre 2010 y 2015

¿Cómo un proveedor consigue pillarme?

Existen muchas cosas que una institución publica o empresa hace para estar pillado por un proveedor:

• Permitir que los lazos personales y las comisiones bajo cuerda influyan en la toma de decisiones técnicas.
• Hacer pliegos de prescripciones técnicas muy genéricos que sirven para "meter goles" al cliente.
• No exigir en los pliegos al proveedor que entregue todos los artefactos incluidos:
  • código fuente,
  • librerías,
  • ejecutables,
  • herramientas de desarrollo,
  • documentación,
  • BBDD de requisitos,
  • diagramas de trazabilidad,
  • ficheros maestros del sistema de control de versiones,
  • scripts de generación de bases de datos,
  • licencias y
  • plazo de duración de las mismas, fechas de caducidad de certificados digitales, etc...
• Firmar contratos donde no se especifiquen las condiciones indicadas en el punto anterior.
• No almacenar eficientemente los entregables comentados en el punto anterior y por lo tanto depender del proveedor para que los facilite en el futuro.

Los 4 grandes y su obsesión por la retención del cliente

Las 4 grandes empresas proveedoras de software son:

• IBM
• Oracle
• SAP y
• Microsoft
• Actualmente habría que añadir a los servicios de Cloud que ofrecen implementaciones propietarias de su software, especialmente Amazon aparte de Azure de Microsoft y Google Cloud

Y sus principales consultoras asociadas o relacionadas son

• Indra
• Everis
• Deloitte
• Accenture
• Viewnext y
• los Integradores de SAP

Estas empresas pugnan entre ellas por vender cuantos mas productos sea posible vender a sus clientes con el fin de retenerlos de por vida. . Es por lo tanto responsabilidad de los clientes encargarse de que no estén pillados por productos "caja negra" de un solo proveedor, esto está muy relacionado con la falta de respeto que estas y otras empresas demuestran por los estandares.

Como dejar de estar pillado

Existen muchos proyectos de software que se desarrollan principalmente o colateralmente para quitarse de encima a un proveedor concreto. Por ejemplo en la década de 2000 eran habituales los proyectos de integración ESB o migración de datos ETL que pretendían sacar datos de sistemas SAP.

Como los vendors dificultan la exportación de datos con todo tipo de técnicas es habitual que los procesos de exportación sean cada más creativos, por ejemplo algunas empresas se dedican a hacer screen-scraping de plataformas SAP para extraer todos los datos de la pantalla y tabularlos en un modelo de datos bien estructurado. En teoría los web services deberían permitir esto, pero siempre existe algún motivo técnico para que la exportación de datos no sea trivial desde SAP.

Otro caso muy conocido de estar pillado es el uso de PL-SQL y UDF en BBDD comerciales, este tipo de procedimientos de código no son fácilmente portables a otros SGBD y requiere de un procedimiento de reescritura.

Realmente cualquier solución presenta dificultades de migración a otra solución, pero obviamente no todas dan problemas de la misma manera y el número de horas a dedicar no siempre es el mismo.