Offshore Gestión de riegos en el desarrollo

El uso de factorías de software puede aportar

importantes ventajas, principalmente relacionadas con

el precio aunque en ocasiones también con la calidad.

En el proceso de localizar fuerzas de desarrollo al mejor

precio, han ido apareciendo ofertas muy

competitivas procedentes de países emergentes

que, aprovechando sus cada día más preparados

técnicos, los bajos salarios y las diferencias en el

cambio de moneda, ofrecen precios extremadamente

competitivos con niveles de calidad razonables.

Cuando una organización se plantea afrontar un

desarrollo o mantenimiento en modalidad offshore, suele

disponer de una cierta experiencia en otras

modalidades de Outsourcing local. A pesar de estas

experiencias, el trabajo en el entorno offshore

conlleva nuevos retos que deben ser afrontados de

una forma clara.

Este documento trata de la gestión de riesgos en la

dirección de proyectos y mantenimientos en un entorno

offshore. Aprovechar las ventajas en costes que

ofrecen países emergentes para la gestión del

mantenimiento de aplicaciones esconde

problemas, oportunidades y retos que deben

tenerse en cuenta desde un principio, a fin de

evitar dificultades en el servicio y aprovechar al

máximo la inversión.

No delegue ciegamente en el proveedor la

totalidad del proceso, como si se tratase de un

eslabón ajeno a sus competencias, sólo por

disponer un mejor precio. Las claves del offshore

pueden condicionar fuertemente las suyas: no se

trata de un simple proceso de optimización en las

operaciones del proveedor, afecta a toda la

cadena, incluido el cliente.

La visión global no concierne exclusivamente al

ámbito geográfico, también afecta al cultural y

metodológico. Aun cuando tengamos experiencias

en el uso de Factorías de Software y hayamos

podido superar algunas de las dificultades de este

modelo, el trabajo con personas de otros países,

culturas e incluso idiomas, hace aún más compleja

esta gestión.

Vamos a realizar un repaso abierto y no

exhaustivo a algunas de las preguntas que

debería hacerse antes de abordar un Offshore IT

Outsourcing. Como siempre que se habla de

riesgos, se corre el peligro de ofrecer una visión

negativa o pesimista. El Offshore es una

oportunidad, por tanto realizar una gestionar

activa sobre los riesgos que conlleva es clave

para aprovechar sus ventajas y evitar sus

inconvenientes.

Intro

ducc

ión ¿Cómo afrontar el Offshore IT Outsourcing?

Riesgos

Es importante ser conscientes de qué forma se llega una

organización a trabajar con un centro offshore.

Se puede llegar al offshore como parte de una

decisión estratégica donde se han valorado todas

las ventajas e inconvenientes de esta modalidad de

trabajo y las fortalezas y debilidades de la

organización, enmarcando este tipo de contrato

dentro de una política general en el Gobierno de TI.

Pero en más ocasiones de las que en principio pueda

parecer, al offshore se llega como consecuencia

táctica en la necesidad de ahorro de costes en el

desarrollo y mantenimiento de software.

Es habitual en el caso de una decisión estratégica, y

menos frecuentemente en una decisión táctica, el

realizar una evaluación de los riesgos y que se

contemplen los principales problemas que se pueden

encontrar. Es posible que finalmente se materialicen

riesgos, problemas o costes ocultos no previstos

inicialmente, pero en general la reflexión previa

permitirá realizar una gestión rápida de estos

imprevistos.

En ocasiones se produce un efecto muy complejo de

gestionar, que denominaríamos offshore

sobrevenido, y suele ser consecuencia de un

proceso de negociación o reducción presupuestaria

que hace que el proveedor tome la decisión de

realizar un offshore de parte de sus operaciones

sin que el cliente haya sido consciente o

suficientemente informado de esta circunstancia.

Aunque el proveedor insista que el se encarga de

todo y que no hay nada de que preocuparse, lo cierto

es que todos los actores del proceso se ven

involucrados en esta decisión y es necesario hacer

la mismas reflexiones y revisar todos los riesgos que

conlleva un desarrollo offshore.

En todos los casos se debe evitar afrontar un

proceso de offshore de forma poco reflexiva llevados

por la simple necesidad de un ahorro de costes. Para

que estos ahorros de costes sean reales, se debe

abordar el offshore dentro de una visión general

de las políticas del Gobierno de TI.

Orige

n ¿Cómo se llega al offshore?

Decisión estratégica o resultado táctico

