1. Etapa Precontractual Etapa Contractual
Fase 1 Fase 2 Fase 3 Fase 4 Fase 5 Fase 6
Ejecución
Desarrollo
de Planificación
Negociación
Iniciación concepto, Cierre
de ofertas del proyecto
elaboración
de ofertas
Seguimiento
y Control
SEMANAS S1 S2 S3 S4 S5 S6
Desarrollo Proyecto
Diseñar
Fabricar
Probar
Implantar
Claves para abordar un
proyecto TIC
Víctor Lerga Bezunartea
MBS3
2. Claves para abordar un proyecto TIC Marzo-2010
INDICE GENERAL
DESCRIPCIÓN PAG
INDICE GENERAL................................................................................................................................................................ 2
1. INTRODUCCIÓN......................................................................................................................................................... 3
2. PONGAMONOS EN CONTEXTO. ¿QUÉ ES UN PROYECTO DE TIC?................................................................................ 3
3. ESTRATEGIA Y PLAN DE ACCIÓN ................................................................................................................................ 6
3.1. EVALUACIÓN DE ASPECTOS ESTRATEGICOS ........................................................................................................ 6
3.2. FACTORES CLAVE DE ÉXITO ................................................................................................................................ 8
4. ETAPAS DE UN PROYECTO TIC.................................................................................................................................... 9
4.1. ETAPA PRE-CONTRACTUAL................................................................................................................................. 9
4.2. ETAPA EJECUCIÓN ........................................................................................................................................... 10
4.2.1. Planificación............................................................................................................................................ 10
4.2.2. Análisis.................................................................................................................................................... 10
4.2.3. Diseño y desarrollo.................................................................................................................................. 10
4.2.4. Seguimiento y control.............................................................................................................................. 11
4.2.5. Implantación ........................................................................................................................................... 11
4.2.6. Formación............................................................................................................................................... 12
5. MANTENIMIENTO Y SERVICIO POST-VENTA............................................................................................................. 12
6. PROCESOS DE EXTERNALIZACIÓN DE SERVICIOS DE IT ............................................................................................. 12
6.1. ACREDITACIONES Y NORMATIVAS.................................................................................................................... 13
6.2. BREVE DESCRIPCIÓN DEL MODELO ISO 20000 .................................................................................................. 14
7. BIBLIOGRAFÍA Y REFERENCIAS ................................................................................................................................. 16
Víctor Lerga Bezunartea 2 de 17
3. Claves para abordar un proyecto TIC Marzo-2010
1. INTRODUCCIÓN
Los cambios tecnológicos se producen cada vez con mayor frecuencia en las empresas, si bien las
personas que deben liderarlo como clientes, suelen carecer de experiencia en los mismos.
Estudios publicados indican que los principales problemas en la implantación de un proyecto
tecnológico se encuentran en la mala definición de los objetivos a alcanzar (39,2%), la falta de
habilidades de gestión de proyectos (29,20% ) y los problemas de relaciones personales entre los
implicados (21,7%).
En la relación con los proveedores de tecnología, los problemas surgen por falta de alineamiento
entre cliente y proveedor, provocado por la falta de experiencia, la ausencia de implicación o por no
conseguir elaborar estrategias efectivas de colaboración. Una mayor comprensión de la problemática
en la gestión de proyectos de Tecnologías de la Información y Comunicaciones (TIC), permitirá
abordarlo con mayor efectividad.
A lo largo de este artículo, se detallarán las fases por las que debe transcurrir cualquier proyecto
relacionado con las TIC, y se indicarán ciertos aspectos clave para gestionar y controlar el avance del
proyecto. El artículo no requiere un alto nivel de conocimientos ni experiencia en nuevas tecnologías.
Se comenzará con una breve exposición de la diversa tipología de proyectos de TIC, y su ciclo de
vida. Después, se pasa a explicar cada una de las fases para definir los puntos en que un cliente debe
prestar mayor atención.
Finalmente, describiremos aspectos significativos de un proyecto de externalización de servicios de
IT, por ser un proceso en auge que cuenta con aspectos que lo diferencian del desarrollo de un
producto.
2. PONGAMONOS EN CONTEXTO. ¿QUÉ ES UN PROYECTO DE TIC?
“Un Proyecto es un esfuerzo temporal emprendido para crear un producto, servicio o resultado
únicos” Project Management Institute (PMI)
La explotación de las TIC en el día a día, responde a un modelo continuo, muy similar a un ciclo de
actuación en Operaciones tradicionales. Este ciclo sigue las fases Planificar-Hacer-Verificar-Actuar
(Plan-Do-Check-Act), que permite la introducción de mejoras continuas en la operación. La necesidad
de un cambio en dicha operativa lanza un proceso paralelo que constituye el desarrollo de un nuevo
proyecto. Una vez finalizado, su resultado se integrará en la operación de la compañía. La
responsabilidad de la operación y soporte de las TIC, suele integrarse en un departamento
denominado de informática o de servicios de IT (Information Tecnologies).
Los tipos de proyectos asociados a las TIC, son de tipología y alcance muy variado. Si atendemos al
producto entregado, podemos distinguir entre un proyecto de suministro, donde se adquieren
nuevos equipos o aplicaciones, y proyectos de servicio, donde es habitual contratar horas para la
realización de un trabajo (cuyo objeto puede ser el desarrollo de un producto/aplicación, un
proyecto de consultoría, etc…). Hoy día, se está extendiendo la adquisición de sistemas y aplicaciones
como servicios (software como servicio SaaS), con lo cual la frontera entre estas categorías es cada
vez más difusa.
Víctor Lerga Bezunartea 3 de 17
4. Claves para abordar un proyecto TIC Marzo-2010
Necesidad
de CAMBIO
Plan Etapa Pre- Etapa
Contractual Ejecución
Soporte y
Act explotación Do
TICs
Check
Décadas atrás, muchos proyectos se desarrollaban internamente si bien hoy es habitual contratar a
un proveedor externo. Actualmente, muchas compañías externalizan también sus operaciones a
través de un proveedor servicios de IT.
Así, ha surgido una nueva clase de proyectos cuyo objeto es externalizar la explotación y soporte de
los servicios de IT. Estos proyectos, denominados de outsourcing de los servicios de IT tiene unas
características especiales, dado que implica obtener una relación continuada con un proveedor;
personas que estarán en contacto diario con nuestra empresa e influirán en el desarrollo de nuestro
negocio. Muy al contrario que un proyecto de nuevos desarrollos que implican una relación limitada
y planificada en el tiempo. También el equipo que debe ejecutarlo ha de contar con habilidades
radicalmente distintas.
Conceptos clave para la provisión de servicios de IT son la orientación a la urgencia, Acuerdos en el
Nivel del Servicio (SLA’s), el catálogo de servicios, y las normativas y estándares más habituales (ITIL,
ISO.20000). La organización y su estructura deben estar orientadas a la entrega del servicio, tomado
este como una relación a largo plazo.
En el desarrollo de un nuevo producto es necesario contar con una buena gestión de objetivos,
experiencia en proyectos, y dominar la elaboración de una adecuada Planificación y gestión de
desarrollo y conocimiento de metodologías de desarrollo.
Así pues, las habilidades de un proveedor para llevar con éxito el proyecto, son diferentes, según la
tipología del proyecto a abordar. En la siguiente tabla se realiza una comparativa entre un proyecto
de nuevo desarrollo y uno dedicado a la provisión de servicios de IT.
Víctor Lerga Bezunartea 4 de 17
5. Claves para abordar un proyecto TIC Marzo-2010
Diferencias conceptuales
Provisión de servicios IT
Nuevos desarrollos
(Operación y explotación)
Tiempo y personas
Producto/Entrega Software y materiales
Uso de infraestructura
Temporal Planificado en tiempo Ilimitado
Conocimiento del negocio Requisitos medios Requisitos altos
Calidad de la entrega del
Foco de excelencia Gestión del proyecto.
servicio
Relación y confianza
Conocimientos tecnológicos
continuada
Habilidades proveedor Planificación
Manejo equipos
Métodos Gestión Proyectos
Orientación a SLA’s
Para abordar con éxito un proyecto, es necesario tener claro qué fases es necesario “quemar” y
cuales son los resultados esperados en cada una de ellas.
La siguiente figura, muestra las fases básicas para abordar un proyecto de TIC’s. En el primer nivel de
clasificación está la etapa pre-contractual que debe ser íntegramente realizada por la empresa, y la
de la propia ejecución del proyecto que se realiza en conjunción con el proveedor elegido.
Etapa Pre-Contractual Etapa de Ejecución
Diseño y
Planificación Análisis Implantación
desarrollo
Pliego Recepción
prescripciones ofertas
Seguimiento y Control
Víctor Lerga Bezunartea 5 de 17
6. Claves para abordar un proyecto TIC Marzo-2010
3. ESTRATEGIA Y PLAN DE ACCIÓN
En muchas ocasiones, cuando se designa al responsable de liderar un proyecto TIC en la empresa, la
decisión del cambio tecnológico ha sido tomada con anterioridad. A veces, liderar un proyecto de
estas características suele ser percibido como un “marrón”, que añadirá, a las tareas cotidianas del
responsable las requeridas por este proyecto.
La primera tarea es coordinar los intereses internos de la empresa y definir objetivos consensuados
Como punto de partida, es necesario un auto-análisis, por parte de todos los implicados, sobre lo que
se espera obtener del nuevo proyecto. También es conveniente realizar un cierto análisis del
entorno, para averiguar la viabilidad tecnológica y su grado de madurez. Esto nos resolverá dudas
sobre las opciones de utilizar productos cerrados o a medida.
3.1. EVALUACIÓN DE ASPECTOS ESTRATEGICOS
Los pasos previos para lanzar un proyecto TIC no se pueden obviar. Debemos evaluar todos los
aspectos estratégicos para clarificar el resultado que queremos obtener, y transmitirlo tanto a
nuestro proveedor como internamente en la compañía.
Es por ello que el líder del proyecto debe contar con una clara definición y evaluación de los
siguientes aspectos internos:
- Criticidad del cambio en la estrategia empresarial
- Madurez de la tecnología
- Necesidad de cambio
- Presupuesto
- Organización interna
- Dimensión del proyecto
- Reestructuración de la organización para abordarlo
- Gestión Cambio
Objetivos -Dimensión-Medición.
La definición de los objetivos esperados es clave. Deben definirse dentro de la organización, y quedar
dimensionados de forma que sea factible medirlos una vez implantado el sistema. Ello nos permitirá
evaluar la capacidad, tanto de la organización como de la tecnología y del proveedor para
alcanzarlos.
Los objetivos no pueden definirse sin evaluar la relación coste-beneficio que se obtendrá con el
desarrollo del proyecto.
En la estimación de costes se considerarán, entre otros, los siguientes aspectos:
Víctor Lerga Bezunartea 6 de 17
7. Claves para abordar un proyecto TIC Marzo-2010
- Adquisición de hardware y software: El que sea preciso para el desarrollo, implantación
del sistema.
- Gastos de mantenimiento de hardware y software.
- Gastos de comunicaciones: Líneas, teléfono, Internet, etc.
- Gastos de instalación: Cableado, acondicionamiento de edificios, recursos, etc.
- Coste de desarrollo del sistema/producto.
- Gastos del mantenimiento del sistema ( Costes anuales).
- Gastos de consultoría: En caso de requerirse consultores externos en alguna etapa.
- Gastos de formación: De desarrolladores, operadores, usuario final, etc.).
- Gastos de material consumible: Papel, tóner, etc.
- Costes derivados de la curva de aprendizaje: De todo el personal involucrado, tanto
técnico como los Usuarios.
- Costes financieros, de publicidad, etc.
- Costes de reorganización: De personal nuevo y reubicación o despido de personal actual.
En la estimación de beneficios se pueden considerar cuestiones como las siguientes:
- Incremento de la productividad: Ahorro o mejor utilización de recursos humanos.
- Ahorro de gastos de mantenimiento del sistema actual.
- Ahorros de adquisición y mantenimiento de hardware y software..
- Incremento de ventas o resultados, disminución de costes: Producidos por una mejora de
la gestión (rotación de stock, "just in time", análisis de negocio, etc.).
- Ahorro de material, (como sustitución por datos electrónicos que proporciona el sistema,
como por ejemplo: papel, correo, etc.
- Beneficios financieros.
- Otros beneficios tangibles: Ahorro de recursos externos, consultoría, formación, etc.
- Beneficios intangibles: Incremento de la calidad del producto o servicio, mejora de la
imagen de la compañía, mejora en la atención al cliente, mejora en la explotación, etc.
Para transmitir los objetivos de la empresa a un proveedor, es conveniente traducirlos al ámbito de
sistemas. Así, un objetivo del proyecto puede ser el incremento de productividad, pero ésta , no
depende exclusivamente de la implantación de una tecnología. En la definición del proyecto es
necesario transmitirlo por ejemplo como un aumento en la velocidad en las operaciones a realizar
con el nuevo sistema.
En todo caso es muy importante gestionar expectativas, tanto del proveedor como las internas en la
organización, a fin de hacerlas acordes con la realidad esperada.
Es conveniente explicar los objetivos de la empresa dentro del ámbito de sistemas ya que no
compramos negocio, sino tecnología.
Víctor Lerga Bezunartea 7 de 17
8. Claves para abordar un proyecto TIC Marzo-2010
3.2. FACTORES CLAVE DE ÉXITO
En definitiva, para conseguir llevar a buen puerto el proyecto, hemos de ser conscientes de dónde
debemos poner el foco de nuestro esfuerzo, tanto internamente en la compañía, como respecto a
nuestra relación con el proveedor. A continuación se exponen los principales factores clave de éxito.
FACTORES CLAVE DE ÉXITO INTERNOS
Involucrar a todos los interesados
Apoyo de la Dirección
Gestión de expectativas realistas
Habilidades de gestión y organización
Definición de roles y responsabilidades
Valoración del impacto organizativo, y del cambio interno
FACTORES CLAVE DE ÉXITO RESPECTO AL PROVEEDOR:
Alineamiento de objetivos
CLIENTE PROVEEDOR
Considerar al proveedor un socio Considerar al cliente como una
tecnológico oportunidad de negocio a largo
plazo
Comprensión de proyectos TIC Comprensión del negocio
Definición de requisitos/ Objetivos Comprensión de los requisitos
/Objetivos
Gestión riesgos para el negocio Gestión riesgos técnicos
Implicación Implicación
Víctor Lerga Bezunartea 8 de 17
9. Claves para abordar un proyecto TIC Marzo-2010
4. ETAPAS DE UN PROYECTO TIC
4.1. ETAPA PRE-CONTRACTUAL
En esta etapa, se deben plasmar los objetivos y resultados que se espera conseguir del proyecto.
El documento que recoge los requisitos técnicos es el Pliego de Prescripciones. Su misión es recoger
los aspectos básicos y fundamentales de proyecto, que permitan al proveedor evaluar la oferta y sus
capacidades para llevarla a cabo. Además, este documento se utiliza como parte del contrato con el
proveedor.
El pliego debe contener al menos:
- Requisitos definidos, claros y concretos. SLA’s, y todo aquello que esté dentro de los
objetivos de la empresa.
- Plan de ejecución (fechas).
- Documentación que se requiere (Plan de proyecto, calidad, procedimientos de prueba,
Plan de contingencias).
- Trabajos que deben realizarse, tanto nuevos como el mantenimiento del Legacy
tecnológico.
- Propiedad intelectual y confidencialidad.
- Penalizaciones: cuales y como se medirán.
PPT. Con o sin obligación administrativa debería redactarse un pliego de prescripciones técnicas.
La ambigüedad en un pliego/contrato provoca desviaciones de EXPECTATIVAS.
En esta fase es necesario tener una cierta evaluación del riesgo tecnológico en cuanto a la
consecución de los objetivos. En caso de un alto grado de incertidumbre, el Pliego debería establecer
las cláusulas necesarias para abordar el proyecto en diversas fases. Dichas fases, como la generación
de proyectos piloto (o prototipos) pueden definirse como condicionantes, a la vista de sus
resultados, para el avance del proyecto/contrato en su totalidad. Es conveniente contactar con
varios proveedores, ya que la mayoría cuenta con apoyo y consultoría pre-venta para la redacción de
Pliegos técnicos. En caso de alta complejidad del proyecto, la compañía deberá contar con la
colaboración de consultores que hagan de Asistencia Técnica a la dirección del proyecto.
La inclusión de los criterios de evaluación de ofertas ayuda a objetivar y priorizar las distintas
opciones que presenten los proveedores.
El PPT no es un “tocho” que contenga TODO el proyecto.
Debe indicar lo fundamental, preparar el contrato y permitir definir las líneas de trabajo y los
objetivos básicos.
Víctor Lerga Bezunartea 9 de 17
10. Claves para abordar un proyecto TIC Marzo-2010
4.2. ETAPA EJECUCIÓN
El cliente debe implicarse en especial durante las primeras fases de ejecución; es necesaria una
comunicación fluida con el proveedor que permita el correcto entendimiento del proyecto. El
responsable del proyecto no puede limitarse a evaluar cuestiones técnicas, pues en este caso su
interés se centrará en implantar excelencias tecnológicas. Nuestro interlocutor debe ser una
persona capaz de entender tanto la tecnología como nuestro negocio lo que permitirá que asimile
nuestras necesidades últimas.
El nivel de interlocución debe balancear lo tecnológico y la capacidad para comprender el negocio.
4.2.1. Planificación
Durante esta fase se marcan las líneas de actuación del proyecto respecto al tiempo, hitos a
conseguir y como realizar el proyecto.
Se deben elaborar los planes que recojan todo ello: Plan de proyecto, Plan de calidad y de Gestión
de la documentación. Debe incluir el Plan de comunicación, que defina la interlocución cliente-
proveedor. El cliente debe visar y aprobar todos los planes.
El plan maestro se actualizará y revisará durante la vida del proyecto.
4.2.2. Análisis
Considero esta etapa la más importante del proyecto. En ella, cliente y proveedor deben sentarse a
entenderse y conocerse. El equipo del cliente debe hacer entender al proveedor qué espera del
proyecto, y este a su vez explicar dónde está el límite de la tecnología. Si el proveedor expresa
cualquier riesgo o dificultad tecnológica sobre los requisitos solicitados, debe atenderse
debidamente, ya que puede arrastrar resultados no deseados durante todo el proyecto.
Como resultado de esta etapa se definen y clarifican los requisitos, que pueden ampliar o rectificar
los que se hallaban el pliego. Codo con codo, debe registrase lo necesario para el proyecto, olvidando
lo superfluo. Los requisitos que se definan, marcan las expectativas del proyecto.
GESTION DE EXPECTATIVAS: En esta fase se forjan todas las expectativas sobre el resultado
- DEFINIR LOS RESQUISITOS, ENTENDERLOS Y APROBARLOS
- MARCAR LOS OBJETIVOS Y RESULTADOS ESPERADOS
- LOS REQUISITOS DEBEN SER ACORDES CON LAS EXPECTATIVAS DE LA EMPRESA
4.2.3. Diseño y desarrollo
Esta etapa requiere poca interacción del cliente, salvo validación de prototipos o interfaces de
usuario, que podrían definirse en la etapa anterior.
Víctor Lerga Bezunartea 10 de 17
11. Claves para abordar un proyecto TIC Marzo-2010
Es una etapa muy técnica en su mayor parte responsabilidad del proveedor.
El cliente debe exigir que exista documentación de diseño, pero no es el diseñador.
Cuanto mayor es el riesgo e incertidumbre sobre la tecnología a desarrollar, más necesario es
desarrollar de forma rápida e iterativa para permitir validaciones parciales del producto. En este
caso, el cliente debe validar cada una de las iteraciones o prototipos, a fin de ir cerrando la
incertidumbre sobre el resultado.
En todo caso, como final de la etapa de desarrollo, es habitual realizar sesiones de Pruebas en
Fábrica a las que el cliente debería asistir. Para la realización de las pruebas se debe exigir la
redacción de los adecuados Procedimientos y la asistencia como apoyo del delegado de calidad del
proveedor.
4.2.4. Seguimiento y control
Al menos de forma mensual, cliente y proveedor deber realizar una reunión de seguimiento para
evaluar el avance del proyecto respecto del plan, y analizar y controlar posibles desviaciones. La
reunión sirve además para poner en común cualquier afectación al plan.
El proveedor debe recibir con antelación a la reunión el Informe de seguimiento, que servirá de guía
en dicha reunión.
El proveedor además debe indicar cualquier cambio de alcance durante estas reuniones, a fin de
oficializar su comunicación. Debe levantarse Acta de lo tratado en estas reuniones.
La reunión no debe tomarse como un rito formal. La base de una buena gestión del proyecto es
tomar y ejecutar las medidas correctoras fruto de esta reunión.
4.2.5. Implantación
Una vez terminado el desarrollo del producto, este debe instalarse e implantarse en su
emplazamiento definitivo para comenzar su explotación.
Si se han realizado diferentes fases de validación, el riesgo de fallo se reduce considerablemente
La implantación es el proceso más doloroso.
ES LA HORA DE LA VERDAD y no hay vuelta atrás
Una vez llegados a esta fase, la vuelta atrás es muy complicada. Es el momento en que usuarios, la
dirección y demás implicados tienen visibilidad plena del proyecto y las expectativas son máximas.
El paso a explotación debe ser ordenado y fiable. Para ello se deben pasar exhaustivas Pruebas de
Aceptación del sistema. Sobre todo, además de las pruebas sobre funcionalidad, no deben olvidarse
Víctor Lerga Bezunartea 11 de 17
12. Claves para abordar un proyecto TIC Marzo-2010
pruebas de carga y estabilidad del sistema, que aseguren la fiabilidad y disponibilidad del sistema
según las necesidades del mismo.
Es muy importante contar con un plan de contingencia, que permita, ya en explotación, una marcha
atrás ante fallos no esperados. Típicos planes de contingencia pueden ser mantener sistemas
heredados en paralelo durante la fase de transición, o establecer mecanismos para activar una
operación de emergencia en caso de fallo.
4.2.6. Formación
La formación es preferible realizarla al final del proyecto, en la fase de implantación, de forma que
los cursos de (administración, usuario, y mantenimiento), se realicen sobre el producto final, en el
propio emplazamiento.
Una alternativa a un curso tradicional que da muy buenos resultados es realizar formación “On the
job training”, durante la cual se resuelven dudas sobre la operación en el mismo puesto de trabajo.
Es habitual dejar al proveedor la responsabilidad de la formación, si bien su ámbito es la tecnología y
no el negocio de la empresa. Lo correcto sería que la formación fuese un proceso conjunto entre
personal del cliente y el proveedor.
El proveedor forma sobre como PUEDE operarse el sistema, no como DEBE que es
responsabilidad de la compañía
5. MANTENIMIENTO Y SERVICIO POST-VENTA
El mantenimiento de las TI’s, suele ser el gran olvidado, dada la tendencia a creer que los sistemas
funcionan solos, sin embargo, el coste anual del mantenimiento puede llegar a un 10-20% del coste
hasta su implantación.
Se debe tener en cuenta desde el principio qué servicio post-venta ofrece el proveedor así como la
estructura organizativa con que cuenta para realizar este servicio, o sea , los tiempos de respuesta y
que cantidad de repuestos, consumibles se necesita para operar adecuadamente el sistema.
Un programa no se lleva a reparar al Mecánico
Es importante saber el coste asociado al servicio post-venta del sistema, que puede ser superior
a la inversión inicial.
6. PROCESOS DE EXTERNALIZACIÓN DE SERVICIOS DE IT
En décadas pasadas, los principales motivos de la externalización de las TIC eran la elevada
complejidad del entorno tecnológico, su coste y la rapidez con que se sucedían los cambios.
Víctor Lerga Bezunartea 12 de 17
13. Claves para abordar un proyecto TIC Marzo-2010
Actualmente las empresas externalizan procesos de negocio completos, no considerados estratégicos
para la compañía, pero con un alto componente tecnológico y de capital humano.
En su mayoría se trata de procesos administrativos, lo que permite a las empresas centrarse en su
negocio principal. Este proceso de externalización de denomina Business Process Outsourcing (BPO)
El BPO es la ejecución de procesos y actividades relacionadas con las TIC por parte de una empresa
externa que cuenta con su propia estructura, recursos, capacidad de decisión y gestión.
Como ya hemos indicado, emprender un proyecto de BPO, es hoy un proceso muy habitual, que
requiere tener una relación estrecha con el proveedor del mismo, pero que puede resultar crítico en
la operación de la empresa. Se estima que a lo largo de todo el ciclo de los productos IT, la fase de
explotación alcanza cerca del 70-80% del total del tiempo y del costo, el resto se invierte en el
desarrollo u obtención del producto.
Los Factores claves de éxito en los procesos BPO de las TIC son:
- Definir la estrategia de externalización, en especial la selección de las actividades que
deben quedar dentro de la empresa.
- Realizar una adecuada selección de los proveedores y de sus capacidades (Acreditaciones,
Catálogos de servicios y referencias).
- Negociar contratos que aseguren tanto el control como la flexibilidad.
- Definir los adecuados niveles de servicio y las penalizaciones en los contratos.
- Asegurar dentro de la empresa el futuro de las tecnologías TIC (Know-how de negocio)
para un posible in-sourcing.
Para realizar un proyecto de BPO, es necesario gestionar cada una de las fases antes detalladas (pre-
contractual, análisis, etc…) si bien con ciertos matices diferenciales, como los criterios para la
selección del proveedor o la fase de transición entre una situación en que los recursos propios
gestionan las TIC y las propia externalización.
En la fase de transición es necesario tener en cuenta los siguientes puntos
- Designar un responsable por ambas partes y crear un equipo de proyecto.
- Gestionar el cambio en la compañía mediante un Plan de Comunicación que explique las
necesidades de la externalización.
- Replanteamiento a la nueva situación de las condiciones laborales.
- Analizar y elaborar las medidas de contingencia durante el traspaso.
Para la elección del proveedor, es imprescindible conocer tanto su experiencia como sus
acreditaciones en la provisión de servicios de IT. En el siguiente apartado se definen las mejores
prácticas de este entorno.
6.1. ACREDITACIONES Y NORMATIVAS
Los intentos de estandarizar la calidad de los servicios de TIC, datan de finales de los 80. Entonces, el
gobierno británico de Margaret Thatcher se propuso mejorar los servicios IT de la administración y
realizó una recopilación de buenas prácticas. Con ello creo ITIL (Information Technology
Víctor Lerga Bezunartea 13 de 17
14. Claves para abordar un proyecto TIC Marzo-2010
Infraestructure Library). ITIL no es pues una normativa, sino una colección de libros donde se detallan
las mejores prácticas en la industria de IT. El objetivo era desarrollar una propuesta sin compromisos
con proveedor alguno.
Este estándar se convirtió en las bases de la norma ISO/IEC 20000 que se liberó a finales de 2005.
Actualmente en España hay únicamente unas 50 empresas acreditadas en ISO-20000, si bien es un
mercado en auge. ISO-20000 es una aplicación estandarizada de ITIL.
6.2. BREVE DESCRIPCIÓN DEL MODELO ISO 20000
ISO20000 ofrece un marco común para la gestión de todas las actividades del departamento IT. LA
norma no pretende describir todas las tareas, que dependerán en gran medida del tipo y alcance del
servicio, pero si describe procesos básicos necesarios para asegurar su calidad.
Estas actividades se dividen en procesos, que procuran un marco eficaz en la Administración madura
de un Servicio IT. Cada uno de estos procesos cubre una o más tareas del departamento IT. La
gestión por procesos permite describir las actividades independientemente de la estructura de
organización real de la entidad.
El esquema organizativo es el que sigue:
Procesos de PROVISIÓN DEL SERVICIO
• Gestión de Nivel de Servicio • Elaboración de Presupuesto y Contabilidad de
• Generación de Informes del Servicio los Servicios de TI
• Gestión de la Continuidad y • Gestión de la Capacidad
Disponibilidad del Servicio • Gestión de la Seguridad de la Información
Procesos de Control
• Gestión de Configuración
• Gestión del Cambio
Procesos de Procesos de
ENTREGA Procesos de
RELACIÓN
RESOLUCIÓN • Gestión de las Relaciones
• Gestión de Incidencias con el Negocio
• Gestión de la Entrega
• Gestión de Problemas • Gestión de Suministradores
Cada uno de los procesos definidos, contará en la organización con un responsable denominado
Dueño del Proceso (Process Owner).
Procesos de Provisión del Servicio. Se ocupan de los servicios ofrecidos en si mismos, asegurando la
calidad y efectividad de su entrega.
Víctor Lerga Bezunartea 14 de 17
15. Claves para abordar un proyecto TIC Marzo-2010
- Gestión del Nivel de Servicio : velará por la calidad de los servicios ofertados, alineando la
tecnología con los procesos de negocio. Se encarga de definir, acordar, registrar y
gestionar los niveles de servicio.
- Generación de Informes del Servicio: Genera los informes de evolución del servicio según
se acuerda con el cliente, con el objeto de mantener una comunicación efectiva.
- Gestión de la Continuidad y Disponibilidad del Servicio: Se encarga de asegurar la
continuidad del servicio ante cualquier causa externa desfavorable (p.ej catástrofes) y la
disponibilidad del mismo en todo momento.
- Elaboración de Presupuesto y Contabilidad de los Servicios de TI: Se encarga de los
servicios financieros del servicio. Presupuesta y contabiliza los costes de la provisión del
servicio.
- Gestión de la Capacidad: Asegura que el proveedor del servicio tiene, en todo momento,
la capacidad suficiente para cubrir la demanda acordada, actual y futura, de las
necesidades del negocio del cliente.
- Gestión de la Seguridad de la Información. Gestiona la seguridad de la información de
manera efectiva para todas las actividades del servicio.
Procesos de Control. La gestión de la configuración y del cambio son dos procesos sobre los que se
apoyan el resto de la gestión del servicio TI.
- Gestión de la Configuración: Define y controla los componentes del servicio y de la
infraestructura, (p.ej. equipos y aplicaciones), y mantiene la información precisa sobre su
estado y relaciones.
- Gestión del Cambio: Asegura que todos los cambios son valorados, aprobados,
implementados y revisados de una manera controlada.
Procesos de Entrega. Este proceso se encarga de realizar la planificación y gestión para poner en
explotación el lanzamiento de un nuevo servicio o producto.
- Gestión de la Entrega: Entregar, distribuir y realizar el seguimiento de uno o más cambios
en el entorno de producción real.
Procesos de Resolución. Se encarga de gestionar la resolución de anomalías en el servicio.
- Gestión de Incidencias: Se encarga de la recuperación de los servicios a los usuarios tan
pronto como sea posible.
- Gestión de Problemas: Tiene la misión de identificar y eliminar las causas de los
incidentes para que no vuelvan a producirse.
Procesos de Relaciones. Se encarga de las relaciones con todos los implicados en el servicio. Tiene
dos vertientes de relación, con los proveedores y clientes.
- Gestión de las Relaciones con el Negocio: Se encarga de las relaciones con el cliente
- Gestión de Suministradores: Trata las relaciones con suministradores, y garantiza la
calidad de su servicio .
Víctor Lerga Bezunartea 15 de 17
16. Claves para abordar un proyecto TIC Marzo-2010
Además de los procesos definidos, la función del Centro de Servicios o Service Desk es clave como
punto de acceso único de todos los implicados en su relación con los servicios de IT. El Service Desk
proporcionará a los usuarios un primer nivel de resolución de incidencias, la información sobre el
servicio y en su caso, contactará con los responsables de los distintos procesos para resolver
incidencias , gestionar cambios, solicitar informes, etc..
7. BIBLIOGRAFÍA Y REFERENCIAS
- “Guía de los fundamentos para la dirección de proyectos (guía del PMBOK®) Cuarta
edición”. Project Management Institute , 2008. ISBN: 978-1-9ANT90-72-2.
- “Dirección y gestión de proyectos”. Jaime Peñara Brand, 1991. ISBN: 84-87189-78-4
- “The Chaos Report”. Standish Group., 2004-2009. http://www.standishgroup.com
- “La externalización de los servicios de TIC y el BPO”. Sandra Sieber, Josep Valor, Valentín
Porta. IESE Business School. OP nº 08/02 Noviembre-2007.
- IEEE Std 1028: 1989, IEEE Standard for Software Reviews and Audits.
- “Metodología de Planificación, Desarrollo y Mantenimiento de sistemas de información
MÉTRICA Versión 3”. http://www.csi.map.es/csi/metrica3/index.html
- “Gestión de proyectos TIC en la seguridad social. Diez casos de gestión TIC en
instituciones de la seguridad social”. Grupo de Trabajo de la AISS e IBM. Asociación
Internacional de la Seguridad Social, Ginebra, 2004. http://www.issa.int/pdf/IT/3IBM.pdf
Referencias para ampliar conocimientos
- COBIT 4.0. Mauricio Espinola, 05-07-2007.
http://www.gestionpublica.cl/gerenciapublica/tema/35/
- Capability Maturity Model Integration (CMMI).
http://es.wikipedia.org/wiki/Modelo_de_Capacidad_y_Madurez
- Portal de Calidad software: http://www.iso15504.es
- “Guía del CMM, para Comprender el Modelo de Madurez de Capacidad del Software”.
Gonzalo Cuevas Agustín; Traducción del Inglés de "A Guide to the CMM" de Kenneth M.
Dymond, 1998. ISBN 10: 0964600803
- “UML, Unified Modeling Language Specification: UML Notation Guide Version 1.3”. OMG
alpha R2, January 1999.
- “Scrum Manager Proyectos”. Juan Palacio, Claudia Ruata. REF.0910244743710
- itSMF (Information Technology Service Management Forum. http://www.itsmf.es
- GARTNER, Consultoría de IT. http://www.gartner.com
- FORRESTER, Consultoría de IT. http://www.forrester.com
- “Requirement Engineering: a good practice guide”. Ian Sommerville, Pete Sawyer, John
Wiley, 1997.
Víctor Lerga Bezunartea 16 de 17
17. Claves para abordar un proyecto TIC Marzo-2010
- “IEEE STD-610. Computer Dictionary”. Compilation de IEEE Standard Computer Glossaries.
IEEE Computer Society, 1990
- “Automated Analysis of Requirement Specifications”. Wilson, Rosenberg y Hyatt.
International Conference on Software Engineering (ISCE ’97), Boston, MA, May 1997.
Víctor Lerga Bezunartea 17 de 17