Upload
itm-platform
View
221
Download
0
Embed Size (px)
DESCRIPTION
Conjunto de artículos en los que se tratan diferentes aspectos de la gestión de riesgos en el desarrollo offshore.
Citation preview
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