Es frecuente en el ámbito de los sistemas de información de gestión, el externalizar determinadas actividades o servicios como por ejemplo, por citar los más habituales, el mantenimiento correctivo y evolutivo de la aplicación (ERP, CRM, etc.) o la operación de las infraestructuras que soportan esas aplicaciones.
En el caso del mantenimiento correctivo y evolutivo parece lógico que sea el integrador que implantó la aplicación en cuestión el que luego se encargue de su mantenimiento, es decir de implementar los cambios que en el ciclo de vida de toda aplicación son necesarios para que evolucione, tanto tecnológica como funcionalmente. Y si dicho integrador tiene las capacidades para ello, pues también se le suele encargar de la operación de las infraestructuras pues así la empresa, además de aprovecharse de las sinergias de ambas actividades, se ahorra los problemas típicos de responsabilidad compartida (el echarse las culpas el uno al otro cuando algo falla, dicho de forma menos elegante)
En esa situación, insisto que bastante frecuente, sucede también lo que los sajones, siempre tan ocurrentes a la hora de poner nombre a las cosas, llaman el miedo al Vendor Lock-In. Es decir, miedo a quedar (atrapado) en las manos del proveedor y que si la empresa quiere cambiar, por mal servicio por ejemplo, no pueda o los costes y riesgos lo hagan poco aconsejable.
Este Vendor Lock-In se puede manifestar en las siguientes situaciones:
- Con el Producto: El proveedor es el dueño del producto, si cambias de proveedor tienes que cambiar de producto. Con el impacto que eso supone en la organización. Es lo que sucede en determinados modelos SaaS (Netsuite, Sales Force, EuHReka, SAP Business ByDesign, etc.)
- Desarrollos y extensiones: Cuando sólo el proveedor (porque fue él el que lo desarrolló) tiene el conocimiento de verdad (no lo que está documentado) sobre los desarrollos y modificaciones/personalizaciones que se le hicieron a la aplicación en el momento de su implantación.
- Datos: Cuando la empresa cliente tiene acceso restringido a las infraestructuras y depende del proveedor para que le entregue sus propios datos. Ocurre, en grado menor, cuando se externaliza la operación de las infraestructuras del sistema y por supuesto en modelos SaaS. Un caso extremo sería en un modelo de externalización de las operaciones o BPO, por ejemplo la nómina, donde el control último de qué datos hay en el sistema lo tiene el proveedor.
Es obvio, y de aquí este artículo, que las compañías deben intentar evitar esta dependencia extrema de sus proveedores y aunque cada caso tendrá sus particularidades y debería ser tratado de forma individualizada – se aceptan peticiones 🙂 – me atrevo a reflexionar en voz alta y exponer, para su debate, una serie de buenas prácticas al respecto.
(1) Negocia cuidadosamente las condiciones de salida en el momento de la venta del servicio.
Como le leí a no me acuerdo quien, la mejor manera de acordar los términos y condiciones de una separación es cuando te llevas bien con la otra parte. Y, creedme, hay pocos momentos donde te vas a llevar tan bien con tu proveedor como cuando está tratando de venderte algo. Este consejo también es aplicable a contratos prematrimoniales y a la constitución de una start up con más de un socio.
(2) Elabora un plan de riesgo desde el primer momento
No te asustes. Detrás de ese rimbombante nombre, básicamente hay dos cosas de sentido común:
- Identifica los riesgos, es decir los elementos que te atarían a tu proveedor o harían más difícil su sustitución. Una check list inicial sería:
- Software de base, producto, desarrollos (fuentes) sobre los que no tengas el control y/o acceso directo
- Conocimiento que no tienes: configuraciones, desarrollos, características de la instalación, …
- Acceso a tus datos, posibles restricciones, si se comparte infraestructura con otras compañías, contraseñas, etc..
- Compensaciones y condiciones de salida por rescisión de contrato
- Para cada riesgo identifica medidas para mitigarlo
- En el caso de desarrollos tener la propiedad intelectual de los mismos o al menos un compromiso de disponibilidad de los fuentes y objetos en caso de ruptura
- En el caso de productos, tener preferencia sobre productos abiertos y si son cerrados que haya la máxima disponibilidad de otros proveedores que lo conozcan. No es lo mismo que el producto sólo lo conozca su fabricante/implantador a que lo conozcan e implanten muchos integradores
- Con respecto a configuraciones y parametrizaciones, es en la fase de implementación cuando hay que adquirir el conocimiento sobre cómo se ha montado y se va a comportar el sistema, y dónde hay que tocar si se quiere que se comporte de otra forma.
- Con los datos no se juega. Este punto es particularmente crítico en el caso de externalización de la infraestructura tecnológica y no digamos ya en un modelo SaaS. Es imperativo tener bien atado, a nivel técnico, plazos y costes, como se van a recuperar los datos en caso de finalización del servicio.
(3) Ten previsto que todo va a cambiar
Incluir en el contrato con el proveedor, en la medida de lo posible, la opción de poder renegociar o revisar las condiciones o términos de separación. Un entorno cambiante puede hacer obsoleto cualquier acuerdo inicial.
(4) Gestiona la simetría de las condiciones de rescisión del contrato
No es lo mismo que el proveedor rescinda el contrato y te dé, por ejemplo 3 meses para que te vayas, que al revés. En este tipo de contratos, el esfuerzo y coste (no sólo monetario) que supone a una empresa cambiar de proveedor puede ser mucho mayor que el del proveedor si pierde el cliente.
He vivido alguna situación, de la que no voy a exponer aquí sus detalles obviamente, donde en el contrato no se especificaba para nada el tiempo de preaviso que debía dar el proveedor si rescindía el contrato unilateralmente (en caso contrario sí se especificaba). Automáticamente, en ese caso, se aplicaban, por simetría, las condiciones de si era el cliente el que rescindía el contrato. Pues resulta que si para implantar la aplicación se tardó, digamos, 12 meses, el tiempo de preaviso previsto era de 3 meses. Os podéis imaginar el problema enorme que tendría la empresa cliente si, en un caso extremo, el proveedor le da los tres meses a la empresa y ésta tiene sólo ese tiempo para poner en marcha un sistema equivalente.
Una buena regla es que el tiempo de preaviso por parte del proveedor sea al menos el tiempo que se tardó en poner en marcha el sistema más el tiempo estimado en buscar un proveedor y en cerrar un contrato con él.
(5) Prepárate ya durante el proyecto de implantación de la aplicación
Todo lo anterior no lo dejes para el final. Durante el proyecto de implantación tienes ya que actuar: empezar a negociar los términos del servicio posterior, asegurar que tu equipo conoce el sistema hasta donde quieras tener el control, asegurar la propiedad intelectual o el acceso a desarrollos, etc. Es durante la implantación cuando mejor se pueden ir identificando los riesgos y construyendo las medidas que te permitirán controlarlo.
Me encantaría conocer vuestras opiniones o experiencias. Estáis invitados a exponerlas en los comentarios. Gracias
