Gesti贸n de riegos en el desarrollo
Offshore
Introducción
¿Cómo afrontar el Offshore IT Outsourcing?
Riesgos
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.
Origen
¿Cómo se llega al offshore?
Decisión estratégica o resultado táctico 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.
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.
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.
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.
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 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.
Actividad
¿Cuál es el alcance?
Proyecto o mantenimiento 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.
Objetivo
¿Qué es y para que se utiliza?
Sistema, aplicación, servicio… 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.
Objetivo
¿Cuáles son sus principales características?
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.
Socio
¿Cómo seleccionar a nuestro socio para el offshore?
Proceso, criterios, consideraciones 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.
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 primer lugar debemos decidir si queremos disponer de un socio local o podemos trabajar directamente con el centro de offshore.
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.
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.
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.
Método
¿Cómo vamos a trabajar?
La importancia del modelo de trabajo 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
Seguridad
¿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.
Legislación
¿Qué responsabilidad tenemos en el offshore?
Los problemas ocultos 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.
Comunicación
¿Dónde y cómo impacta el idioma y las diferencias culturales?
La gestión de la diversidad 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.
Comunicación
¿En que idioma se trabaja? ¿En que idioma está la aplicación?
La torre de Babel
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.
Es necesario establecer el idioma de los diferentes elementos de la aplicación:
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.
• Idioma de los literales de la interfaz de usuario. Esto puede llegar a ser especialmente importante a la hora del control de calidad.
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.
• Idioma de la documentación del código, de las librerías comunes, del framework, etc.
• 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 emergencia
las
incidencias
y
situaciones
de
www.itmplatform.com