Aunque en ocasiones pueda parecer que los proyectos y

el mantenimiento se pueden gestionar en offshore de

igual forma, los problemas y riesgos pueden ser

diferentes.

En el caso de los proyectos es posible que la existencia

de un proveedor local permita minimizar el impacto en

el cliente, evitando que este tenga contacto directo con

los centros de offshore, sobre todo si se centran en

labores de desarrollo muy concretas en modalidad de

factoría de software.

En las relaciones a largo plazo, como el mantenimiento

o grandes proyectos, es mucho más complicado

aislar al cliente de los centros offshore. Aun cuando se

hayan establecido mecanismos de comunicación

formales que den la impresión que todo se realiza en

España, la gestión de situaciones excepcionales, la

resolución de incidencias o la necesidad de aclaraciones

harán necesaria la comunicación directa en algún

momento.

En los proyectos puede llegar a ser asumible dentro

de la planificación de una sobrecarga por el offshore

en la gestión de la calidad, la traducción o revisión de

los documentos y del software o la gestión de la

comunicación interna, realizando una exhaustiva

gestión de actividades en paralelo.

En los procesos de producción continua -como los

servicios de mantenimiento- la introducción de estos pasos

extra por el offshore puede afectar de forma significativa

en los tiempos de entrega de cada petición. En los casos de

trabajos urgentes puede llegar a ser imposible de gestionar

esta sobre carga en el proceso, por lo que deben

establecerse mecanismos optimizados para estas

circunstancias.

En la gestión externalizada del mantenimiento de

aplicaciones en offshore, el proceso de transferencia de

conocimiento puede llegar a realizarse en varias etapas,

siendo necesario trasferir el conocimiento funcional, la

documentación técnica, la de diseño y el código a un

proveedor local, para que este a su vez envíe parte de esta

información al centro offshore.

Las experiencias en proyectos offshore no pueden

trasladarse directamente al mantenimiento offshore. Si

bien ambos comparten algunos aspectos, las relaciones a

largo plazo con centro offshore deben ser planteadas con

mayor detenimiento y deben contemplar con más claridad una

gestión integrada del offshore.

Activ

idad

¿Cuál es el alcance?

Proyecto o mantenimiento

En ocasiones se tiende a pensar que cualquier servicio,

aplicación o sistema puede ser gestionado en

outsourcing. En la práctica, los condicionantes y

características de la aplicación o sistema

condicionan nuestra capacidad para gestionarlo de

forma externalizada.

En este sentido debemos realizarnos algunas preguntas

sobre la aplicación o sistema que vamos a externalizar.

Estas preguntas serán contestadas de forma diferente

por cada organización y por lo tanto son sólo una vía

para la reflexión.

¿Cuál es el nivel de criticidad de su cobertura

funcional? Es decir, si tiene un papel crítico en la

cadena de valor de la empresa o da servicio a procesos

auxiliares y de soporte. No es lo mismo externalizar la

aplicación de soporte de un proceso secundaria, que

externalizar una aplicación de alta criticidad. Si es un

sistema crítico, la diferencia horaria o la necesidad de

gestionar todas las peticiones por escrito pueden

dificultar la respuesta en casos de urgencia.

¿Qué nivel de confidencialidad tiene la información que

maneja? Si la información gestionada es crítica, es posible

que fuera necesario reforzar las medidas de seguridad para

evitar el acceso a esta información por personal ubicado en

otros centros, e incluso en terceros países.

¿Quiénes son los usuarios finales? ¿Quiénes son los

usuarios prescriptores? En muchas ocasiones no se

diferencian ambos, pero en otras los usuarios que utilizan la

aplicación difieren de los que dicen qué debe hacer. Las

características de los usuarios prescriptores deben ser

contempladas a la hora de afrontar una externalización.

¿Cómo se realiza el proceso de gestión de la demanda?

Es necesario conocer cómo hacen las peticiones los usuarios,

quién las atiende y cómo se traspasan al proveedor, así como

qué herramientas se utilizan en todo estos pasos. Todas

estas preguntas pueden llegar a ser relevantes en el caso de

que sea necesario establecer comunicaciones directas entre

el equipo del cliente y el centro de offshore.

Objet

ivo

¿Qué es y para que se utiliza?

Sistema, aplicación, servicio…

El nivel de madurez (nueva, estable, obsoleta) de la

aplicación es relevante a la hora de afrontar una

gestión externalizada. En principio, una aplicación

nueva puede disponer de mayor y más actualizada

