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
Hola Luis,
Interesante el tema que has sacado, justo ahora en plena vorágine de reducción de costes y presupuestos…
Visto desde el lado «cliente» parecen razonables tus propuestas pero estas llevan asociado un bloqueo a un amplio abanico de proveedores pequeños, más económicos o que estamos innovando en esas áreas.
Y es que a nosotros, evidentemente nos penalizará que que el producto está asociado al proveedor, el que los únicos que sabemos de verdad como funciona somos nosotros y que evidentemente no vamos a entregar el código fuente (¡Estamos hablando de soluciones SaaS, por dios! y no entremos en discusiones de OpenSoftware ni Wikinomics).
Por ello, estas posturas desde luego que ofrecen seguridad y son muy conservadores para un cliente, pero le impiden decantarse por soluciones novedosas y «arriesgadas» que en estos momentos pueden ser la respuesta diferenciadora frente a su competencia (toma publi-reportaje!).
Con ello no quiero ni mucho menos negar la necesidad (obligación diría yo) de diseñar los planes de contingencia, de salida desde el principio y negociar bien las condiciones de cancelación. Eso si, por mucho que tardemos 12 meses en desarrollar ningún cliente que conozca me quiere firmar un compromiso de preaviso de 12 meses. Me dan 3 y quejándose, claro yo les doy lo mismo, pero en estos tiempos ¿quien cancela un contrato a un cliente?
Luis, gracias por tus apreciaciones. Tienes toda la razón en que la visión del artículo es la de cliente y que es conservadora, pero no creo que estos «consejos» penalicen a proveedores innovadores de forma diferente a los no innovadores. La penalización de proveedores asociados a producto creo que será la misma para los innovadores y para los no innovadores, ¿no?
Otro tema: De tus palabras deduzco que no te cuadra entregar el código fuente si la solución es SaaS. ¿Por qué no? Imagínate un SaaS sobre un producto Open Source, ¿no lo ves posible? – este tema me interesa especialmente porque sorprendentemente, para mí al menos, conozco contados casos donde se produzca esa combinación, SaaS+Open Source
Sobre el preaviso: cierto, parece exagerado 12 meses de preaviso pero en ese caso, si no lo haces te quedas en manos de tus proveedores. Y me dices que ¿quién ahora cancela un contrato a un cliente? Pues ocurre, y tengo algún ejemplo cercano, cuando, precisamente por la crisis, el proveedor se concentra en sus clientes más rentables para poder «adelgazar» – a lo que voy es que más que facturar lo que hay que buscar es la rentabilidad. ¿Qué prefieres facturar 100 con margen -10 o facturar 60 con margen 5?
Sigamos debatiendo. Gracias
No me refería a proveedores innovadores frente a los que no. Innovando están las grandes y las pequeñas. Me refería a las pequeñas y nuevas frente a las grandes y conocidas. Uno puede cambiar de vendor de SAP o de Siebel, o de Salesforce. Pero difícilmente un pequeño/nuevo tiene un modelo en el que haya intermediarios y por tanto penaliza el riesgo proveedor+producto.
Respecto a Fuentes+SaaS a lo que me refiero es que puede tener cierto sentido el exigir a un proveedor que te instala en casa un software a medida que te entregue los fuentes (en nuestro modelo no lo hacíamos). Pero en este mundo en el que lo que el cliente paga en SaaS es un acceso mensual a una funcionalidad que enta implantada en una nube (muchas veces privada del proveedor) me cuesta mucho más verlo. Aunque por ejemplo extensiones de Salesforce, por ejemplo, puedo entenderlo. Pero ¿A que nadie le pide los fuentes a Salesforce? ¿O a Siebel? [humor: quiero cambiar el mundo pero nadie me deja el código fuente]
Evidentemente si tienes clientes muy «nocivos» pues habrá que solucionarlo, pero esa reducción de facturación lleva casi siempre asociado una reducción de plantilla, si no, no sale la ecuación. Y en ese caso muchas veces es mas rentable aguantar con el -10 que pagar las indemnizaciones para el 5. Recuerdo como en el sector de las artes gráficas muchas imprentas vendías a perdidas trabajos solo por seguir teniendo las máquinas en marcha, cuando de verdad perdían era al pararlas así que…
Hola Luis, lo que comento es que esa desventaja de los pequeños existe en todos los ámbitos, externalizados o no, es decir no está restringido al ámbito del artículo/post.
Respecto a lo del código fuente, me he expresado muy mal. Lo que quería enfatizar, más que entregar las fuentes, es que el producto (1) fuese conocido por el mayor número posible de proveedores y (2) cualquier desarrollo realizado lo pudiese mantener, sin trabas _legales_ ni técnicas, cualquier proveedor que se hiciese cargo del servicio después de la posible ruptura con el primer proveedor.
Me sorprende que no haya un extenso mercado de proveedores dando servicios SaaS con aplicaciones como OpenERP, SugarCRM, Nuxeo, por citar tres tipos de aplicaciones de gestión (ERP, CRM y KM). Algo de SugarCRM sí que he visto, pero en todo caso residual. Igual es una oportunidad de negocio por explotar o un post por escribir 🙂
Cada caso tendrá sus números y el ejemplo de las artes gráficas es extremo. El coste de despedir no es comparativamente tan elevado, sobre todo teniendo en cuenta las múltiples trapichuelas que hay para contratar en precario.
Gracias
Hola:
Muy oportuno e interesante el artículo.
La gestión de riesgos debe hacerse sobre todo aquello que pueda afectar al nuestro negocio y debe hacerse, como en los proyectos, desde el inicio y permanentemente realizando una inversión equilibrada respecto a la amenza que se vaya a gestionar.
Considero que una buena estrategia es mantener el ERP lo más ligero posible, evitando realizar personalizaciones que estén bien justificadas desde un punto de vista de negocio. Otra buena opción es observar la salud financiera del proveedor y la relación que mantenemos con él.
Saludos,
Ángel
Hola Ángel, bienvenido al blog. Buen apunte lo de mantener el ERP ligero para evitar dependencias futuras, un tema más a considerar.
Gracias
Muy interesante el artículo (tb la ppt de la PMI sobre metodologías ágiles con ERPs), e interesante la discusión sobre si perjudica o no estas precauciones a proveedores pequeños/medianos.
Personalmente creo que si un proveedor pequeño/mediano es capaz de vender un proyecto que toma 12 meses de implantación más otros de venta, ya no es tan pequeño/mediano, estamos hablando de proyectos ya más grandes.
Por otro lado, concuerdo con Angel en mantener el ERP ligero y en mirar la salud financiera del proveedor, y del mercado. Si hay riesgos y no tenemos cláusulas de preaviso de 12 meses, podemos – en la medida de lo posible – comenzar nuestra búsqueda y preparación del cambio antes del aviso.
Slds desde Chile.
En mi opinión a los clientes ya sea en saas o en modo convencional, sólo se les retiene por calidad de servicio / coste y cualquier otra treta sólo podrá retrasar la pérdida del cliente. Creo que hay que mirarlo como el equivalente a la productividad de una fábrica, pero en servicios / producto.
Ya existen productos de software libre en modo Saas como Sugar tal como decías, OpenErp, aunque creo que en este caso está restringido a los propios desarrolladores su uso en saas, pero por ejemplo Clickgest está basado en Iglobalgest (open source) y las condiciones de salida están fijadas de inicio, de forma que un cliente que quiera abandonar el modelo saas, pagará el importe del servicio y se le instalará la aplicación y sus datos en el servidor que él decida, pudiendo contratar nuestros servicios o los de cualquier tercero para su mantenimiento y además es perfectamente reversible sin perder ningún día de trabajo.
En cuanto a las mínimas personalizaciones posibles, si hablamos de SaaS «real», dichas personalizaciones estarán incluidas en los «datos de la empresa» y por tanto cuando el cliente se lleve sus datos, también se llevará sus personalizaciones.
Saludos
Pingback: Selección de aplicaciones SaaS de negocio. Puntos clave. Fin del servicio | NodoTIC