Atrapado por tu proveedor

 

Locked!

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

 

Problemas ocultos en la externalización de las TIC

En un post anterior ya comenté, al hilo de la revisión de un ya viejo informe (¿viejo 7 años?), algunos de los problemas, que en mi opinión, nos podemos encontrar en la externalización de las TIC.

En una etapa profesional anterior me tocó liderar algún que otro proyecto de implantación de externalización de las TIC (ITO por Information Technology Outsourcing se le llamaba a este tipo de proyectos) por lo que he podido experimentar (quizá sufrir sea una palabra más indicada) personalmente alguno de los problemas anteriormente citados y alguno más … los ocultos

Éstos problemas ocultos, generalmente son derivados, no de dificultades de los cambios organizativos o tecnológicos intrínsecos a estas movidas, sino de lo complejas que son a veces las organizaciones y relaciones humanas (it’s the Change Management, stupid!)… y son el objeto de esta entrada:

Efecto solidaridad vengativa: Ocurre con frecuencia que en un proyecto de externalización algunos puestos de trabajo devienen redundantes (eufemismo para decir que las personas que los ocupaban se van a la calle), y se crean nuevos, casi siempre ocupados por personas de la empresa de servicios adjudicataria del proyecto (de eso se trata, ¿no?).
La reacción de los que se quedan frente a los que llegan es frecuentemente de hostilidad, se creen que han de vengar a sus ex-compañeros y se aprovechan de la más mínima ocasión para quejarse y decir aquello de «esto es un desastre, antes estábamos mejor, … nos hacían más caso, … no resolvéis, …»

Efecto tú no eres de la empresa: Los recién llegados son vistos como externos, que no entienden las necesidades del negocio, que son meros proveedores, a los que se les puede tratar como eso: p… proveedores. Este hecho dificulta el intercambio de información, las relaciones del día a día, la confianza, etc.

Efecto todo está definido y queda registrado: Una condición imprescindible para que un proyecto de externalización de las TIC sea controlable y funcione, es que toda actividad y cambio sea registrada y siga unos procedimientos muy bien especificados. El resultado es que los usuarios se quejan de burocratización, lentitud, para todo hace falta llenar un formulario, etc.

Efecto ya no se puede mangonear como antes: Los empleados de la empresa que presta el servicio TIC externalizado no son tan fácilmente controlables como lo eran los ex-empleados que ocupaban esos puestos anteriormente (en base a relaciones informales o por línea jerárquica pura) . Se acabó aquello de «mírame el PC de mi hijo que no funciona» – caso inocente – o en un caso real que conocí (y que no era tan inocente) «borra todo rastro de ese e-mail que le envié a fulanito hace tres meses no vaya a ser que llegue una inspección judicial por la demanda que nos ha puesto el cliente ACME»

En conclusión, no todos los problemas de las externalizaciones vienen por los cambios tecnológicos y operativos. Hay que gestionar el cambio en las personas

10 razones para externalizar… o no

Ha vuelto a caer en mis manos un informe de hace unos años sobre «las 10 razones más frecuentes por las que las compañías externalizan» (Top 10 reasons Companies Outsource).

El artículo lo confeccionó, en 1998, el «Outsourcing Institute» a partir de una encuesta de la que no he podido encontrar los detalles técnicos de su elaboración, aunque he comprobado que ya no se puede encontrar en su site. (Si a alguien le interesa una copia que me mande un correo electrónico o sino ahí está papá google).

Me ha parecido interesante (y también morboso, confieso) revisitar el informe para ver qué cosas que se decían entonces se pueden seguir diciendo hoy. Y ciertamente me he encontrado que estas 10 razones aún están en vigencia (unas más que otras) aunque con algunas puntualizaciones