documentación que permita la transferencia de

conocimiento al centro offshore, pero habitualmente es

susceptible de sufrir una gran cantidad de adaptaciones

hasta llegar a su nivel de estabilidad. En el caso de una

aplicación obsoleta, que haya recibido una gran cantidad

de modificaciones y cuya documentación no esté

actualizada, presenta características que complican o

dificultan la etapa de transferencia de conocimiento.

De igual forma, la tecnología utilizada y nivel de

madurez técnica de la aplicación pueden

condicionar la externalización. La utilización de

tecnologías muy recientes o ya obsoletas dificultarán la

localización de personal técnico disponible con la

suficiente experiencia para los centros de offshore. Por

el contrario, la utilización de tecnologías consolidadas y

con una fuerte base de técnicos facilita la dotación de

personal en los centros de offshore. Debemos revisar si

la formación del personal de los centros de offshore se

convierte en un factor crítico para el éxito del servicio.

La interconexión y dependencia con otros sistemas de la

organización puede complicar la gestión externalizada.

Es necesario conocer el nivel de acoplamiento de la

aplicación con otros sistemas de la empresa a fin de

identificar canales de comunicación necesarios y quizás no

identificados inicialmente. La utilización de elementos como

librerías comunes, frameworks y módulos generales también

tienen que ser tenidos en cuenta. Todas estas

interconexiones afectarán a la transferencia de conocimiento,

gestión de la calidad, pruebas de regresión y estabilidad,

versionado, gestión de cambios, etc.

Objet

ivo

¿Cuáles son sus principales características?

Sistema, aplicación, servicio…

Como en cualquier proceso de contratación, la selección de un

proveedor que nos acompañe como socio en el offshore es un

elemento clave. Debemos establecer cómo vamos a realizar este

proceso y cuáles van a ser los principales aspectos a valorar.

En primer lugar debemos decidir si queremos disponer de un socio

local o podemos trabajar directamente con el centro de offshore.

Trabajar con un socio local en general facilitará la gestión,

simplificará los contratos y nos permitirá aprovechar su experiencia

en la gestión con centros offshore, aunque aumentará en algo los

costes.

Trabajar directamente con un proveedor offshore nos permite

obtener el mejor precio, pero nos expone a todos los riesgos,

incluidas las fluctuaciones en el cambio, complicando la contratación

y exigiendo de nosotros realizar gran parte de la gestión del

offshore.

Si decidimos trabajar con un socio local debemos tener en cuenta

que tenga experiencia real en trabajar offshore. Las grandes

empresas de servicios juegan con las experiencias de unas

divisiones concretas y las ofrecen como experiencias generales.

Debemos confirmar que las personas que están asignadas a nuestra

empresa o sector tienen experiencia real con el centro offshore con

el que se va a trabajar.

Si decidimos trabajar directamente con el centro offshore debemos tener

en cuenta que tenga experiencia con empresas de nuestro país en

nuestro sector. El personal del proveedor offshore debe ser capaz de

entender nuestro idioma y nuestra problemática de forma eficaz.

En todos los casos es deseable que el proveedor tenga una experiencia

previa con nosotros, si es el centro offshore en un proyecto pequeño o

mediano antes de entrar en un mantenimiento, si es el proveedor local en

proyectos y mantenimientos. Cada empresa tiene su vocabulario y sus

formas de trabajar y es necesario conocerlos para que la comunicación sea

fluida y eficiente.

En cualquier caso debemos evitar la subcontratación en cadena de

forma descontrolada. Hay ocasiones donde un cliente descubre que

trabaja con un centro offshore por un correo o un comentario casual de uno

de los trabajadores del proveedor. Además de la necesaria confianza y

claridad que debe existir en la relación proveedor-cliente, debemos ser

capaces de gestionar estas transformaciones dentro de las organización y

que no sean los proveedores quienes tomen estas decisiones de forma

unilateral. En el caso de que la subcontratación exista, asegúrese que

existen los contratos y la experiencia necesaria para garantizar un servicio

continuado y de calidad.

Por último, no se fije sólo en el precio, puede costarle caro.

Socio

¿Cómo seleccionar a nuestro socio para el offshore?

Proceso, criterios, consideraciones

Es muy importante que exista un método de trabajo

bien definido que cubra todas las fases del ciclo de

desarrollo y que sea conocido de forma efectiva por

todos los actores involucrados en el proceso. De nada

sirve una metodología de trabajo que sólo conocen

algunos de los implicados y de poco vale disponer de un

