El nivel de madurez (nueva, estable, obsoleta) de la aplicación es relevante a la hora de afrontar una externalización. 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.

Otros artículos relacionados con la gestión de riesgos en el desarrollo offshore:

1. Gestión de riesgos en el desarrollo offshore: el método de trabajo

2. Gestión de riesgos en el desarrollo offshore: ¿Cómo seleccionar a nuestro socio para el offshore?

3. Gestión de riesgos en el desarrollo offshare: ¿Cuáles son las principales características de la externalización?

4. Gestión de riesgos en el desarrollo offshore: ¿Qué es y para qué se utiliza el outsourcing?

5. Gestión de riesgos en el desarollo offshore: ¿Cuál es el alcance?

6. Gestión de riesgos en el desarollo offshore: ¿Cómo se llega al offshore?

7. Gestión de riesgos en el desarollo offshore: ¿Cómo afrontar el offshore IT outsourcing?

8. Gestión de riesgos en el desarrollo offshore: ¿En qué idioma se traba? ¿En qué idioma está la aplicación? 

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.

Estas preguntas serán contestadas de forma diferente por cada organización

¿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.

Otros artículos relacionados con la gestión de riesgos en el desarrollo offshore:

1. Gestión de riesgos en el desarrollo offshore: el método de trabajo

2. Gestión de riesgos en el desarrollo offshore: ¿Cómo seleccionar a nuestro socio para el offshore?

3. Gestión de riesgos en el desarrollo offshare: ¿Cuáles son las principales características de la externalización?

4. Gestión de riesgos en el desarrollo offshore: ¿Qué es y para qué se utiliza el outsourcing?

5. Gestión de riesgos en el desarollo offshore: ¿Cuál es el alcance?

6. Gestión de riesgos en el desarollo offshore: ¿Cómo se llega al offshore?

7. Gestión de riesgos en el desarollo offshore: ¿Cómo afrontar el offshore IT outsourcing?

8. Gestión de riesgos en el desarrollo offshore: ¿En qué idioma se traba? ¿En qué idioma está la aplicación? 

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.

Aunque pueda parecer que los proyectos y el mantenimiento se pueden gestionar en offshore de igual forma, los problemas y riesgos pueden ser diferentes.

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.

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.

Se debe evitar afrontar un proceso de offshore de forma poco reflexiva.

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.

Otros artículos relacionados con la gestión de riesgos en el desarrollo offshore:

1. Gestión de riesgos en el desarrollo offshore: el método de trabajo

2. Gestión de riesgos en el desarrollo offshore: ¿Cómo seleccionar a nuestro socio para el offshore?

3. Gestión de riesgos en el desarrollo offshare: ¿Cuáles son las principales características de la externalización?

4. Gestión de riesgos en el desarrollo offshore: ¿Qué es y para qué se utiliza el outsourcing?

5. Gestión de riesgos en el desarollo offshore: ¿Cuál es el alcance?

6. Gestión de riesgos en el desarollo offshore: ¿Cómo se llega al offshore?

7. Gestión de riesgos en el desarollo offshore: ¿Cómo afrontar el offshore IT outsourcing?

8. Gestión de riesgos en el desarrollo offshore: ¿En qué idioma se traba? ¿En qué idioma está la aplicación? 

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 conjunto de artículos 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.

El uso de factorías de software puede aportar importantes ventajas

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.

Otros artículos relacionados con la gestión de riesgos en el desarrollo offshore:

1. Gestión de riesgos en el desarrollo offshore: el método de trabajo

2. Gestión de riesgos en el desarrollo offshore: ¿Cómo seleccionar a nuestro socio para el offshore?

3. Gestión de riesgos en el desarrollo offshare: ¿Cuáles son las principales características de la externalización?

4. Gestión de riesgos en el desarrollo offshore: ¿Qué es y para qué se utiliza el outsourcing?

5. Gestión de riesgos en el desarollo offshore: ¿Cuál es el alcance?

6. Gestión de riesgos en el desarollo offshore: ¿Cómo se llega al offshore?

7. Gestión de riesgos en el desarollo offshore: ¿Cómo afrontar el offshore IT outsourcing?

8. Gestión de riesgos en el desarrollo offshore: ¿En qué idioma se traba? ¿En qué idioma está la aplicación? 

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.