La primera razón aducida es la de reducir y controlar los costes operativos o literalmente tal como lo pone en el informe reduce and control operating costs.
Poco habría que decir en teoría sobre esta razón. Al fin y al cabo si firmas un contrato cerrado (tal servicio tal coste), parece que te puedas olvidar de revisar el presupuesto de IT más de dos veces al año. La realidad, me parece a mí, no es tan simple. Si hay un SLA que se queda corto, una nueva línea de negocio que surja, … dile al proveedor que te mejore sin coste el SLA a ver que te contesta.
Las grandes firmas que proveen de servicios de externalización siempre te proponen ahorros medios del 10 al 20% a tres o más años. La conclusión a la que llego es que esta razón parece seguir siendo válida (si nos creemos lo del 10-20%) pero siempre que:

  • el proceso de definición de la externalización se haga teniendo muy en cuenta al resto de las áreas de la compañía
  • que haya flexibilidad de renegociación de SLAs y se tenga un especial cuidado en la definición de estos SLAs, que al fin y al cabo van a ser los indicadores de gestión del servicio… o sea que ojo al proceso de negociación del contrato.

Otra pregunta que se puede hacer es si vale la pena «la movida» que supone una externalización incluso alcanzando ese «teórico» 10 a 20%.

Segunda razón: mejorar la focalización de la compañía o Improve Company Focus… no me acaba de gustar esta traducción.
Qué duda cabe que es deseable que todo el talento de la compañía se concentre en los procesos que aportan directamente valor al cliente y el resto dejárselo a especialistas para los cuales el cliente soy yo, y que se apliquen el cuento a ellos mismos.
Si aplicamos este razonamiento hasta el final, toda la cadena de valor de un determinado ámbito de negocio se transformaría en una sucesión de empresas que sólo se concentran en las tareas o procesos que aportan valor a sus clientes.
Este sería un buen punto de partida para quien se esté planteando la externalización de alguna área de la empresa para determinar qué actividades son, en principio, externalizables.

Tercera razón: Conseguir acceso a capacidades de la mejor clase o Gain Access to World-Class capabilities.
Se entiende que a bajo coste (ya que como nos dice el refrán «pagando San Pedro Canta»), y es aquí que para resolver la ecuación «bueno a bajo coste» puede que nos debamos ir a soluciones que o 1)implican cruzar límites geográficos (me viene en seguida a la cabeza las factorías de desarrollo de software de la India), 2) llevan a compartir infraestructuras (por ejemplo un centro de proceso de datos bunkerizado) que no estarían al alcance de cada una de las empresas usuario por separado.

Cuarta razón: liberar recursos internos para otros propósitos o Free internal resources for other purposes.
Esta razón la relaciono con la segunda (los recursos liberados los dedico a tareas que aporten más valor a la compañía) y quizá se pueda utilizar como factor de motivación del personal: desvío el «trabajo sucio» a los externos y me quedo con el «trabajo interesante» para los míos.

Quinta razón: la de acceder a recursos que no se tienen o Resources are not available internally.
Valga todo lo dicho para la tercera razón (Conseguir acceso a capacidades de la mejor clase), pero puntualizando que los que esgrimieron esta razón intuyo que daban más importancia al factor «bajo coste» que al factor «bueno» de la ecuación mencionada.

Sexta razón: Acelerar beneficios de reingeniería o Accelerate reengineering benefits.
Reconozco que en este punto he tenido que leer detenidamente el detalle del informe para entenderlo. Resulta, si lo he interpretado bien, que es algo así como «limpiando donde más sucio está es como verás mejor la limpieza».
Dicho más formalmente, externalizar es una forma de que la compañía se aperciba de los beneficios que la reingeniería de procesos puede traer ya que generalmente se externalizan las áreas que no son estratégicas o core y que por tanto, al haber sido históricamente relegadas frente a las estratégicas, son las más ineficientes y productivas, y claro está, donde más fácil y visible es obtener mejoras.
Yo además añadiría que externalizar una función implica, como paso previo, examinar en detalle su organización y procesos, lo que ya en sí mismo ayudará en la identificación de oportunidades de mejora.
Esta es una de las razones que me parecen algo desfasadas tras estos cinco años, no porque no sea actual la necesidad de mejorar los procesos de las compañías, sino por la utilización del concepto «reingeniería de procesos». Supongo que hay que entender que cuando se hizo el informe aún estaba de moda dicho concepto por lo que tocaba decir algo al respecto.