proceso bien definido sólo en una parte del proceso.

Es necesario establecer un cuadro de

responsabilidades que contemple todos los actores,

incluido los procesos internos del proveedor. Hay cierta

tendencia a tratar al proveedor como una caja negra a la

que hacemos peticiones y que nos devuelve resultados.

El proveedor tiende a ocultar sus proceso internos, pero

el cliente debe ser consciente de la forma de trabajo

interno, porque depende de ella.

En este sentido se debe definir con claridad que papel

juega el equipo del cliente, el equipo del proveedor local

y el centro offshore. El método de trabajo y el control

de los proceso dependerá del papel que juega cada

uno.

Esta metodología de trabajo debe establecer con

claridad los medio de comunicación entre los

equipos , pero no sólo para las situaciones normales,

también para las situaciones excepcionales, las

urgencias e imprevistos. Sólo de esta se podrá afrontar

estas situaciones con garantías de éxito.

La dependencia de los equipos dentro del proveedor

también es relevante. Si se tiene una dependencia

jerárquica o por el contrario hay una dependencia

cruzada indicará la complejidad interna de la

organización del proveedor y en ocasiones indicará al

cliente a quien debe dirigirse en caso de conflicto grave

También se debe tener en cuenta la organización de

los equipos y su distribución entre el proveedor local

y el centro offshore, así como la dedicación en

exclusiva o su trabajo compartido con otros clientes.i

Méto

do

¿Cómo vamos a trabajar?

La importancia del modelo de trabajo

Segu

ridad

¿Qué tenemos que adaptar para un contexto internacional?

Trabajar desde un entorno remoto

En cualquier servicio externalizado la seguridad debe

tener un papel relevante para garantizar la correcta

gestión de los activos y evitar conflictos que podrían

llegar a ser graves.

En la colaboración con un proveedor offshore, la

seguridad puede llegar a ser mucho más importante, ya

que se puede estar produciendo un acceso a los

sistemas desde otros países, con legislaciones

diferentes y con niveles de criminalidad mucho más

elevados.

La fidelidad de los empleados de los proveedores de

offshore en algunas ocasiones es muy baja, por lo que

existen riesgos de sabotaje por parte de los propios

trabajadores.

Por todo ello debemos ser muy estrictos en las

políticas de acceso a los sistemas por parte del

offshore, analizando con detenimiento a que entornos

puede tener acceso, que controles de seguridad

disponemos para evitar accesos indebidos a otros

servidores o servicios, la gestión de cambios, etc.

La administración de la seguridad con un centro

offshore accediendo a nuestros sistemas puede llegar a

ser compleja. La creación de usuarios y su asignación

de permisos puede llegar a ser una autentica locura con

los empleados de un centro ubicado en la otra parte del

mundo. Debemos establecer con claridad los

procedimiento de alta/baja de usuarios evitando el

recurso fácil de la utilización de usuarios genéricos y

anónimos, pues son fuente de continuos conflictos.

Por supuesto, se deben cuidar todos los acuerdos de

confidencialidad con el proveedor, teniendo en cuenta

las posibles subcontrataciones.

Cuando trabajamos en un offshore fuera de la Unión

Europea debemos ser conscientes de las grandes

diferencias que pueden existir en cuanto a la

legislación que se debe aplicar en caso de existir

conflictos de cualquier tipo.

En caso de proveedores Españoles, todos conocemos

los posibles conflictos en casos de problemas

laborales y hemos establecido los mecanismos

adecuados para protegernos de los posibles conflictos

de los proveedores con sus trabajadores. En el caso de

trabajar con un proveedor offshore debemos informarnos

de los posibles compromisos que el cliente está

asumiendo de forma subsidiaria con los empleados del

proveedor.

De forma análoga hay que revisar que legislación existe

en el país del centro offshore en cuanto a la propiedad

de los trabajos realizados. En algunos países no se

reconocen los derechos de propiedad intelectual de

igual forma a como los entendemos en occidente y

puede terminar surgiendo conflictos con el desarrollador

o con la empresa proveedora, aunque haya trabajado

por cuenta de terceros.

Por otra parte hay tener garantías que el proveedor está

usando software legalmente adquirido y que no está

reutilizando código entre clientes para de esta forma

reducir costes.

La mayoría de estos riesgos está razonablemente

controlados en los países donde existe una industria

del outsourcing suficientemente desarrollada, siendo

más relevante en nuevos destinos para el desarrollo

offshore donde la legislación vigente puede no estar

suficientemente adaptada para ofrecer las garantías

necesarias a las empresas de los países desarrollados.

Por último, es posible que tenga la confianza de haber

firmado un buen contrato que le protege de toda

responsabilidad en cualquier conflicto, pero debe tener

también en cuenta el posible daño que puede

producir a su reputación corporativa un problema

grave de su proveedor. La prensa tiende a simplificar

los mensajes y aprovechar cualquier oportunidad para

conseguir un titular llamativo, por lo que puede terminar

viendo el nombre de su empresa envuelto en

escándalos totalmente indeseados.

Legis

lación

¿Qué responsabilidad tenemos en el offshore?

Los problemas ocultos

En la relación con un servicio externalizado la

comunicación es siempre la pieza clave de los

procesos. En el offshore, la comunicación se

convierte en un aspecto crítico.

Trabajar con personas en otra parte del mundo, con

otro horario, otra cultura y en ocasiones otro idioma,

requiere una gestión específica de la comunicación.

Es necesario establecer los mecanismos y

herramientas de comunicación a diferentes niveles.

Desde las más formales a las más informales, desde las

comunicaciones en situaciones normales a las que

tienen que producirse en casos excepcionales y de

urgencia.

Los mecanismos de comunicación y los

interlocutores para cado caso se deben definir,

difundir y controlar. Debemos asegurarnos que todos

los implicados conocen y utilizan estos mecanismos de

forma eficiente, revisándolos continuamente y, si es

necesario, realizar adaptaciones y mejoras en el

proceso.

Hay que tener en cuenta las diferencias culturales,

aun cuando se hable el mismo idioma. Los conflictos,

los malos entendidos, las confusiones, pueden ser

fuente de graves conflictos, retrasos e ineficiencias. Es

complejo gestionar las diferencias culturales, pero

debemos tener mecanismos que garanticen que se

han comprendido los documentos y no progresar los

errores de comprensión hasta niveles cuyas

consecuencias sean difícilmente identificables y

asumibles.

No crea que el proveedor no va a tener problemas de

comunicación con el centro de offshore. Aunque las

grandes empresas de servicios suelen tener personal

que habla varios idiomas y que está acostumbrado a

trabajar en entornos multiculturales, hay que estar

seguros de que van a ser capaces de gestionar la

comunicación de forma eficiente y que tienen

experiencia en el trato con el centro de offshore que

finalmente se va a utilizar, además de utilizar los

mecanismos de confirmación suficientes.

Comu

nicac

ión

¿Dónde y cómo impacta el idioma y las diferencias culturales?

La gestión de la diversidad

Al trabajar con un centro offshore situado en un país que

no sea de habla hispana, debemos establecer en qué

idioma se realizan cada una de las actividades del

proceso.

Si se decide trabajar en inglés, habrá que tener en

cuenta que en la mayoría de los casos los

interlocutores no son nativos en este idioma y que,

por lo tanto, los errores y confusiones pueden ser muy

significativos.

Estas dificultades idiomáticas hacen que se tienda a

abusar de las comunicaciones formales en las que

uno puede revisar el texto una y otra vez hasta estar

seguro de que ha escrito algo comprensible. Esto

dificulta y ralentiza la comunicación. Es recomendable

establecer mecanismos de comunicación informal

para resolver dudas o aclarar algunos puntos menores,

aun cuando supongan un mayor esfuerzo para los

interlocutores.

Especialmente en los acuerdos de mantenimiento, el

idioma resulta clave, pues existe ya una documentación

redactada en el idioma de origen, un código comentado

y un interface que deben ser objeto de transferencia de

conocimiento.

Es necesario establecer el idioma de los diferentes

elementos de la aplicación:

• Idioma de la documentación del código, de las

librerías comunes, del framework, etc.

• Idioma de los literales de la interfaz de usuario. Esto

puede llegar a ser especialmente importante a la hora

del control de calidad.

• El idioma del entorno de desarrollo y de los puestos

de trabajo: puede parecer indiferente, pero en

ocasiones existen problemas entre versiones del

mismo software en distintos idiomas.

Es necesario establecer el idioma de todas las

comunicaciones:

• Idioma de la documentación para la transferencia de

conocimiento.

• Idioma de las solicitudes y de la documentación

devuelta.

• Idioma de las incidencias y situaciones de

emergencia

Comu

nicac

ión

¿En que idioma se trabaja? ¿En que idioma está la aplicación?

La torre de Babel

www.itmplatform.com