Séptima razón: la función externalizada es difícil de gestionar o está fuera de control o Function difficult to manage/out of control.
Me sorprende que esta razón la pueda esgrimir abiertamente alguien al que le están pagando para gestionar, directa o indirectamente, la función «conflictiva». La razón en sí, no me sorprende: simplemente ocurre. En mi experiencia profesional he conocido áreas a punto del derrumbe y que han sido salvadas, in extremis pero no sin sufrimiento, por su externalización a tiempo.
De todas formas que nadie piense que externalizar una función significa despreocuparse de ella ni mucho menos, puede que no tengas que estar en el día a día, pero en el «semana a semana» si deberías.

Octava razón: reducir la necesidad de inversión en capital o Make Capital Funds Available (la he traducido de otra forma que me ha parecido más clara).
Esta sí me parece una razón claramente vigente. Para ser flexible, ¿es preferible «pagar por usar a medida que lo necesito» o «comprar para tener y poder usar»?. Ejemplos se nos pueden ocurrir muchos: ¿es mejor comprar un servidor de correo más grande o ir contratando niveles de utilización de un ordenador del proveedor de servicios externalizados?, ¿se justifica incorporar en plantilla un técnico en un entorno técnico determinado o es mejor pagar por horas de un técnico de un proveedor de servicios?, …
Además suele haber otros motivos que no son de índole operativa, que hagan que pueda ser preferible «gastar» que «invertir». Se me ocurren motivos fiscales, razones contables, de presentación de información financiera,…

Novena razón: Compartir riesgos o Share Risks (he dudado en traducirlo como así tengo a otro a quien echarle la culpa)
Puede parecer que al utilizar la infraestructura y personal del proveedor de servicios compartes (yo diría que casi le traspasas) el riesgo asociado. Esta razón puede ser engañosa, ya que en efecto, puede parecer que ya que el proveedor de servicios se compromete con un acuerdo de nivel de servicio, si le pasa algo a sus infraestructuras, ya se espabilará. Cuidado con esto ya que, por ejemplo, poco consuelo podrás obtener de cobrarle la multa por incumplimiento del SLA si no has podido servir a tus clientes durante 2 días.
En otra clave añadiría que esta razón también se podría interpretar como «así hay otro al que le puedo echar la culpa si pasa algo», pero claro esta interpretación no se puede decir abiertamente, pero… ¿a que la han pensado?

Décima razón: una externalización puede suponer una entrada de contado o Cash Infusión.
Se alega en el informe que en algunos procesos de externalización se puede llegar a recibir capital, contante y sonante, como consecuencia de la venta de activos del área externalizada al proveedor del servicio. De todas las razones, ésta es la que me parece más discutible, incluso extravagante, y en todo caso, seguro que muy restringida a casos particulares. Lo que parece de sentido común es que aunque el proveedor del servicio te pague por los activos que absorba, ya se los cobrará de una forma u otra,…¡si no vaya negocio!.
Supongo que se referirá a que en algún caso específico puede ir bien una inyección de cash para la compañía, aunque luego se devuelva con creces al proveedor del servicio (algo así como una financiación encubierta).

Conclusión
Una vez repasadas la 10 razones, me sorprende constatar que, en estos tiempos donde el usuario es Dios, ninguna de ellas haga referencia a los usuarios de los servicios de IT. No aparecen expresiones equivalentes a la tan en boga hoy en día de «incrementar la satisfacción de los usuarios» o esa horripilante frasecilla de «mejorar la experiencia del usuario».

Lo que he intentado transmitir al hilo de estas reflexiones es que cualquier combinación de estas razones puede justificar, a priori, acometer un proceso de externalización pero siempre se deberán tener en cuenta los diversos factores y condicionantes que hemos ido repasando para cada una de ellas y que a modo de resumen citaría como los más importantes 1) prestar atención al proceso de negociación del contrato, y 2) considerar al resto de áreas de la empresa

En fin, repasar este viejo informe (pero vigente con matices) espero que haya servido como ejercicio de reflexión para aquellos que se estén planteando alguna externalización, que si hemos de creer a las encuestas y estudios que circulan son ya una mayoría entre las mesnadas directivas.

Uso de cookies

Este sitio web y subdominios asociados utilizan cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies

ACEPTAR
Aviso de cookies