universidad para la cooperacion internacional proyectos de … · la gestión de proyectos en la...
TRANSCRIPT
UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI)
Administración de expectativas de los stakeholders y la gestión de alcances en proyectos de la DCTIC en BN
RONNY F. ZÚÑIGA PINEDA
PROYECTO FINAL DE GRADUACION PRESENTADO COMO REQUISITO PARCIAL PARA OPTAR POR EL TITULO DE MASTER EN ADMINISTRACION
DE PROYECTOS
San José, Costa Rica
Marzo, 2011
ii
UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI)
Este Proyecto Final de Graduación fue aprobado por la Universidad como
Requisito parcial para optar al grado de Máster en Administración de Proyectos
__________________________ Manuel Álvarez Cervantes
PROFESOR TUTOR
_________________________ Beverly Hernández
LECTOR No.1
__________________________ Eithel Bonilla
LECTOR No.2
________________________ Ronny F. Zúñiga Pineda
SUSTENTANTE
iii
AGRADECIMIENTOS
A mi familia.
iv
INDICE
1 INTRODUCCION .......................................................................................................... 1 1.1 Antecedentes ........................................................................................................... 1 1.2 Problemática. .......................................................................................................... 2
1.3 Justificación del problema ...................................................................................... 2 1.3.1 Objetivo general ................................................................................................. 3 1.3.2 Objetivos específicos. ......................................................................................... 4
2 MARCO TEORICO ....................................................................................................... 5 2.1 Marco referencial o institucional ............................................................................ 5
2.1.1 Antecedentes de la Institución ............................................................................ 6 2.1.2 Misión y visión ................................................................................................... 6
2.1.3 Misión. ................................................................................................................ 7 2.1.4 Visión. ................................................................................................................ 7 2.1.5 Estructura organizativa ....................................................................................... 7 2.1.6 Productos que ofrece .......................................................................................... 8
2.2 Teoría de Administración de Proyectos ............................................................... 14 2.2.1 Proyecto ............................................................................................................ 15
2.2.2 Áreas del Conocimiento de la Administración de Proyectos ........................... 15 2.2.3 Ciclo de vida de un proyecto ............................................................................ 16 2.2.4 Procesos en la Administración de Proyectos .................................................... 16
2.2.5 Gestión de Involucrados. .................................................................................. 17 2.3 Cobit ..................................................................................................................... 18
2.4 ITIL ....................................................................................................................... 18 3 MARCO METODOLOGICO ...................................................................................... 20
3.1 Fuentes de información ........................................................................................ 20 3.2 Fuentes Primeras: ................................................................................................. 20
3.2.1 Juicio experto .................................................................................................... 20
3.2.2 Fuentes Secundaria: .......................................................................................... 21 3.2.3 Métodos de Investigación ................................................................................. 21
3.2.4 Herramientas. .................................................................................................... 23 3.2.5 Supuestos y Restricciones. ............................................................................... 24 3.2.6 Entregables. ...................................................................................................... 24
4 DESARROLLO ............................................................................................................ 26 4.1 Situación actual .................................................................................................... 26
4.2 Fuetes de información .......................................................................................... 29 4.3 Consideraciones relacionadas con metodología de AP institucional .................. 31
4.3.1 Gestión de problemas: ...................................................................................... 31 4.3.2 Gestión de incidentes: ....................................................................................... 33 4.3.3 Gestión de stakeholders: ................................................................................... 34 4.3.4 Gestión de cambios: ......................................................................................... 35 4.3.5 Gestión de niveles de servicio: ......................................................................... 36
4.4 Priorización de proyectos ..................................................................................... 36 4.5 Propuestas de implementación ............................................................................. 37
5 CONCLUSIONES ........................................................................................................ 39 6 RECOMENDACIONES .............................................................................................. 42
v
7 BIBLIOGRAFIA .......................................................................................................... 49 8 ANEXOS ...................................................................................................................... 50
8.1 Anexo 1: ACTA DEL PROYECTO ..................................................................... 50
8.2 Anexo 2: EDT ....................................................................................................... 52 8.3 Anexo 3: CRONOGRAMA ................................................................................. 56 8.4 Anexo #4: Propuesta de procedimientos .............................................................. 57
8.4.1 Procedimiento para la gestión de problemas .................................................... 57 8.4.2 Procedimiento para la gestión de incidentes..................................................... 61
8.4.3 Procedimiento para la gestión de cambios ....................................................... 67 8.4.4 Procedimiento para la gestión de niveles de servicio ....................................... 70
vi
ÍNDICE DE FIGURAS
Figura #1. Organigrama del BN ......................................................... 8 Figura #2. WBS, nivel 1 .................................................................... 52
Figura #3. WBS, seminario de graduación .................................... 53
Figura #4. WBS, tutoría .................................................................... 54
Figura #5. WBS, lectores .................................................................. 54 Figura #6. WBS, tutoría de ajuste ................................................... 55 Figura #7. WBS, defensa ................................................................. 55
Figura #8, cronograma ...................................................................... 56
vii
ÍNDICE DE CUADROS
Cuadro #01: Métodos de Investigación .............................................. 22
Cuadro #02: Herramientas ................................................................... 23 Cuadro #03. Especialistas en proyectos de TI ................................. 26
Cuadro #04, ejemplos de proyectos en TI ......................................... 29
Cuadro #05 entrevistas con directores de proyectos y jefes de la DCTIC ...................................................................................................... 30
viii
RESUMEN EJECUTIVO
El proyecto se realizó para atender una necesidad de atención que enfrenta la gestión de proyectos en la Dirección Corporativa de Tecnología de Información y Comunicaciones del Banco Nacional debido a que en un porcentaje representativo de los proyectos gestados no logra amarrar el alcance definido del proyecto con el logro de las expectativas de los interesados en el proyecto.
Es muy común que los tiempos definidos y los costos de un proyecto sean modificados conforme este avanza, incluso, el mismo alcance del proyecto se puede ver modificado en el transcurso del desarrollo porque los involucrados tienen una visión diferente a la que ven germinar conforme el mismo progresa.
De ahí que se definieron como objetivos base la propuesta de mejoras en lo que gestión de expectativas compete y su relación directa con el alcance definido para un proyecto de la dirección.
Para lograr este objetivo se definieron a su vez tres objetivos secundarios que facilitaran el logro de los mismos, donde se detalla el análisis de la situación actual que permitió determinar las áreas de esmero prioritarias, la priorización para atención y el enfoque de esfuerzos en los puntos que mayor valor agregado a la organización aporten y finalizar con las propuestas de estrategias de implementación a las mejoras sugeridas para guiar el proceso tan ordenadamente como sea posible, obviamente, adaptado a la cultura organizacional del momento.
De ahí que se definió utilizar una metodología que defina claramente los alcances, en primera instancia, donde es importante dejar claro que la metodología de administración de proyectos del Banco Nacional ya tiene un apartado definido y claro sobre este campo, pero que no siempre se respeta y sigue cabalmente.
Como fuentes de información, se utiliza básicamente el criterio experto como fuente primaria, pues son los directores y gestores de proyectos los que viven el problema acotado en este trabajo a diario y los principales afectados con los constantes cambios a los que se ven sometidos durante su gestión.
El estudio y análisis de proyectos finalizados en el pasado por el suscrito brindó a su vez, retroalimentación y fuente primaria de información para lograr sustentar las bases del trabajo, dejando claro el porqué se tomó este tema como base para el proyecto de graduación. Donde a través de las experiencias vividas en sendos proyectos se ha comprobado que el alcance definido para los proyectos no está ligado con el logro cabal de las expectativas de los involucrados.
ix
La propuesta de mejora incluye ajustes a la metodología institucional del banco. Metodología que aunque se respeta, no siempre se sigue como sería lo recomendado.
En un análisis de la situación actual saltan a la vista irregularidades que deben tratarse con prontitud, situaciones como el irrespeto a una metodología catalogada como institucional y que por lo tanto debería delimitar los pasos por seguir para la administración de proyectos en todo el Banco y que es vista como un conglomerado de trámites innecesarios y que se cumplen única y exclusivamente porque la auditoría lo exige son muestras claras de una falta de trabajo de concientización en el campo.
Es necesario también que se contemplen aspectos como la gestión de niveles de servicio, donde se especifique claramente que es lo que se espera lograr de un proyecto y que aunado a una buena gestión de involucrados permita definir de forma explícita las expectativas de los mismos.
También deben contemplarse aspectos post implementación, temas que en proyectos de tecnología de la información son básicos para lograr definir como exitoso un proyecto. Aspectos como la forma como se atenderán los incidentes, los problemas y los cambios en última fase de un proyecto. Su puesta en marcha. Una buena gestión de cambios, de problemas y de incidentes permitirá proyectar la percepción de éxito con los stakeholders, lo que será visto como un cumplimiento cabal a sus expectativas.
El Banco Nacional es una institución líder en cuanto a la administración de proyectos en empresas de su categoría, su nivel de madurez supera con creces a sus similares a nivel nacional, sin embargo aún tiene un importante camino por seguir para mejorar y alcanzar los niveles que una empresa de su alcurnia, líder del mercado financiero nacional con metas y proyecciones a convertirse y mantenerse en la cúspide del mercado financiero latinoamericano. De ahí que la consideración de un proceso de mejora continua y consideraciones de las buenas prácticas que han funcionado para otras instituciones de similar proyección y nivel como lo son Cobit1 e ITIL2 son básicas e importantes para mejorar y superarse continuamente. Entre las recomendaciones más importantes esta la consideración de algunas buenas prácticas que se confían para ser adoptadas y adaptadas a la práctica institucional de administración de proyectos y principalmente para los que tengan que ver con tecnología de la información.
1 Por sus siglas en inglés: Control Objectives for Information and related Technology, es
un conjunto de buenas prácticas desarrolladas para la administración de la información por parte del Information Systems Aaudit and Control Association y el IT Governance Institute. 2 Por sus siglas en inglés: Information Tecnology Infraestructure Library, es un conjunto de
conceptos prácticos para la gestión de servicios de TI.
1
1 INTRODUCCION
1.1 Antecedentes.
La administración y gestión de proyectos es una función compleja, en la
cual, las organizaciones modernas invierten mucho esfuerzo y recursos, con el fin
de asegurar su competitividad y supervivencia en el entorno empresarial moderno.
El desarrollo vía proyectos requiere del uso cada vez más efectivo de
herramientas, metodologías y esquemas sistematizados que permitan asegurar el
éxito en dicha tarea.
En organizaciones como la estudiada, se presentan problemas serios en
cuanto a la definición de alcances y el cumplimiento de las expectativas de los
involucrados, lo que ha sido el motivo principal por el que se ha tomado este
tema para el desarrollo de la propuesta.
Se desea investigar y probar que las metodologías utilizadas actualmente
no son completamente funcionales y requieren de una adaptación a las
necesidades del momento. Pues, casi se podría asegurar que el tiempo
requerido para que un proyecto inicie en su puesta en marcha (producción), es
mucho mayor, del esperado y los niveles relativos de cumplimiento de
expectativas de calidad difícilmente se cumplen. Aunado al hecho de que un
importante porcentaje de proyectos son pasados a producción sin estar
completamente finalizados, lo que provoca descoordinación y atrasos
considerables en el personal relacionado, aumentado por el riesgo de pérdida
financiera o de imagen que podría afectar a la institución.
Es importante dejarle claro a todas las partes relacionadas con la gestión y
administración de proyectos de la institución que las metodologías para el manejo
de materiales, de gestión de comunicaciones, de administración del recurso
humano, incluso de gestión de cronogramas, debe estar siempre enfocada hacia
el logro eficiente de los recursos. Esto para evitar que algunos proyectos cuenten
con asignación de recursos que no sean utilizados y algunos otros, cuenten con
2
un presupuesto muy limitado, lo que repercutiría directamente en el cumplimiento
de expectativas y el alcance deseado para el proyecto.
Otra parte importante por razonar, es el proceso de cierre de un proyecto,
para evitar que cuando un proyecto se finalice se obvie la entrega de
documentación adecuada para el mantenimiento y administración del producto o
servicio final. Lo que podría afectar la vida útil, el mantenimiento y operación del
producto, también los aspectos relacionados con la retroalimentación para futuros
proyectos y por supuesto, la parte que nos atañe para este trabajo, el logro de
expectativas y alcances del proyecto.
1.2 Problemática.
Un mal general en las entidades financieras público-nacionales es la falta de
comunicación. La poca identificación entre las partes se refleja en cada uno de los
relacionados con el desarrollo y gestión de un proyecto. Estos se centran
exclusivamente en “lo que le toca”, se obvian o descartan potenciales mejoras en
las áreas que no son de directa incumbencia. Se sabe, por ejemplo, que los
funcionarios encargados de las pruebas, pocas veces tienen relación con el
desarrollo del producto, lo que podría favorecer y enriquecer las bases del mismo.
De igual forma sucede cuando se realiza el levantado de requerimientos para
iniciar el desarrollo del proyecto, donde no se tienen completamente demarcados
los límites y conforme el mismo avanza, se hacen cambios que afectan desde el
tiempo destinado al proyecto hasta los mismos resultados, de nuevo, procesos
que repercuten en el alcance y las expectativas del proyecto.
1.3 Justificación del problema.
Aunque en el Banco Nacional (BN) el nivel de madurez que se tiene en
cuanto a la gestión de proyectos es vanguardista, comparado con sus similares,
falta trabajar el orden y las secuencias de los procesos acorde con los intereses y
control de alcance, costo y tiempo, a un mayor nivel. Debe respetarse y dar mayor
importancia a la definición de etapas, la planificación de rutas críticas para
delimitar los tiempos de duración de los mismos y la clara definición de lo que se
3
incluirá y lo que no será incluido en el proyecto, o sea, los alcances, y dejar
claramente definidas las expectativas de los involucrados cuando el proyecto
finalice y se vean los resultados del mismo.
En muchos casos la definición de prioridades de un proyecto se hace acorde
al criterio de las más altas jerarquías técnico-administrativas relacionadas con el
desarrollo y utilización del proyecto. Considerando aspectos de cumplimiento de
compromisos adquiridos más que de un estudio formal que solventará una
necesidad del mercado o una oportunidad de mejora para la organización.
Otro importante problema refiere a la falta de uniformidad de trabajo en el
desarrollo de proyectos, pues no todos los jefes tienen la misma forma de trabajar,
y aunque exista una metodología que, en teoría, delimita los lineamientos y
procedimientos por seguir, el trabajar en un proyecto o en otro, pueden ser
experiencias totalmente diferentes, tanto a nivel de desarrollo como de logro de
resultados y cumplimiento de objetivos, igual sucede con el cumplimiento de las
expectativas y el alcance, donde va a depender mucho del patrocinador que se
tenga, lo que conlleva necesariamente a concluir que no hay herramientas claras
para la medición de niveles de calidad relativos para garantizar la satisfacción de
los involucrados y por lo tanto del cumplimiento de sus expectativas.
1.3.1 Objetivo general
Se ha definido el objetivo principal del presente trabajo como:
Proponer mejoras en el proceso de gestión de expectativas y su relación con
el alcance de un proyecto en la Dirección Corporativa de Tecnología de
Información y Comunicaciones del Banco Nacional (DCTIC).
4
1.3.2 Objetivos específicos.
Y para su cumplimiento se han definidos los siguientes tres objetivos secundarios,
los cuales ayudarán a levantar la propuesta acotada, a saber:
Realizar un análisis de la situación actual para determinar las áreas de
atención prioritaria.
Realizar propuestas de priorización para la atención de limitaciones y enfocar
esfuerzos en las zonas de mayor valor agregado.
Proponer estrategias de implementación de las mejoras sugeridas para guiar
el proceso de forma ordenada y de acuerdo a la cultura de la organización.
5
2 MARCO TEORICO
2.1 Marco referencial o institucional
La propuesta se realizará en el Banco Nacional, institución estatal de
carácter autónomo fundada el 9 de octubre de 1914 bajo el nombre de Banco
Internacional de Costa Rica, con vocación hacia el desarrollo agrícola y rural del
país.
El 5 de noviembre de 1936 se le cambió el nombre al de Banco Nacional de
Costa Rica y, desde entonces, se ha consolidado como un verdadero banco de
desarrollo con una proyección trascendente y positiva en la vida económica, social
y financiera del país.
En la actualidad, ante las grandes innovaciones que ha traído la era de la
informática y las telecomunicaciones y, en especial, la enorme competitividad del
sector financiero nacional e internacional, el Banco Nacional se ha transformado
en un banco universal, abarcando todos los sectores del mercado costarricense,
tales como: banca personal, empresarial, corporativa, institucional, bursátil,
pensiones, fondos, sin descuidar su vocación de financiación al desarrollo
económico del país, que sigue siendo su columna vertebral. Su misión es ofrecer
servicios bancarios universales, estandarizados, de alta calidad, seguridad y
confianza, que le proporcionan una alta rentabilidad por medio de una excelente
atención a todos los costarricenses.
El Banco Nacional posee una amplia red de más de 169 oficinas, más de 428
cajeros automáticos en toda la Nación, y cerca de 4.800 empleados. Es la
institución bancaria más grande del país, con un volumen de activos de US$6.661
millones que lo ubican en el primer lugar en Costa Rica y Centroamérica (excluida
Panamá), el Caribe y República Dominicana.
Además, los Corresponsales BN Servicios pueden brindar más de 200
opciones de pagos con empresas públicas y privadas que están en convenio con
6
el banco, y ofrecen la posibilidad de realizar retiros de efectivo y el pago de
tarjetas y operaciones de crédito en más de 1176 establecimientos comerciales en
todo el país.3
2.1.1 Antecedentes de la Institución.
En cuanto a la administración y gestión de proyectos, el BN es una de las
instituciones con un nivel de madurez más robusto en la región, contando con
departamentos formalmente establecidos para la gestión de los mismos y
contando con personal destacado y altamente calificado para su seguimiento y
administración.
Se cuenta con metodologías desarrolladas y adaptadas a las necesidades
institucionales, así como esquemas de administración para priorizar y dar
seguimiento a los proyectos.
Sin embargo, aún hay mucho por mejorar, en especial aspectos como la
segregación entre la gestión de alcances y las expectativas por esperar de un
proyecto por parte de los involucrados, y la gestión de involucrados.
De ahí la necesidad de desarrollar y detallar las recomendaciones que este
trabajo pretende justificar y aportar a la institución en pro del crecimiento y
mejoramiento del nivel de madurez y beneficios por alcanzar para cada caso.
2.2 Misión y visión.
El trabajo se enfocará en una de las áreas de la institución, específicamente
en la Dirección de Tecnología y Comunicaciones, sin embargo, dado que la
institución es una sola en pro del beneficio nacional, la visión y misión de cada
área funcional es la misma que la institución ha adoptado como propias.
Estas se pueden detallar como:
3 Tomado de la página de internet institucional, www.bncr.fi.cr
7
2.2.1 Misión.
Ofrecer eficientemente servicios financieros universales y estandarizados
que sobrepasen las expectativas de sus clientes por medio de: atención
especializada por segmentos, uso de canales electrónicos, el compromiso de
integridad y espíritu de servicio de sus colaboradores, para coadyuvar en la
alfabetización financiera y el desarrollo socioeconómico del país.
2.2.2 Visión.
El Banco Nacional es la principal institución financiera del país, de
propiedad estatal, que impulsa el desarrollo económico y social, ofreciendo
soluciones integrales globalizadas, un servicio de alto valor para sus clientes, con
un recurso humano eficiente, una plataforma tecnológica que facilite el uso
intensivo de productos mediante canales electrónicos, comprometidos con la
sostenibilidad del medio ambiente, con el objetivo fundamental de maximizar la
rentabilidad y mantener una suficiencia patrimonial adecuada.
2.2.3 Estructura organizativa.
La estructura de organización de la institución cambio a finales del año
anterior, adoptando un esquema funcional más moderno y variado y enfocado en
mejorar aspectos como el servicio al cliente y el posicionamiento de la
organización, entre otras cosas.
El organigrama de la institución se representa en la figura número 1. Detalla
a continuación.
8
Figura #1. Organigrama del BN
Fuente: www.bncr.fi.cr
2.2.4 Productos que ofrece
Actualmente el BN ofrece una gran cantidad y variedad de productos y
servicios para los costarricenses, entre los que pueden detallarse.
9
2.2.4.1 BN Internet Banking.
Es una plataforma electrónica que le permite realizar transacciones de
forma rápida y segura, transacciones como transferencias entre cuentas e
instituciones contempladas dentro del sistema SINPE. Pagos de servicios de
instituciones con las que se tengan convenios, pagos de tarjetas de crédito, entre
otra gran variedad de servicios.
2.2.4.2 Internet Banking Corporativo.
Es una plataforma enfocada al servicio de instituciones que requieren de un
servicio especializado a nivel institución y que les brinde ventajas y servicios
diferenciados y adaptados a sus necesidades.
2.2.4.3 BN Banca de Inversión.
Banca de Inversión ayuda a interesados a coordinar toda la prestación de
servicios financieros de la Corporación Banco Nacional en el Mercado de
Capitales de Costa Rica. Trabaja en conjunto para coordinar los servicios
relacionados a puesto de bolsa, administradora de fondos de inversión y
operadoras de pensiones. Y ofrece servicios como:
Titularización Inmobiliaria
Infraestructura Pública
Vivienda
2.2.4.4 BN Banca Hipotecaria.
Es un área de empresas enfocada a los préstamos para vivienda.
Especializada en facilitar servicios como:
Condiciones crediticias
Desarrollos urbanísticos
Prestamos paso a paso
10
Programas especiales
2.2.4.5 BN Comercio Exterior.
El Banco Nacional, mediante la Banca de Comercio Exterior, brinda una
solución integral para los exportadores e importadores que se ajusta a las
necesidades particulares de cada transacción internacional.
Se ofrecen servicios bancarios que cubren todos los procesos del comercio
exterior, desde los medios de pago internacionales más convenientes, hasta la
ubicación de la mercadería en las bodegas del importador. Todo esto
complementado con la asesoría y soluciones personalizadas que se ajustan a las
necesidades particulares de cada cliente, brindadas por un equipo de
profesionales en materia bancaria internacional. Además se cuenta con alianzas
estratégicas a través de bancos corresponsales en el exterior, que garantizan
soluciones eficaces a negocios en cualquier parte del mundo
2.2.4.6 BN Comercio Electrónico.
Es una plataforma que apoya el negocio a través de Internet, utilizando la
plataforma de pagos virtuales BN Comercio Electrónico, el cual ofrecerá a los
comercios afiliados la oportunidad de procesar transacciones Visa y MasterCard
desde su sitio Web.
El Banco Nacional de Costa Rica se ha certificado a los programas Verified
by Visa y MasterCard SecureCode, para brindar por medio de su plataforma de
Pago Virtual, BN Comercio Electrónico el procesamiento de transacciones de
manera segura y con el respaldo de las marcas internacionales.
Estos programas están basados en el protocolo 3-D Secure, tecnología que
sustenta la nueva plataforma del Banco Nacional de Costa Rica y que disminuirá
el riesgo de fraude y contra cargos a los comercios afiliados, autenticando y
autorizando las transacciones en tiempo real.
11
Algunas de las Ventajas que las empresas podrían percibir con esta
funcionalidad son:
Brindar a los consumidores la certeza de que son comercios legítimos.
Aumentar sus ventas al aumentar la seguridad en su página Web.
Obtener nuevas oportunidades de negocio.
Generar aceptación y reconocimiento Internacional.
Disminuir el riesgo de transacciones fraudulentas.
Generar disponibilidad 24 x 7 x 365.
Disminuir el riesgo de inversión en comercio electrónico
Procesar cualquier tarjeta VISA o MasterCard de crédito o débito
internacional y nacional.
Auto- Administrar sus transacciones.
Recibir información inmediata acerca del pedido.
Recibir el pago de sus transacciones en 24 hrs. en su cuenta del BNCR.
2.2.4.7 BN Fiduciaria.
Es un área funcional y enfocada únicamente a los fideicomisos y su
administración, donde enfoca esfuerzos en la atracción de clientes con poder
adquisitivo alto o en su defecto la administración de fideicomisos de carácter
social.
2.2.4.8 BN Fondos.
BN Fondos Sociedad Administradora de Fondos de Inversión, es una
sociedad anónima propiedad 100% del Banco Nacional de Costa Rica. Fue creada
con el objetivo único de prestar servicios de administración de Fondos de
Inversión.
Fue fundada el 29 de abril de 1998, con el fin de administrar Fondos de
Inversión que se inscriban ante la Superintendencia General de Valores
(SUGEVAL), autorizada por el Consejo Nacional de Supervisión del Sistema
12
Financiero en la sesión 61-98 celebrada el 17 de diciembre de 1998 y tiene por
objetivos los siguientes:
Consolidarse a nivel nacional como la sociedad más importante por volumen y
rentabilidad.
Convertirse en motor de desarrollo del mercado financiero mediante la
gestión de figuras novedosas orientadas al mercado de capitales.
Posicionarse en los inversionistas como la mejor Sociedad de Fondos de Inversión
del país.
Masificar los fondos de inversión mediante la red de distribución del Banco
Nacional a través de 169 agencias y sucursales en todo el país.
Gestión de Fondos especiales entre ellos los Fondos Inmobiliarios y los Fondos
Hipotecarios.
El capital social de BN Sociedad Administradora de Fondos de Inversión es
de ¢ 1,500,000,000.00 (mil quinientos millones de colones) suscrito y pagado,
perteneciente en un 100% al Banco Nacional de Costa Rica.
2.2.4.9 BN Páguese.
Es una funcionalidad que le permite a las empresas facilitar los pagos a
proveedores por medio de las plataformas y servicios del BN.
2.2.4.10 BN Salud.
BN Salud es un producto de crédito que le permite al cliente financiar a una
tasa y plazo preferencial, sus problemas de salud tanto propios como los de sus
seres queridos.
Este tipo de financiamiento puede solicitarlo en los hospitales en convenio
con el BN o en las propias oficinas bancarias.
13
2.2.4.11 BN Sucursales / ATMs.
Es el detalle de todas las sucursales y dispositivos de cajeros automáticos
instalados a lo largo del territorio nacional.
2.2.4.12 BN Tarjetas.
Las tarjetas de crédito del Banco Nacional son emitidas con el respaldo de
las marcas VISA y Master Card. Ofrece el beneficio de ser utilizadas como medio
de pago local e internacional o como fuente de financiamiento a través de varias
tarjetas de crédito.
2.2.4.13 BN Turismo.
El Banco Nacional de Costa Rica ha tenido la visión de crear una Dirección
que se especializa en Turismo, lo que representa un paso innovador e histórico
tanto en la Banca Nacional, como en el desarrollo del turismo en Costa Rica.
BN Turismo, inicia una labor muy importante que implica una relación
directa entre el sector turístico nacional e internacional y el Banco Nacional de
Costa Rica.
Esta labor, se enfoca básicamente en desarrollar servicios especializados,
en un sector que involucra muchos actores con quienes se mantiene un lenguaje
en común.
BN Turismo promueve una relación directa entre empresas turísticas,
desarrollo regional, desarrollo comunal, asociaciones, cámaras e instituciones
turísticas, micro y pequeños empresarios con el impulso a crear y mejorar la
infraestructura.
14
2.2.4.14 BN Vital.
Es la operadora de pensiones enfocada a la administración de fondos de
pensión para los costarricenses que lo deseen.
2.2.4.15 Pagos en Línea.
Son pagos con empresas con las que se han creado convenios para
conveniencia del cliente, facilitando el trámite y ahorrando tiempo y recursos en
mutuo beneficio.
2.2.4.16 BN Corredora Seguros.
Es una sociedad anónima dedicada a la correduría de Seguros. Esta figura
es autorizada por la Superintendencia General de Seguros en el mes de octubre
del 2009.
Brinda a sus clientes productos y servicios existentes en el mercado de los
seguros. Y busca ofrecer una buena oferta y con la meta de ir más allá de lo
esperado, con productos creados a la medida de las necesidades del cliente, en
aquellos casos donde el mercado no satisfaga lo que él requiere, elevando así
nuestros estándares de calidad
2.3 Teoría de Administración de Proyectos
Según el PMBOK4: “La dirección de proyectos es la aplicación de
conocimientos, habilidades, herramientas y técnicas a las actividades del proyecto
para cumplir con los requisitos del mismo. Se logra mediante la aplicación e
integración adecuadas de los 42 procesos de la dirección de proyectos, agrupados
lógicamente, que conforman los 5 grupos de procesos.” (Guía del PMBOK 2008,
página 12) y pueden, de igual forma describirse algunos conceptos para facilitar la
asimilación del trabajo, conceptos tales como:
4 La guía del PMBOK es un estándar para la administración de proyectos desarrollada por
el Project Management Institute (PMI).
15
2.3.1 Proyecto.
Es básico contar con la definición clara de lo que es un proyecto, de
acuerdo a lo que se ha estudiado, podría decirse que un proyecto es un esfuerzo
temporal que se lleva a cabo para crear un producto, servicio o resultado único. Y
que la naturaleza temporal de los proyectos indica un principio y un final definidos.
2.3.2 Áreas del Conocimiento de la Administración de Proyectos.
Las nueve áreas del conocimiento mencionadas en la Guía del PMBOK 2008
son:
Gestión de la Integración del Proyecto:
Incluye los procesos y actividades necesarios para identificar, definir, combinar,
unificar y coordinar los diversos procesos y actividades de la dirección de
proyectos dentro de los grupos de procesos de dirección de proyectos.
Gestión del Alcance del Proyecto:
Incluye los procesos necesarios para garantizar que el proyecto incluya todo (y
únicamente todo) el trabajo requerido para completarlo con éxito.
Gestión del Tiempo del Proyecto:
Incluye los procesos requeridos para administrar la finalización del proyecto a
tiempo.
Gestión de los Costos del Proyecto:
Incluye los procesos involucrados en estimar, presupuestar y controlar los costos
de modo que se complete el proyecto dentro del presupuesto aprobado.
Gestión de la Calidad del Proyecto:
16
Incluye los procesos y actividades de la organización ejecutante que determinan
responsabilidades, objetivos y políticas de calidad a fin de que el proyecto
satisfaga las necesidades por la cuales fue emprendido.
Gestión de los Recursos Humanos del Proyecto:
Incluye los procesos que organizan, gestionan y conducen el equipo del proyecto.
Gestión de las Comunicaciones del Proyecto:
Incluye los procesos requeridos para garantizar que la generación, la recopilación,
la distribución, el almacenamiento, la recuperación y la disposición final de la
información del proyecto sean adecuados y oportunos.
Gestión de los Riesgos del Proyecto:
Incluye los procesos relacionados con llevar a cabo la planificación de la gestión,
identificación, el análisis, la planificación de respuesta a los riesgos, así como su
monitoreo y control en un proyecto.
Gestión de las Adquisiciones del Proyecto:
Incluye los procesos de compra o adquisición de los productos, servicios o
resultados que es necesario obtener fuera del equipo del proyecto.
2.3.3 Ciclo de vida de un proyecto
Se definió como un conjunto de fases cuyo número y nombres están
determinados por las necesidades de control de la organización ejecutante. (Guía
del PMBOK 2008, página 303)
2.3.4 Procesos en la Administración de Proyectos
Un proceso es un conjunto de acciones y actividades interrelacionadas
realizadas para obtener un producto, resultado o servicio predefinido. Cada
17
proceso se caracteriza por sus entradas, por las herramientas y técnicas que
puedan aplicarse y por las salidas que se obtienen. El director del proyecto debe
considerar los activos de los procesos de la organización y los factores
ambientales de la empresa. Éstos se deben tener en cuenta para cada proceso,
incluso si no están enumerados de manera explícita como entradas en las
especificaciones del proceso. Los activos de los procesos de la organización
proporcionan pautas y criterios para adaptar dichos procesos a las necesidades
específicas del proyecto. Los factores ambientales de la empresa pueden restringir
las opciones de la dirección de proyectos (guía del PMBOK 2008, página 40)
2.3.5 Gestión de Involucrados.
La gestión de involucrados (stakeholders) permite identificar todas las
personas u organizaciones que reciben el impacto del proyecto y de documentar
información relevante relativa a sus intereses, participación e impacto en el éxito
del proyecto.
En la Guía del PMBOK se define la gestión de stakeholders como el proceso
de identificar a todas las personas u organizaciones que reciben el impacto del
proyecto y de documentar información relevante relativa a sus intereses,
participación e impacto en el éxito del proyecto (Guía del PMBOK 2008, página
363).
Para este caso, la gestión de involucrados es un factor básico por contemplar,
pues la competencia y relación de los implicados con el proyecto y su percepción
de logro de metas y objetivos, junto a la definición de alcances del mismo es la
razón de ser de este trabajo.
En una institución donde los involucrados, además de autorizar los recursos,
tienen la facultad de cancelar o modificar, a su discreción, es muy importante
definir claramente los temas en discusión, el alcance y las expectativas.
18
2.4 Cobit
COBIT ha sido desarrollado como un estándar generalmente aplicable y
aceptado para la práctica del control de Tecnología Informática. Está basado en
los Objetivos de Control existentes de la Information Systems Audit and Control
Foundation (ISACF) mejorados con los estándares internacionales existentes y
emergentes técnicos, profesionales, regulatorios y específicos de la industria. Los
Objetivos de Control resultantes, aplicables y aceptados en forma generalizada,
han sido desarrollados para ser aplicados a los sistemas de información de toda la
empresa.
El término "generalmente aplicables y aceptados" es explícitamente utilizado
en el mismo sentido que los Principios Contables Generalmente Aceptados
(GAAP). Para los propósitos del proyecto, "buenas prácticas" significan el
consenso de los expertos.
En Costa Rica a las entidades financieras que deben acoplarse a las normas
estatales que la SUGEF5 dicta deben cumplir con lo que la ley 1409 solicita, y esta
está basada en una tropicalización de lo que los objetivos de control de Cobit
establecen. Así que cumplir con estas buenas prácticas no solo es bueno por su
contenido y aporte al negocio como tal sino que a su vez garantiza el cumplimiento
de normativas exigidas y obligadas legalmente.
2.5 ITIL
ITIL es el más aceptado acercamiento a la Administración de Servicios de
tecnologías de información (TI) en el mundo. Provee un conjunto de mejores
prácticas para las organizaciones de TI tanto para empresas de orden privado
como públicas.
A Finales de 1980 el gobierno Británico solicitó a la Agencia Central de
Telecomunicaciones y Computadores (CCTA) para que estructurase la gestión de
TI en las agencias del gobierno.
5 Súper intendencia General de Entidades Financieras.
19
El resultado fue la librería de la infraestructura de TI, una librería que detalla
las mejores prácticas en la gestión de TI y la forma en que se deben implementar.
Actualmente es el compendio de best-practices más reconocido y aceptado
para administrar la infraestructura y servicios de TI. Y reconoce como sus
objetivos principales:
Facilitar una gestión con calidad de los servicios soportados por TI.
Aumentar la eficiencia en que los objetivos corporativos son logrados.
Mejorar la eficiencia y la efectividad, y reducir riesgos.
Ofrecer un código de buenas prácticas que mejoren la calidad.
20
3 MARCO METODOLOGICO.
La metodología por emplear está acorde con la definición de alcances y
objetivos de la propuesta, de manera que se definan claramente aspectos como
fuentes de información y metodologías empleadas.
3.1 Fuentes de información.
La fuente básica de información será el juicio experto, donde se tomará como
base el conocimiento de causa que la experiencia ha dado a los involucrados en el
proceso de gestión de proyectos de la DCTIC.
También se tomará información histórica de documentación de proyectos del
área en estudio para analizar el nivel de cumplimiento de expectativas alcanzado y
tomarlo como base para las propuestas que facilitarán el proceso y las propuestas
correspondientes.
3.2 Fuentes Primarias:
Wikipedia define la fuente primaria como “la fuente documental que se
considera material de primera mano relativo a un fenómeno que se desea
investigar” (http://es.wikipedia.org/wiki/Fuente_primaria, 08-marzo-2011).
Para nuestro caso se utilizará como fuente primaria el juicio experto de los
ingenieros involucrados en gestión de proyectos para la dirección.
3.2.1 Juicio experto.
La principal fuente de información será el juicio experto de los involucrados
y directores de proyectos de la DCTIC, quienes a través de su experiencia y
conocimiento brindan una fuente de información básica para la toma de decisiones
y enmarcar las propuestas y por lo tanto el logro de los objetivos.
21
3.2.2 Fuentes Secundarias:
Utilizando la misma fuente de información que se utilizó para definir las
fuentes primarias, puede indicarse que una fuente secundaria es un texto basado
en fuentes primarias, e implican generalización, análisis, síntesis, interpretación o
evaluación (http://es.wikipedia.org/wiki/Fuente_secundaria, 11-marzo-2011).
Entonces, la fuente secundaria utilizada será la documentación relacionada
con proyectos y el historial de cumplimiento de los mismos y el alcance las
expectativas de los involucrados, así como el cumplimiento de alcances de tiempo
y costo. Con esto se tendría retroalimentación sobre el nivel actual de
cumplimiento de expectativas y alcances.
Se tomará como base algunos de los proyectos en los que el sustentante ha
participado y para los cuales se cuenta con información de primera mano y
completamente real sobre los resultados y su cumplimiento.
3.2.3 Métodos de Investigación.
La investigación es la base para la obtención de la información necesaria
para realizar cualquier trabajo, y este caso no es la excepción por lo que podemos
referir al libro de Hernández Sampieri que define la investigación como: “estudio
que tiene como objetivo examinar un tema o problema de investigación poco
estudiado, del cual se tienen muchas dudas o no se ha estudiado antes”,
(Hernández Sampieri, Metodología de la Investigación, 2002).
En este caso en particular, si bien es cierto, la institución cuenta con
suficiente información y conocimiento sobre la gestión de alcances y expectativas,
existe una brecha en la institución en lo que refiere a la cultura sobre la aplicación
y respeto a estos esquemas y los modelos de definición de los mismos. De
manera que se permitan maximizar los resultados. Esto porque es más común de
lo que se pensaría de una institución con un buen grado de madurez en la gestión
de proyectos.
22
Específicamente, para cada objetivo se utilizará el siguiente esquema de
investigación.
Cuadro #01: Métodos de Investigación.
Objetivos Métodos de Investigación
Inductivo-Deductivo Observación
Proponer mejoras en el proceso de gestión de expectativas y su relación con el alcance de un proyecto.
A partir de los resultados reflejados en algunos de los proyectos tomados como base, se podría generalizar y especular sobre la gestión de alcances y de expectativas para los demás proyectos similares.
Se observará y analizará a fondo el modelo empleado de definición de expectativas y alcances en la DCTIC.
Realizar un análisis de la situación actual para determinar las áreas de atención prioritaria.
N/A Definiendo las áreas de atención prioritaria junto al análisis de los involucrados se podrá aplicar la mejor metodología y maximizar resultados del análisis y priorización de zonas por atender.
Realizar propuestas de priorización para la atención de limitaciones y enfocar esfuerzos en las zonas de mayor valor agregado.
Se analizará la priorización de requerimientos y proyectos para definir un modelo “genérico” aplicable a la mayoría de proyectos de manera que abarque la mayor y mejor atención a limitaciones y maximice el aporte al logro de objetivos.
A partir de entrevistas con los involucrados se podrá obtener la información necesaria para realizar la priorización y enfocar en esfuerzos en las zonas con mayor probabilidad de aportes valiosos y de mayor impacto en el proyecto.
Proponer estrategias de implementación de las mejoras sugeridas para guiar el proceso de forma ordenada y de acuerdo a la cultura de la organización.
A partir de entrevistas y revisión de documentación podrá obtenerse información por contemplar como base para las sugerencias y la metodología por seguir.
Fuente: propia.
23
3.2.4 Herramientas.
La primera herramienta por utilizar será la entrevista con algunos de los
involucrados, Wikipedia define entrevista como una reunión entre dos o más
personas; Con el fin de que se obtenga información sobre un tema
(http://es.wikipedia.org/wiki/Entrevista, 11-marzo-2011).
Para este caso en particular, las entrevistas se realizarán tanto a jefes como
a los encargados de proyectos, lo que permitirá tabular resultados que serán base
para toma de decisiones y montar las propuestas definidas en los objetivos del
presente trabajo.
La otra herramienta básica y necesaria es el juicio experto, que podríamos
definir como el análisis de la percepción de un especialista con amplio
conocimiento de causa y plausible confianza sobre una situación particular. Para
lo cual se valorarán los aportes que un grupo de especialistas en la administración
de proyectos podrían brindar.
Cuadro #02: Herramientas.
Objetivos Herramientas
Proponer mejoras en el proceso de gestión de expectativas y su relación con el alcance de un proyecto.
Juicio experto.
Realizar un análisis de la situación actual para determinar las áreas de atención prioritaria.
Entrevista.
Realizar propuestas de priorización para la atención de limitaciones y enfocar esfuerzos en las zonas de mayor valor agregado.
Entrevista.
Proponer estrategias de implementación de las mejoras sugeridas para guiar el proceso de forma ordenada y de acuerdo a la cultura de la organización.
Entrevista.
Fuente: propia.
24
3.2.5 Supuestos y Restricciones.
3.2.5.1 Supuestos:
Un supuesto es una premisa, una consideración que se da como cierta y se
prepara para enfrentar las consecuencias que puedan acarrearse. Por otro lado,
las restricciones son las consideraciones que afectan y limitan el proyecto.
En este caso, el más importante supuesto es que se contará con la venia de los
directores y altos niveles jerárquicos de la institución y aceptarán las propuestas
como medidas de mejora y aumento en el nivel de madurez institucional en el
tema de la administración profesional de proyectos.
Otra será que la implementación del esquema y las propuestas que resulten
del presente trabajo no están contempladas en el mismo.
Y finalmente, no se define ni se considera presupuesto alguno para el
presente trabajo.
3.2.5.2 Restricciones:
Una de las restricciones más relevantes es el acceso a la información, de ahí que
se tomará como base la experiencia y la información disponible a partir de los
proyectos que el autor del presente trabajo tiene a disposición y en los cuales se
ha participado, los cuales son de peso para la institución, además, en cuanto a
cantidad permite extrapolar las conclusiones y resoluciones generadas a partir de
sus memorias.
3.2.6 Entregables.
Un entregable es un documento que permite valorar el avance del proyecto,
es un documento que permite valorar el porcentaje de avance y el cumplimiento
de los compromisos adquiridos, además constituye una herramienta para valorar a
25
tiempo si es necesario aplicar medidas correctivas para “re direccionar” un
proyecto.
Para este proyecto en particular se han definido los siguientes entregables.
Informe de situación actual
Diagnóstico de áreas críticas
Propuesta de priorización de áreas.
Propuesta de mejoras al esquema de comunicación.
26
4 DESARROLLO
La idea de realizar un análisis que permita desarrollar la gestión del alcance
de un proyecto procurando la satisfacción de las expectativas por parte de los
involucrados, tiene relación directa con la situación que diariamente viven los
directores y líderes de proyectos en la organización y específicamente en la
DCTIC. De ahí que es menester iniciar con un diagnóstico de la situación actual
previo a la generación de propuestas de mejora y detalle de consideraciones por
contemplar.
4.1 Situación actual.
El Cuadro #03 siguiente, muestra a los especialistas del área de TI que
cuentan con vasta experiencia en la administración y gestión de proyectos, los
cuales se entrevistaron:
Cuadro #03. Especialistas en proyectos de TI.
Nombre Puesto Dirección funcional
Danilo Segura M. Jefe de Acreditación Dirección de Ingeniería de Sistemas de TI
Glen Urbina R. Director de Proyectos TI Dirección de Gestión de Estrategia y Proyectos de TI.
Cilliam Cuadra Director Seguridad y Cumplimiento de TI
Dirección de Seguridad y Cumplimiento de TI
Mario Arguedas Jefe Internet Banking Dirección de Apoyo Institucional a Usuarios
Aníbal Ortiz Jefe proyectos de infraestructura
Dirección de Análisis del Negocio
Oscar Cambronero Jefe proyectos de aplicación
Dirección de Análisis del Negocio
Fuente: propia.
Después del análisis de sus comentarios se obtiene como denominador
común que aunque se defina el alcance de un proyecto no se considera ninguno
de los factores que se desarrollan a continuación:
27
Gestión de problemas
Gestión de incidentes
Gestión de stakeholders
Gestión de cambios
Gestión de niveles de servicio
Lo anterior indica que el modelo actualmente empleado debe mejorarse para
incluir estos aspectos y lograr los beneficios de una metodología más completa y
eficiente. Que considere buenas prácticas que en otras latitudes ha funcionado y
la experiencia de especialistas recomienda.
Con cada uno de ellos se analizó la situación basado en su experiencia en
proyectos de diferente tipo, injerencia, impacto, costo para la institución y en todos
los casos el patrón fue similar.
También se logró detectar una fuerte apatía hacia la utilización de la
metodología institucional y todos coinciden en que se usa porque la auditoria lo
exige y no porque crean que sea la mejor herramienta para guía en los proyectos.
De hecho algunos de los proyectos más importantes no han respetado la
metodología institucional y por lo tanto no han definido alcances pero si han
logrado cumplir con creces las expectativas de los interesados, proyectos como
por ejemplo el de identidad virtual, el cual ha ganado premios a nivel internacional
y que obvió por completo los lineamientos institucionales que según el director del
proyecto: el riesgo de no lograr los beneficios es menor que el riesgo de retraso
por adoptarlos.
Otro proyecto, ejemplo de proyecto exitoso, que se realiza sin la aplicación
de la metodología institucional es el proyecto de internet banking desde el punto
de vista de alcance de expectativas de stakeholders.
Este proyecto estaba programado para durar año y medio pero su duración
superó los 6 años, como resultado se dio un incremento importante a nivel de
utilización, rendimiento y posicionamiento del mercado, logrando convertirse en el
28
canal bancario mejor diseñado, más completo y más seguro a nivel nacional, y
además, uno de los mejores portales financieros a nivel latinoamericano.
La gestión de proyectos en la DCTIC se hace respetando un manual
institucional para la administración de proyectos sin embargo este manual no
detalla aspectos como la gestión de expectativas y por lo tanto simplemente se
obvia o se considera como parte de la gestión de proyectos, sin darle el énfasis o
la importancia que requiere, afectado el resultado final del mismo y por lo tanto
incurriendo en reproceso o modificaciones a fechas y costos relacionados con la
operativa del día a día.
En este mismo trabajo está bien definido un apartado para la gestión de
alcance, donde se detallan los pasos y componentes utilizados para la adecuada
definición del mismo sin embargo se incurre en dos grandes faltas, la primera
refiere a la falta de conocimiento del mismo por parte de los directores de
proyectos de la DCTIC, esto es fácilmente comprobable al muestrear algunos de
los proyectos que ahí se manejan, donde se obvian aspectos tales como la
creación del WBS6 o las autorizaciones a modificaciones durante la marcha del
proyecto.
La segunda aplica para casos donde obvia aspectos relacionados con la
gestión de stakeholders, y su efecto en el alcance y por lo tanto en las
expectativas por alcanzar en el proyecto.
Un importante aspecto relacionado con la gestión de proyectos en la DCTIC,
refiere a la forma como se define el alcance de un proyecto, esto porque en
ocasiones se acopla al cumplimiento de compromisos adquiridos o solicitudes de
terceros para el mismo, o incluso se define el alcance conforme el tiempo que
alguno(s) de los directores o jefes involucrados necesita que se finalice y no
basado en análisis técnicos y fundamentados para maximizar resultados y la
utilización de recursos invertidos.
6 Work Breakdown Structure.
29
Uno de los jefes con quien se habló sobre el tema comentó una analogía que
vale la pena acotar en este momento, dijo: “…si Usted contrata una constructora
para que le hagan una casa y les dice, quiero una casa en concreto, con tres
cuartos, dos baños, una cochera para dos carros, una sala y una cocina; ellos no
saldrán corriendo a construirla, primero hacen un análisis de suelos, analizan el
presupuesto, preparan varios diseños de las casas para conversar y negociar con
el dueño de la casa. Pues en la DCTIC es similar el caso, pero ahí si salimos
corriendo a hacer la “casa”… si un usuario solicita un reporte se hace sin siquiera
hacer un análisis de costos, de tiempo, de expectativas, etc...” Lo que refleja un
problema de madurez en lo que a gestión de proyectos refiere y un serio problema
metodológico que debe atenderse y corregirse cuanto antes.
4.2 Fuentes de información.
Como base de información para el proyecto se ha hecho un muestreo de
proyectos según lo muestra el Cuadro #04, para obtener resultados que respalden
los argumentos en este trabajo referidos. De ahí que se tomaron los siguientes
proyectos:
Cuadro #04, ejemplos de proyectos en TI.
Proyecto Finalización, según cronograma inicial
Finalización, última versión de cronograma
Diferencia de tiempo
Sistema de Crédito.
18/12/2001 01/02/2005 3 años, 1.5 meses
Recursos Humanos.
14/12/2001 05/01/2005 3 años, 0.5 meses
Distribución de listados.
22/09/1999 09/03/2001 5.3 meses
Fuente: propia.
-Las fechas y nombres de los proyectos fueron modificados para proteger la
confidencialidad institucional, ya que se considera información susceptible y
delicada ante el acceso público.-
30
De la entrevista a jefes y directores de proyectos para obtener su criterio al
respecto de primera mano, donde los resultados obtenidos se pueden ver en el
siguiente Cuadro #05:
Cuadro #05 entrevistas con directores de proyectos y jefes de la DCTIC.
Tema Comentario Observación
Metodología de administración de proyectos del BN.
En resumen, los directores entrevistados coinciden en que la metodología actualmente implementada en la institución es poco práctica y se respeta solo porque es requisito para cumplir con la auditoría, no porque se entienda como una herramienta para el mejoramiento continuo y formal de la metodología.
Falta cultura en lo que respecta a la metodología de administración de proyectos, debe entenderse que es una guía y una base para una administración eficiente y eficaz de proyectos.
Priorización de proyectos.
Cuando se asignan varios proyectos no se establece un modelo de priorización de proyectos que permita distribuir los recursos disponibles de la mejor forma.
Un modelo que permita priorizar la asignación de recursos es básico en la administración de proyectos.
Gestión de alcances. Los alcances definidos en el inicio de un proyecto no siempre se respetan y en muy pocas ocasiones se cumplen tan cual han sido definidos en un inicio, los cambios en el alcance son constantes y en muchas ocasiones representan un replanteamiento de tiempos (cronograma) y asignación de recursos. En algunos casos se indica que los trámites burocráticos a que se ven obligados por respetar para el cumplimiento de requisitos obligatorios, casos que son ampliamente conocidos y por lo tanto
Una metodología bien definida y con un modelo fácilmente respetable y detallado de su apartados ayudaría a su gestión de alcance. Sin embargo, un aspecto base por tratar estaría ligado al respeto del plan de proyecto por parte del patrocinador, quien al fin de cuentas será quien tiene el poder de hacer cambios sustanciales en un proyecto determinado.
31
deberían ser considerados en el proceso de gestión de los proyectos.
Gestión de expectativas.
No se considera en ningún momento el cumplimiento de las expectativas de ningún involucrado que no sea el patrocinador.
Este es un aspecto base por mejorar.
Fuente: propia.
4.3 Consideraciones relacionadas con metodología de Administración de Proyectos (AP) institucional.
Como puede notarse en el cuadro anterior, en la metodología actual
empleada por el BN y por lo tanto por la DCTIC, no se contemplan aspectos
básicos y que por lo tanto dejan un importante escollo en el alineamiento que debe
existir entre el logro de los alcances de un proyecto y el cumplimiento de las
expectativas de los stakeholders.
Entre ellas las más importantes son:
4.3.1 Gestión de problemas:
En los proyectos de tecnología contemplar aspectos post implementación
está íntimamente ligado con el cumplimiento de las expectativas de los
involucrados.
No se está considerando la gestión de problemas en la metodología actual,
lo que impide definir modelos de atención para casos donde algún inconveniente
se presente y que, potencialmente, significaría un importante escollo en el
cumplimiento de metas y objetivos, y por lo tanto significar un desplome de fechas,
compromisos, puesta en producción, y en general del cumplimiento de
responsabilidades adquiridas para la finalización y cumplimiento cabal del
producto o servicio que el proyecto busca satisfacer.
Una efectiva gestión de problemas requiere de la identificación y clasificación
de problemas, el análisis de las causas desde su raíz y su resolución. El proceso
32
de administración de problemas también incluye la identificación de
recomendación para la mejora, el mantenimiento de registros de problemas y la
revisión del estatus de las acciones correctivas. Lo cual mejora los niveles de
servicio, reduce costos, mejora la conveniencia, satisfacción del usuario y por lo
tanto del más importante stakeholder de un proyecto que se enfoque en la
satisfacción total al cliente.
Un proyecto de TI debería enfocarse en garantizar la satisfacción de los
usuarios finales y para ello debe brindar promesas de servicio y niveles de servicio
acordes con lo esperado, reducir el re trabajo, los defectos de prestación de los
servicios y de las soluciones.
La metodología de administración de proyectos del BN no contempla gestión
de problemas que permita dictar pautas para registrar, rastrear y resolver
problemas operativos y técnicos, ni busca investigar la causa raíz de todos los
problemas relevantes y definir soluciones definitivas.
Es importante que se consideren en la metodología el análisis que debe
realizar para la detección y atención de problemas reportados, realizar un análisis
de tendencias que permita, de forma proactiva, determinar situaciones similares
que puedan presentarse a futuro y por lo tanto afectar de igual manera el producto
o servicio y, obviamente, las expectativas de los involucrados.
También existe una falta completa de asignación de prioridades a los
problemas de manera progresiva, siempre guardando una relación costo beneficio
en su atención y seguimiento.
No existe tampoco una forma de medir y controlar el número de problemas
recurrentes con impacto en el negocio, el porcentaje resuelto dentro del periodo de
tiempo solicitado y la frecuencia de los reportes o actualizaciones sobre un
problema en curso, con base en la severidad.
33
4.3.2 Gestión de incidentes.
Muy de la mano con la gestión de problemas, no existe un modelo para la
gestión de incidentes como parte de una metodología que busca no solo cumplir
con el logro de los alcances definidos para el proyecto sino también con la
satisfacción de las expectativas de los involucrados.
Los incidentes requieren de una atención inmediata a un evento que se
presente y que afecta el servicio para el cual fue gestado el proyecto y por lo tanto
debe contemplarse desde su inicio un modelo que permita atenderlos de la mejor
forma.
Básicamente lo que se debe buscar es tener un tiempo de respuesta
oportuno y efectivo a las consultas y problemas de los usuarios finales. Se debe
establecer un modelo de atención y escalamiento de incidentes, análisis de
tendencias, análisis de causa-raíz y resolución en una escala de tiempo que
permita recuperar el servicio o sistema tan pronto como sea posible y afectar al
stakeholder lo menos posible.
Los beneficios que una buena gestión de incidentes podría aportar al negocio
contempla un incremento en la productividad gracias a la resolución rápida de
consultas. Y además, el negocio podría identificar la causa raíz de un evento a
través de un modelo de reportes efectivos y bien estructurados, como por ejemplo
un pobre entrenamiento a usuarios.
En este apartado especial y particular, debe considerarse a la Dirección de
Apoyo Institucional a Usuarios desde un inicio, porque son ellos quienes
detectarían en primera instancia una situación anómala, tanto por llamadas de
usuarios como por monitoreo a sistemas y por lo tanto quienes darían la voz de
alerta a los encargados de corregir la situación con la prioridad del caso.
Es importante también en este apartado, medir y cuantificar el nivel de
satisfacción del stakeholder como usuario final y el porcentaje de incidentes
34
resueltos dentro del lapso de tiempo que se defina como aceptable o acordado. Lo
que permitiría garantizar que los involucrados mantengan un nivel de expectativas
satisfechas junto al alcance del proyecto. Objetivo del presente trabajo.
4.3.3 Gestión de stakeholders.
Una institución con un nivel de líder en la administración de proyectos como
es el Banco Nacional debe, definitivamente, contar un modelo de gestión de
stakeholders como uno de sus principales puntos en la metodología institucional
de administración de proyectos.
Este aspecto es básico y necesario si se quiere lograr un equilibrio entre el
logro de los objetivos, alcances y expectativas.
La Guía del PMBok en su más reciente edición (cuarta edición) en el capítulo
dedicado a la gestión de comunicaciones de un proyecto (capítulo 10) incorpora
un apartado dedicado a la gestión de expectativas de los interesados y detalla la
importancia de contemplar a los involucrados desde un inicio en la gestión de un
proyecto, aspecto en que se está fallando en la metodología empleada en el BN.
De esta forma se puede ver como un grave problema que la metodología
institucional no contemple un modelo que permita administrar a los involucrados a
nivel de TI y direcciones relacionadas para un proyecto, de manera que se
contemple la relevancia de un proyecto, un estudio exhaustivo de su injerencia, su
efecto, su impacto y hasta los riesgos de su consideración y a su vez
interrelacionarlo con su respuesta ante las diferentes situaciones que puedan
presentarse a lo largo del desarrollo de un proyecto.
Entonces, un modelo de gestión con los stakeholders enfocado a los
resultados, de manera que a través de ellos se logren insumos suficientes para
considerar las diferentes situaciones que puedan enfrentarse durante el desarrollo
del proyecto y después de implementado, el mismo es inexistente en la
metodología actual.
35
El impacto que los diferentes stakeholders puedan tener en un proyecto de TI
es tan variado y podría ser tan representativo que el mismo proyecto puede
fracasar si no se consideran. En este caso, para el alcance del proyecto y el logro
de sus expectativas es fundamental que una buena gestión de involucrados sea
contemplada en la metodología y el manual institucional de gestión administración
de proyectos.
4.3.4 Gestión de cambios.
En un proyecto de TI la gestión de cambios es básica por contemplar en una
buena gestión de proyectos, se relaciona tanto con el alcance como con las
expectativas de los involucrados.
Todos los cambios, incluyendo los de emergencia o los parches que surjan
de un proyecto y que estén relacionados con la infraestructura y las aplicaciones
de TI en ambientes de producción deben administrase formalmente y por lo tanto
deben incluirse en una metodología de administración de proyectos. Cualquier
cambio que afecte un procedimiento, un proceso, un sistema o incluso los
parámetros de sistemas que brinden servicios pueden afectar la prestación y por
lo tanto la expectativas de algunos de los involucrados. De ahí que se deben
registrar, evaluar y autorizar, proceso que debe quedar claramente plasmado en el
plan del proyecto y deben contemplarse en el desarrollo del proyecto y
relacionarse con los alcances y metas del proyecto. La razón es simple y clara, se
garantiza la reducción de riesgos que puedan impactar negativamente la
estabilidad o integridad del ambiente de producción y por lo tanto impactar de igual
o en mayor manera las expectativas de los involucrados, aunque el alcance del
proyecto se haya cumplido según lo acordado.
Para esto algunas buenas prácticas como Cobit o ITIL ya han desarrollado
capítulos sobre el tema y coinciden en que son muy importantes y que ayudan a
controlar la evaluación del impacto y brindan recomendaciones técnicas para
minimizar errores que se deban a especificaciones incompletas o consideraciones
que queden fuera del control del proyecto.
36
4.3.5 Gestión de niveles de servicio:
Otro importante aspecto por considerar, que en la metodología de proyectos
del BN y la de DCTIC se obvian y que son base para alcanzar la satisfacción de
expectativas del cliente que está de la mano con el alcance del proyecto es la
gestión de niveles de servicio, en este apartado se deben definir y documentar
acuerdos de servicio para TI que faciliten la comunicación efectiva con los
stakeholders e incluso con los clientes mismos (aunque también podrían
considerarse como stakeholders, dependiendo del proyecto).
Este proceso debe contemplar un monitoreo oportuno y eficiente de los
involucrados tanto durante el desarrollo del proyecto como después de finalizado
el mismo, por lo que sería importante dejar plasmado en la metodología de
seguimiento a un proyecto en su fase de post-implementación los modelos de
control y seguimiento por seguir para velar por el cumplimiento de los niveles de
servicio definidos.
4.4 Priorización de proyectos.
Del mismo análisis con los especialistas se obtuvo la información de que no
todos los proyectos son priorizados de la mejor forma, en algunos casos se
cancelan algunos porque a criterio del director es mejor darle prioridad a uno que
él considera de mayor cuantía, pero no se realiza un estudio formal de costo
beneficio para analizar su cierre o cancelación o incluso lo que puede costar a la
institución posponerlo por un tiempo indefinido. De esta forma la priorización de
atención a proyectos será acorde con lo que mande el director corporativo o el
director dueño del producto, no como respuesta a un estudio formal sobre el valor
agregado que podría generar a la institución.
Comúnmente, la priorización se da para casos donde los recursos no dan
abasto con la carga de trabajo, para lo cual se define qué proyectos son más
urgentes.
37
En resumen, este es un punto que requiere de trabajo a nivel de TI, siempre
hay proyectos importantes en los que se deben trabajar, todos son urgentes y
todos deben terminarse en el tiempo deseado y con las condiciones deseadas, por
lo que en muchos casos los directores y jefes que lideran estos proyectos deben
enfrentar situaciones de limitación de personal y organización que les permita no
solo salir adelante con el o los proyectos asignados sino mantener la operativa de
servicios que sustentan las finanzas y la razón de ser del Banco.
La metodología tampoco contempla la situación del BN de acuerdo a lo que
se ocupa, debería considerarse una mejora sustanciosa donde se incorporen
aspectos que formalmente sean discutidos. Como la gestión de stakeholders,
gestión de problemas, gestión de incidentes, gestión de cambios y una adecuada
gestión de niveles de servicio. De manera que cada punto sea contemplado de
manera ágil y sin que implique trámites burocráticos que creen resistencia a la
adopción de un modelo de formulación y administración de proyectos que permita
trabajar de forma estandarizada y ordenada.
4.5 Propuestas de implementación
Todo proceso de mejora continua debe seguir un orden lógico y simple, de
manera que modificaciones al “modus operandi” de la organización no se vea
afectado por un factor extra al que implica luchar contra una cultura que está
empezando a asimilar la metodología de administración de proyectos. De ahí que
las propuestas de implementación de mejoras deben ser aplicadas tomando en
cuenta la resistencia al cambio lógica y entendible que todo nuevo proceso, se
proponen cambios pausados, comedidos que brinden frutos y permitan a los
interesados ver los resultados y por lo tanto aceptar como positivo el cambio y
continuar con el proceso de mejora continua.
El primer punto por implementar está ligado a la creación de procedimientos
claros y obligatorios enfocados a la gestión de problemas, gestión de incidentes,
38
gestión de cambios y gestión de niveles de servicio para toda la dirección.
Procedimientos acoplados a un modelo institucional pero que no estén focalizados
a una única dirección funcional sino que vean a toda la DCTIC como una “banda”
donde cada dirección es un eslabón de una cadena donde todos los participantes
tienen un papel fundamental. Una propuesta de estos procedimientos están
suministrados en el anexo #4.
Para el caso específico de la gestión de stakeholders debe trabajarse según
ajustes a la metodología de administración de administración de proyectos
empleada por el BN y para ello puede basarse en las buenas prácticas dictadas
por la Guía del PMBOK y referidas en el presente trabajo.
39
5 CONCLUSIONES
El nivel de madurez de la DCTIC y del BN en general es bastante robusto sin
embargo debe trabajar aspectos clave como la gestión de alcances, de
involucrados y de expectativas. De esta manera la cultura debe trabajarse en lo
que refiere a la administración de proyectos, alcance de expectativas y definición
de alcances, proceso que debería empezar con el patrocinio y apoyo de los altos
niveles jerárquicos.
Otro aspecto importante por mejorar es el manual institucional de manera
que se plasmen claramente aspectos como la gestión de stakeholders y la gestión
de expectativas, aspectos que hasta el momento no son abordados del todo.
Deben estudiarse con un importante grado de profundidad la gestión de
problemas, de incidentes y de niveles de servicio como parte de la metodología
por aplicar en la administración de proyectos, no solo a nivel de TI, sino a nivel de
toda la institución.
El manual de administración de proyectos empleado en el BN no es funcional
para proyectos de TI, no solo porque no se aplica de la mejor forma, sino porque
para los jefes y directores de proyectos es más una carga y una guía “obligatoria”
por seguir que un conjunto de buenas prácticas que les permitirá guiar su proyecto
hacia el logro de los objetivos planteados dentro del marco de tiempo, alcance y
costo definido.
Los constantes cambios en el rumbo de un proyecto de TI afectan de
sobremanera el cumplimiento del alcance dentro del rango de tiempo definido y
bajo la proyección de costos estimada.
El personal destinado a trabajar en proyectos de TI debe estar capacitado y
entrenado no solo en los aspectos técnicos que enfocan los proyectos sino
también en la metodología empleada y diseñada por la institución, así como en
40
conocimientos a nivel importante en lo que a las buenas prácticas de PMI, ITIL y
Cobit recomienda.
La cultura organizacional es considerablemente débil y la incertidumbre de
no conocer el detalle de los cambios que puedan avecinarse hace que el nivel de
productividad no sea el esperado.
No se tiene un modelo de priorización de proyectos que permita valorar
aspectos como el costo beneficio o el valor agregado al negocio que podrían
aportar para utilizarlo como base y seleccionar a los de mayor impacto como
prioritarios.
No se tiene un “modos operandi” estandarizado por parte de los directores y
jefes, cada uno trabaja según lo que consideran mejor, así que en caso de una
sucesión de procesos o un cambio de manos en la dirección de un proyecto se
presentaría una discordia en las interpretaciones de lo que se hace o deja de
hacer.
Se presenta falta de apoyo de jefaturas en proyectos –que algunos jefes
pueden considerar de bajo impacto para el negocio- lo que podría significar
atrasos y mala utilización de recursos.
El manual institucional considera recomendaciones de buenas prácticas del
PMI que según los involucrados del BN, que para casos específicos de TI se
queda corto y es poco funcional.
La metodología institucionalmente adoptada para la administración de
proyectos, aunque está debidamente definida promulgada, no es ni conocida ni
respetada por quienes deberían conocerla de memoria; lo que provoca que el
control sobre la calidad, la estandarización y los resultados finales de los
procesos, no sea el unificado para una institución de esta envergadura.
La definición de variables procedimentales para las metodologías utilizadas.
Aspectos como tamaño, vida del proyecto, y otros requeridos, como presupuesto y
41
calendarización de resultados no son considerados como básicos para lograr
cumplir con los objetivos, con la visión y misión del proyecto. Visión y misión que
en muchos de los casos no se tienen claras con el desarrollo y administración de
un proyecto.
42
6 RECOMENDACIONES
El ajuste más importante por hacer refiere a actualización al manual de
administración de proyectos del BN, donde se incorporen consideraciones
específicas al modelo de comunicaciones para proyectos y un apartado
especialmente importante enfocado a la gestión de stakeholders.
Las empresas de hoy en día deben tener muy claro que deben adoptar como
parte de su filosofía laboral el planeamiento estratégico como instrumento para
visualizar escenarios y definir los objetivos que logren ubicarlos en una posición
deseada y acorde con sus esfuerzos e inversiones. Es por esto, que la gestión de
proyectos en el BN y particularmente en la Dirección Corporativa de Tecnología de
Información y Comunicaciones, representa la herramienta de expresión básica
para el posicionamiento de los servicios brindados.
Estas condiciones requieren de la utilización de procedimientos apropiados,
operados por personal altamente motivado, en aprendizaje permanente y con
capacidad de innovarlos constantemente. Adaptando y adoptando las buenas
practicas que en otras latitudes han funcionado que bajo un estudio formal podrían
aportar beneficios cuantificables a la institución, como sería específicamente el
caso de Cobit e ITIL.
Es necesario que quede claro que los sistemas de gestión de proyectos no
surgen por generación espontánea, ni su actualización y administración puede
estar en la potestad de los empleados operativos ni en la de los mandos medios –
quienes sólo pueden hacer lo que sus gerencias les ordenan o permitan-. Es claro
que la responsabilidad de fomentar su utilización y hacer que operen
satisfactoriamente, es exclusiva de los estratos de dirección y gerenciales.
Los puestos de directores deben enfocar sus esfuerzos en puntos básicos
como:
43
1. Satisfacción de sus clientes por la entrega de productos y servicios
apropiados, oportunos y de costo razonable.
2. Liderazgo que genere entusiasmo por los resultados que se alcanzan
en la organización.
3. Recursos humanos calificados, altamente motivados y proactivos.
4. Sistemas y procesos operativos de calidad.
5. Disposición y habilidad de todos para mejorar constantemente, a la
vez que para innovar de forma oportuna, cada vez que en el entorno
aparecen nuevas ofertas de productos o tecnologías que dan mejores
servicios a los clientes.
Todos los encargados de la gestión de proyectos en la organización deben
tener muy claro que una organización que rige su quehacer por rutina, se
convierte rápidamente en una entidad obsoleta. Y a partir de ahí, se deben definir
las rutas por seguir para convertir, a partir de proyectos diferenciadores basados
en una metodología eficaz y eficiente, la institución en la que marque la diferencia
en el mercado, de manera que se mantenga el liderazgo que hasta el momento es
sobresaliente en el BN.
Es conveniente que la instrucción adopte y adapte en su política de gestión
de proyectos el estudio de factibilidad con su debido desglose y análisis puntual.
En cada uno de los seis7 aspectos considerados, en un estudio de esta índole, se
determinan y definen aspectos necesarios para la aprobación, el desarrollo, el
seguimiento y la implementación de proyectos eficientes, rentables y acordes con
la capacidad de la institución. Aspectos que no están siendo considerados con la
importancia requerida en la metodología institucional para el debido análisis de
costo-beneficio, mucho menos bajo el nivel cultural que tiene el Banco y la DCTIC
en este momento.
7 Factibilidad comercial, factibilidad técnica, factibilidad legal, factibilidad organizacional,
factibilidad económica y financiera y factibilidad ambiental.
44
Debe promoverse también un ambiente de clima organizacional agradable,
que permita florecimiento de valores como espíritu de servicio al cliente, trabajo en
equipo, creatividad y lealtad en su “identificación” laboral. Con lo que se obtiene
un importante paso hacia la pro actividad tan deseada en los empleados y tan
necesitada en los encargados de implementar los proyectos.
Contar con personal identificado, logrará que los funcionarios trabajen con
entusiasmo y no sólo por obligación, lo que marcará una diferencia radical en los
resultados. Gran cantidad del personal trabaja sólo por la paga y por lo tanto, se
dedican a hacer lo mínimo necesario para “cumplir” con la jornada laboral.
Actualmente, algunos jefes y directores de proyectos de TI tienen ideado en su
modo de operación el concepto de descubrir a quienes hace mal las cosas con el
fin de reprimirlos, incluso el trabajo o la asignación a un proyecto lo ven como un
premio a la buena labor de un empleado en particular, aunque no sea el óptimo
para el proyecto. Esto debe ser cambiado por la política de enseñar a su grupo
los principios de mejoramiento continuo. Enfocado al cumplimiento de las
expectativas de los involucrados.
El cambio de este tipo en la gestión de proyectos por parte de los jefes se
reflejará en un personal más motivado, con mayor cultura, con mayor capacidad
de planear su trabajo, lo cual asegura la calidad de sus procesos y el tomar las
decisiones correctivas pertinentes. Sin embargo, como base para lograr estos
aspectos deben pasar de jefes a líderes. Es por esto, que un director de
proyectos debe ser capaz de identificar y promover a quienes tengan una
personalidad cultural triunfadora y destacarlos como líderes de proyectos por su
esencial capacidad individual y de trabajo en equipo.
Los gerentes de proyectos de TI y la organización como tal, debe ser capaz
de distinguir a los mejores candidatos para llenar las posiciones que requieran de
desarrollo o para suplir pérdidas o deserciones del personal, que cambia de tareas
o trabajo sobre la marcha de un proyecto.
45
Deben identificarse claramente las etapas de identificación de facultades,
productividad y reemplazo de los funcionarios que trabajan en proyectos, para lo
cual debe contar siempre con personal calificado, capacitado e identificado con las
tareas relacionadas. Los gerentes y líderes deben lograr que los nuevos
funcionarios acoplen como suyas, la misión y la visión de la empresa y si fuese
necesario las correspondientes a cada proyecto, así como hacer que los que
tienen más tiempo y experiencia no pierdan el interés en su trabajo. Utilizar
capacitación constante y las técnicas que estén a mano para lograr mantener el
personal productivo con un rendimiento máximo, durante el mayor tiempo posible.
Es importante también que aprendan a identificar cuándo un funcionario está en
su etapa de saturación y ha cumplido un ciclo en un puesto específico, para que,
antes de que sea una estadística más de rotación de personal, deje sus
conocimientos y experiencia plasmados en su reemplazo, por medio de
capacitación y seguimiento adecuado.
Debe mejorarse el trabajo en equipo dentro de los miembros de un equipo,
esto puede verse como algo mecánico, no es cuestión de poner a un grupo de
trabajo una tarea para que los resultados sean mejores en tiempo, esfuerzo,
recursos y calidad que los que obtuviese un solo funcionario realizando la totalidad
de la tarea. Los líderes deben lograr cautivar el respeto mutuo, la confianza entre
los miembros y el deseo de trabajar en conjunto para obtener los mejores
resultados. Característica identificada como deficiencia, que todos los líderes de
proyectos y gerentes de las entidades financieras deben mejorar. Deben buscar y
lograr identificar un equipo que cuente con la madurez necesaria y con un gran
equilibrio y respeto hacia los demás y hacia sí mismo como profesionales.
Se debe trabajar la capacidad de liderazgo en los gerentes de proyectos,
tanto en TI como en todo el BN, buscando que sean personas de mentalidad
abierta y dispuestas a mejorar y adaptarse al cambio para el mejoramiento de su
gestión, es imperioso indicar que estos –los líderes- deben ser personas con
habilidades y complementos, que les faculte y habilite para ser verdaderos líderes
capaces de valorar la capacidad de cada uno de los miembros del equipo a su
46
cargo; sin miedo a enfrentar problemas; con capacidad de plantarlos sin diluir su
autoridad ni el brillo de la excelencia individual; característica propia de los
equipos triunfadores.
Debe mejorarse el manual y la política de administración y gestión de
proyectos no sólo porque “ordena la cancha” al señalar las pautas por seguir para
cada etapa del desarrollo de un proyecto sino porque establece clara y
concisamente los lineamientos para el adecuado levantado de requerimientos por
considerar en el desarrollo de un proyecto, con una delimitación clara y
transparente de limitaciones, alcances, involucrados, procesos de mantenimiento
post implementación como gestión de problemas e incidentes, gestión de niveles
de servicio y vida útil del proyecto. De hecho, según puede analizarse de las
conversaciones con los expertos y la experiencia propia, uno de los problemas
más comunes es que se ha vuelto muy común, y es visto como normal, que un
proyecto sea modificado en su marcha, y sea necesario redefinir presupuesto, el
tiempo de ejecución, los objetivos e incluso el personal que trabaja en su
desarrollo. Esto obviamente afectará el tiempo de finalización y atrasará
considerablemente la puesta en marcha del mismo. Al final genera gastos no
contemplados, una mala imagen para los responsables e incluso productos
defectuosos, si se considera que el resultado no es el gestado y aprobado en sus
primeras etapas.
Entonces, con el fin de mejorar la administración de expectativas de los
stakeholders y la gestión de alcances en proyectos de la DCTIC del BN deberían
trabajarse los siguientes puntos:
Deben presentarse mejoras considerables en la metodología y en los
canales de comunicación, formalizar y establecer mejoras constates para
fortalecer la confianza de los mismos. Las plantillas utilizadas en la
definición del plan del proyecto incorporando temas de priorización y
asignación de recursos basados en el valor agregado que se vaya a lograr
y en estudios formal de costo beneficio.
47
Debe definirse una metodología clara y simple, fácil de seguir y respetar, la
cual debe ser conocida y aplicada por todos los miembros de los equipos
de trabajo institucionales.
Deben definirse procedimientos cortos, de simple y rápida referencia para
cada una de las tareas relacionadas con el desarrollo de un proyecto.
Iniciando con su gestación, pasando por su desarrollo, su puesta en
producción y el correspondiente mantenimiento del producto finalizado y en
producción. No se debe olvidar la documentación que genere, la
importantísima y olvidada retroalimentación para mejorar los
procedimientos existentes.
Estos procedimientos deben estar considerados como parte necesaria por
cumplir y respetar. Bajo ninguna circunstancia deben obviarse.
El personal relacionado con la gestión de proyectos debe estar capacitado,
motivado, identificado y comprometido con los objetivos del proyecto. Se
deben tomar como propias la misión y la visión por seguir. Debe lograrse
un nivel de producción tal en los funcionarios que se pueda “sacar la faena”.
Se deben enfrentar los obstáculos que sean necesarios; tomar decisiones
con proactivas y con un nivel de calidad tan alto como sea posible.
Las prioridades a los proyectos que deben ser atendidos será
responsabilidad única y exclusiva de los gerentes de la institución. Serán
estos los responsables de la asignación de recursos a una tarea o a otra.
Los gerentes deben tener muy claro la capacidad de su personal, evitar
sobrecargas de trabajo que generen productos con calidad menor a la
esperada o extender la duración o el presupuesto de un proyecto más de lo
necesario. Para esto es necesario contar con indicadores y seguimientos
muy bien detallados y fácilmente identificables.
Todo proyecto debe tener muy claramente definido, desde su primera
etapa, los alcances, la vida útil, el estudio de riesgos, la gestión de
involucrados, el tiempo de duración, el debido estudio de factibilidad y
demás aspectos necesarios que puedan servir como herramienta para el
adecuado levantamiento de requerimientos. Este proceso debe ser
48
realizado por profesionales con experiencia y capacidad comprobada; en
donde cualquier modificación que necesite hacerse no signifique
modificaciones sustanciales en el desenlace del proyecto.
49
7 BIBLIOGRAFIA
Project Managment Institute (2008). Guía de los Fundamentos para la Dirección
de Proyectos (Guía del PMBOK®), 4ª Edición. Newtown Square, Pennsylvania:
PMI.
Hernández, Fernández, Baptista Metodología de la Investigación; México.
McGraw Hill, 2002.
http://es.wikipedia.org/wiki/Fuente_secundaria, 11-marzo-2011)
www.bncr.fi.cr, pagina web del Banco Nacional, 10-marzo-2011
Adam, Everett Administración de la Producción y las Operaciones; México.
Prentice Hall 1991.
Dirección de COBIT y IT Gopbernance Institute; COBIT 4.1, Pautas de Gestión.
Buenos Aires, Argentina. Julio 2007.
Dirección de Proyectos, Banco Nacional de Costa Rica. Estándares para la
Administración de Proyectos. Marzo, 2001.
Microsoft Solutions Frameword (MSF), http://microsoft.com
Zairi, Mohamed Administración de la Calidad Total para Ingenieros; México.
Editorial Panorama 1986.
50
8 ANEXOS
8.1 Anexo 1: ACTA DEL PROYECTO.
Fecha: Nombre del proyecto:
15 de febrero de 2011 Administración de expectativas de los stakeholders y la gestión de alcances en proyectos de la DCTIC en BN.
Áreas del conocimiento: Área de aplicación
Gestión de la integración del proyecto.
Gestión de alcance del proyecto.
Gestión de la calidad del proyecto.
Gestión de comunicaciones del proyecto.
Gestión de riesgos del proyecto.
Gestión de los recursos humanos del proyecto.
DCTIC
Fecha de inicio del proyecto Fecha de finalización del proyecto
15 de febrero de 2011 8 de julio de 2011
Objetivos del proyecto
Objetivo General
Proponer mejoras en el proceso de gestión de expectativas y su relación con el alcance de un proyecto en la Dirección Corporativa de Tecnología de la Información y Comunicaciones del BNCR.
Objetivos específicos
Realizar un análisis de la situación actual para determinar las áreas de atención prioritaria.
Realizar propuestas de priorización para la atención de limitaciones y enfocar esfuerzos en las zonas que mayor valor agregado.
Proponer estrategias de implementación de las mejoras sugeridas para guiar el proceso de forma ordenada y de acuerdo a la cultura de la organización.
Justificación del proyecto
Actualmente los proyectos de la DCTIC difieren en cuanto al alcance definido durante su gestación y el alcance con que se termina el proyecto, esto porque las expectativas de los proyectos cambian radicalmente durante el proceso del mismo, en algunos casos, incluso, se ha hecho necesario replantear dichos alcances para cumplir con expectativas de los stakeholders. Esto genera modificaciones importantes en el alcance, tiempo y costo de los mismos, y obviamente en el cumplimiento de los cronogramas y niveles de eficiencia de los mismos.
Descripción del producto
La idea es presentar propuestas puntuales para mejorar la forma como se maneja la relación entre las expectativas de un proyecto y su relación directa con la gestión de alcances del mismo.
51
Entregables
Informe de situación actual
Diagnóstico de áreas criticas
Propuesta de priorización de áreas.
Propuesta de mejoras al esquema de comunicación.
Supuestos
El más importante supuesto es que se contará con la venia de los directores y altos niveles jerárquicos de la institución y aceptarán las propuestas como medidas de mejora y aumento en el nivel de madurez institucional en el tema de la administración profesional de proyectos. La implementación del esquema y las propuestas que resulten del presente trabajo no están contempladas en el mismo. No se define ni se considera presupuesto alguno para el presente trabajo. Como referencia documental se utilizarán cuatro proyectos en los que el autor de este trabajo ha participado para tomarlos como referencia y se obviarán los nombres como medida de protección de información de la empresa.
Factores críticos de éxito
Contar con el apoyo por parte de los altos niveles jerárquicos de la dirección.
Aceptación de medidas propuestas por parte de todos los niveles involucrados.
Capacitación constante para los involucrados en el proceso.
Aceptación positiva al proceso de cambio en el diario enfrentamiento a los proyectos de la DCTIC
Stakeholders
Director de la DCTIC
Directores de la DCTIC
Directores de proyectos de la DCTIC
Funcionarios de la DCTIC involucrados en proyectos.
Elaborado por Firma
Ronny F. Zúñiga Pineda
Aprobado por Firma
Manuel Álvarez
52
8.2 Anexo 2: EDT.
En un primer nivel se detallan las tareas a nivel macro que permiten visualizar los
macro procesos por enfrentar.
Figura #2. WBS, nivel 1.
Fuente propia.
A partir de este momento se detalla cada uno de los procesos en sus sub-tareas
para facilitar su análisis, cumplimiento, seguimiento y control.
La primera fase, está ligada directamente al seminario de graduación, a saber las
tareas que la conforman son:
53
Figura #3. WBS, seminario de graduación.
Fuente propia.
La segunda parte es la que se relaciona con la tutoría de la tesina como tal, fase
que está desglosada de la siguiente forma:
54
Figura #4. WBS, tutoría.
Fuente propia.
La tercera parte consiste en la lectura y retroalimentación de los lectores, de la
siguiente forma:
Figura #5. WBS, lectores.
Fuente propia.
55
Una vez que se tienen las observaciones de los lectores deben hacerse los
ajustes del caso:
Figura #6. WBS, tutoría de ajuste.
Fuente propia.
Finalmente, con un trabajo detallado acorde con las expectativas se pasa a la fase
final de defensa:
Figura #7. WBS, defensa.
Fuente propia.
56
8.3 Anexo 3: CRONOGRAMA.
Figura #8, cronograma.
Fuente propia.
57
8.4 Anexo #4: Propuesta de procedimientos.
El BN ya cuenta con un formato establecido para procedimientos así que los
mismos se adaptaron a dicho formato para facilitar su aceptación.
8.4.1 Procedimiento para la gestión de problemas.
CRITERIOS
PROCESOS RELACIONADOS
ACTIVIDADES
SE
CU
EN
CIA
GE
ST
IÓN
DE
CA
PIT
AL
ES
CA
DE
NA
DE
VA
LO
R
EV
AL
UA
CIÓ
N Y
ME
JO
RA
RESPONSABILIDAD Y AUTORIDAD
GO
BE
RN
AB
ILID
AD
Proceso: Gestión de Tecnología de Información y Comunicaciones
Nombre: Procedimientos para la Gestión de Problemas de TI
Código:
PRXXXTI01
Elaborado por:
DISTIFecha Aprobación: Fecha que Rige: Página:
1 de 5
Edición:
01
Aprobado por:
DCTIC
Alcance Este procedimiento es para uso exclusivo de la Dirección
Corporativa de Tecnologías y Comunicaciones del BNCR.
ISO 9001: 5.1,7.1,7.3.1
ISO 14000: 4.2,4.4.1,4.4.6
OHSAS 18000: 4.2,4.4.1,4.4.6
Propósito
Establecer los lineamientos a seguir para la gestión de problemas de TI,
presentados en cualquiera de las unidades organizativas del Banco
Nacional o en sus sistemas informáticos
Alcance del Sistema:$
Recepción de potencial
Problema en la DCTIC1
Se recibe con insumo base
para la atención de problemas
los registros de la Gestión de
Incidentes, uno con la
detección y detalle del mismo
u otro con la forma como se
solventó la situación,
respectivamente.
Busca registrar, rastrear y
resolver problemas operativos
investigando la causa raíz de
los problemas relevantes y
definiendo soluciones a los
problemas identificados.
Dir
ec
tor
Ge
sti
ón
Es
tra
tég
ica
y
Pro
ye
cto
s d
e T
I
Dir
ec
tor
Se
rvic
ios
de
TI e
n
Pro
du
cc
ión
Dir
ec
tor
Ap
oy
o
Ins
titu
cio
na
l a
Us
ua
rio
s
Dir
ec
tor
Ing
en
ierí
a d
e
Se
rvic
ios
de
TI
Simbologia:Control de Formatos: FD06-PR01SC01 / Edición 4
MétodoImpresión
INICIO /
FINProceso Registro
Software
$
La versión impresa de este documento constituye una COPIA NO CONTROLADA
DecisiónConector
Resultado de análisis
de gestión de incidentes
Pro
ve
ed
or
Recibir incidente. 1.1
El incidente debe llegar a la
gestión de Problemas con al
menos los dos registros base, el
que se creó al momento de su
detección y el de corrección del
mismo .
El caso debe analizarse en
equipo, conformado por un
representante de la DISTI y otro
de la DSTIP, considerando que
la DISTI será el dueño de
problemas relacionados con
Aplicaciones y la DSTIP con
problemas de Infraestructura.
XXX
xxxx
Proceso ProcesoAnalizar el candidato a problema
(problema en potencia)1.2
El análisis de la atención del
problema se realiza en equipo
entre las dos áreas funcionales
mas afectadas, a saber la
DSTIP y la DISTI y tomando
como base los SLA’s
establecidos en el proceso de
Gestión de Niveles de Servicio
Dado que no todos los
incidentes serán problemas es
aquí donde se analizará y
basado en el criterio experto del
equipo de trabajo se define
cuales pasan al siguiente ítem.
El caso debe analizarse en
equipo, conformado por un
representante de la DISTI y otro
de la DSTIP, considerando que
la DISTI será el dueño de
problemas relacionados con
Aplicaciones y la DSTIP con
problemas de Infraestructura.
Dir
ec
tor
Se
gu
rid
ad
y
Cu
mp
lim
ien
to
GE
ST
IÓN
DE
CA
LID
AD
XXX
Solución del
incidente
xxx
1.3
58
Código:
PRxxxTI01
Página:
2 de 5
Edición:
01
CRITERIOS
PROCESOS RELACIONADOS
ACTIVIDADES
SE
CU
EN
CIA
GE
ST
IÓN
DE
CA
PIT
AL
ES
CA
DE
NA
DE
VA
LO
R
EV
AL
UA
CIÓ
N Y
ME
JO
RA
RESPONSABILIDAD Y AUTORIDAD
GO
BE
RN
AB
ILID
AD
GE
ST
IÓN
DE
CA
LID
AD
NA
Dir
ec
tor
Se
rvic
ios
de
TI e
n
Pro
du
cc
ión
Dir
ec
tor
Ap
oy
o
Ins
titu
cio
na
l a
Us
ua
rio
s
Dir
ec
tor
Ing
en
ierí
a d
e
Se
rvic
ios
de
TI
Dir
ec
tor
Arq
uit
ec
tura
de
Se
rvic
ios
de
TI
Pro
ve
ed
or
NANA NA
La versión impresa de este documento constituye una COPIA NO CONTROLADA
1.2
Atención y seguimiento al
problema.2
En este apartado se busca
documentar y detectar la
causa del problema.
Categorizar y priorizar el
problema1.5
Se considerará como base el
impacto del problema y las
condiciones de los SLA’s
comprometidos, así como la
disponibilidad de recursos para
su atención. A partir de estos
datos se define, utilizando el
criterio experto para definir el
impacto, la urgencia y la
prioridad del problema.
El caso debe analizarse en
equipo, conformado por un
representante de la DISTI y otro
de la DSTIP, considerando que
la DISTI será el dueño de
problemas relacionados con
Aplicaciones y la DSTIP con
problemas de Infraestructura.
Una vez analizado el caso se
incluirá en el Rational y/o la
Bitácora Electrónica, según sea
el caso (Rational para
problemas de aplicaciones y
Bitácora Electrónica para
infraestructura.
Proceso Proceso
Asignar problema1.6
El equipo de trabajo asigna a
uno o varios ingenieros para la
atención, investigación y
documentación del problema.
siguiente ítem.
El caso debe analizarse en
equipo, conformado por un
representante de la DISTI y otro
de la DSTIP, considerando que
la DISTI será el dueño de
problemas relacionados con
Aplicaciones y la DSTIP con
problemas de Infraestructura.
Proceso Proceso
PR380TI0
1Niveles de Servicio
Generar registro de incidentes
que no califican como
problema.
1.4
Se creará un registro sobre los
incidentes que no califican para
el flujo de problemas y se
enviará a los involucrados.
Detallando el porque no se
considera problema.
xxx 2.9
¿Califica como problema?1.3
No todos los incidentes serán
tratados como problemas, solo
los que a criterio del equipo
evaluador merezcan ser
tratados como tales.
La decisión debe tomarse en
equipo, conformado por un
representante de la DISTI y otro
de la DSTIP, considerando que
la DISTI será el dueño de
problemas relacionados con
Aplicaciones y la DSTIP con
problemas de Infraestructura.
Decisión Decisión
NO
SI
2.1
59
Código:
PRxxxTI01
Página:
3 de 5
Edición:
01
CRITERIOS
PROCESOS RELACIONADOS
ACTIVIDADES
SE
CU
EN
CIA
GE
ST
IÓN
DE
CA
PIT
AL
ES
CA
DE
NA
DE
VA
LO
R
EV
AL
UA
CIÓ
N Y
ME
JO
RA
RESPONSABILIDAD Y AUTORIDAD
GO
BE
RN
AB
ILID
AD
GE
ST
IÓN
DE
CA
LID
AD
NA
Dir
ec
tor
Se
rvic
ios
de
TI e
n
Pro
du
cc
ión
Dir
ec
tor
Ap
oy
o
Ins
titu
cio
na
l a
Us
ua
rio
s
Dir
ec
tor
Ing
en
ierí
a d
e
Se
rvic
ios
de
TI
Dir
ec
tor
Arq
uit
ec
tura
de
Se
rvic
ios
de
TI
Pro
ve
ed
or
NANA NA
La versión impresa de este documento constituye una COPIA NO CONTROLADA
1.6
Analizar documentación
necesaria para plantear
requerimiento.
2.4
De ser necesario, este análisis
se hace en conjunto con el
representante de la instancia
consultada, sin embargo el
responsable de plantear el
requerimiento será el
representante de la DISTI como
dueño del proceso.
xxx
Actualización de información
sobre el problema en el flujo de
requerimientos para su
construcción.
2.5
Se actualiza la informacion al
Rational como requerimiento,
dejando claro el valor de
prioridad -según criterio
experto- y adjuntando toda la
documentación del análisis que
facilite su interpretación y
construcción. Rational
Solicitar apoyo de siguiente
nivel de soporte.2.3
Se solicitará el apoyo respectivo
para lo cual la(s) oficina(s)
consultada debe brindar el
apoyo solicitado de manera
expedita y prioritaria.
SI
Proceso
¿Se requiere de apoyo de otra
dirección o proveedor para
documentar y analizar el
problema?
2.2
Dado que un problema puede
presentarse por múltiples
circunstancias y tener relación
con varias oficinas, se debe
valorar la opción de solicitar
apoyo a otras direcciones y de
ser necesario crear un equipo
multifuncional para su atención.
La decisión debe tomarse en
equipo, conformado por un
representante de la DISTI y otro
de la DSTIP, considerando que
la DISTI será el dueño de
problemas relacionados con
Aplicaciones y la DSTIP con
problemas de Infraestructura.
Decisión Decisión
NO
NO
Coordinar con Gestión de
Cambios la puesta en
producción del producto.
2.6
Una ves finalizado el flujo
normal de atención de
requerimientos se debe
formalizar con Gestión de
Cambios la aplicación del
mismo.
Proceso
2.8
Software
Analizar y/o investigar el
problema.2.1
El (los) ingeniero(s)
designado(s) analizará la
situación y documentación
adjunta para tener un panorama
real del escenario.
El caso debe analizarse en
equipo, conformado por un
representante de la DISTI y otro
de la DSTIP, considerando que
la DISTI será el dueño de
problemas relacionados con
Aplicaciones y la DSTIP con
problemas de Infraestructura.
Toda la documentación y
análisis del caso debe quedar
registrado detalladamente en el
Rational y en la Bitácora
Electrónica.
Proceso Proceso
2.7
60
Código:
PRxxxTI01
Página:
4 de 5
Edición:
01
CRITERIOS
PROCESOS RELACIONADOS
ACTIVIDADES
SE
CU
EN
CIA
GE
ST
IÓN
DE
CA
PIT
AL
ES
CA
DE
NA
DE
VA
LO
R
EV
AL
UA
CIÓ
N Y
ME
JO
RA
RESPONSABILIDAD Y AUTORIDAD
GO
BE
RN
AB
ILID
AD
GE
ST
IÓN
DE
CA
LID
AD
NA
Dir
ec
tor
Se
rvic
ios
de
TI e
n
Pro
du
cc
ión
Dir
ec
tor
Ap
oy
o
Ins
titu
cio
na
l a
Us
ua
rio
s
Dir
ec
tor
Ing
en
ierí
a d
e
Se
rvic
ios
de
TI
Dir
ec
tor
Arq
uit
ec
tura
de
Se
rvic
ios
de
TI
Pro
ve
ed
or
NANA NA
La versión impresa de este documento constituye una COPIA NO CONTROLADA
xxx
1.4
El Problema se pudo corregir?2.8
Una vez concluido el proceso
de atención de la solución del
problema y atendido el flujo de
atención de un requerimiento,
se debe dar seguimiento al
problema hasta certificar su
corrección y garantizar que se
solventara la causa/raíz del
mismo.
El monitoreo lo realizará cada
dirección según su pertinencia,
de manera que si es problema
relacionado con la
infraestructura la
responsabilidad recae en la
DSTIP, y si es un problema
aplicativo, la responsabilidad
será de la DISTI.
Decisión
SI
NODecisión
Generar informe de oportunidad
de mejora y retroalimentación a
los involucrados.
2.9
Como cierre del proceso, se
generará un informe con el
detalle del proceso y atención
del problema para
retroalimentar a los
involucrados y generar
realimentación a futuro.
El informe lo realizará cada
dirección según su pertinencia,
de manera que si es problema
relacionado con la
infraestructura la
responsabilidad recae en la
DSTIP, y si es un problema
aplicativo, la responsabilidad
será de la DISTI.
Debe quedar claramente
detallada la causa raíz del
problema y todo el actual para
su atención, lo que se enviará
vía correo electrónico a las
jefaturas involucradas para que
tomen las medidas correctivas
correspondientes.
2.4
xxxx
Monitorear el comportamiento
problema -corregido- en los
ambientes de producción.
2.7
Se dará seguimiento al
problema hasta certificar que el
mismo no se presentará
nuevamente, tomando la
periodicidad que el criterio
experto defina.
El monitoreo lo realizará cada
dirección según su pertinencia,
de manera que si es problema
relacionado con la
infraestructura la
responsabilidad recae en la
DSTIP, y si es un problema
aplicativo, la responsabilidad
será de la DISTI.
ProcesoProceso
2.6
61
8.4.2 Procedimiento para la gestión de incidentes.
CRITERIOS
PROCESOS RELACIONADOS
ACTIVIDADES
SE
CU
EN
CIA
GE
ST
IÓN
DE
CA
PIT
AL
ES
CA
DE
NA
DE
VA
LO
R
EV
AL
UA
CIÓ
N Y
ME
JO
RA
RESPONSABILIDAD Y AUTORIDAD
GO
BE
RN
AB
ILID
AD
GE
ST
IÓN
DE
CA
LID
AD
Proceso: Gestión de Tecnología de InformaciónNombre: Procedimientos para la Gestión de Incidentes
de TI
Código:
PRxxxTI01
Elaborado por:
Asistente de la DCTICFecha Aprobación: Fecha que Rige: Página:
1 de 7
Edición:
01
Aprobado por:
Dirección Corporativa
de TI
Alcance
Este procedimiento es para uso exclusivo de la
DCTIC
ISO 9001: 8.2.3
ISO 14001: 4.5.1, 4.5.2
OHSAS 18001: 4.5.1, 4.5.2
Propósito
Establecer los lineamientos para la gestión de incidentes de TI,
bajo los servicios administrados por la DCTIC
Alcance del Sistema:$
Detección de Incidentes1
En
te E
xte
rno
Dir
ec
tor
de
Se
rvic
ios
en
Pro
du
cc
ión
Dir
ec
tor
de
Ap
oy
o
Ins
titu
cio
na
l a
Us
ua
rio
s
Dir
ec
tor
de
Ing
en
ierí
a
PROCESO PROCESO PROCESO PROCESOPROCESO
Recepción de incidente1.2
Elaborar registro del incidente1.4Elaborar Registro del Reporte del
Incidente
Proceso
xxx
Categorizar el incidente1.5
Se recurre a la ¨Categorización
de Incidentes¨ e incorpora el
impacto del incidente
Proceso
Incidente gestionado
Dir
ec
tor
Se
gu
rid
ad
y
Cu
mp
lim
ien
to
¿El incidente debe ser atendido
por ingeniería?1.7
Cuando la DAIU realiza el
diagnóstico del incidente, puede
detectar que lo atienda ingeniería
Decisión 4.1SI
3.2
¿El incidente debe ser atendido
por producción?1.6
Cuando la DAIU realiza el
diagnóstico del incidente, puede
detectar que lo atienda
producción
Decisión
NO
3.1SI
¿El incidente debe ser atendido
por seguridad y cumplimiento?1.8
Cuando la DAIU realiza el
diagnóstico del incidente, puede
detectar que lo atienda seguridad
y cumplimiento
Decisión 5.1SI
NO
Simbologia:
Control de Formatos: FD06-PR01SC01 / Edición 4
MétodoImpresión
INICIO /
FINProceso
Registro
Software
$
La versión impresa de este documento constituye una COPIA NO CONTROLADA
DecisiónConector
¿Es un incidente?1.3
Es un incidente si está afectando
el servicio (SLA explícito o
implícito), y que afecta de
manera significativa al negocio
en caso contrario se rechazaDecisión
SI
No
Rechazo de incidente
2.1NO
¿El incidente fue gestionado por
la DAIU?1.1
Un incidente puede generarse
a partir de eventos que
gestiona la DSTIP o la DAIU
Decisión
SI
No / Incidente
gestionado
por DSTIP
En caso contrario el incidente fue
gestionado por la DSTIP
COBIT /
ITIL
62
Código:
PRxxxTI01
Página:
2 de 7
Edición:
01
CRITERIOS
PROCESOS RELACIONADOS
ACTIVIDADES
SE
CU
EN
CIA
GE
ST
IÓN
DE
CA
PIT
AL
ES
CA
DE
NA
DE
VA
LO
R
EV
AL
UA
CIÓ
N Y
ME
JO
RA
RESPONSABILIDAD Y AUTORIDAD
GO
BE
RN
AB
ILID
AD
GE
ST
IÓN
DE
CA
LID
AD
NA
NA
Dir
ec
tor
de
Ap
oy
o
Ins
titu
cio
na
l a
Us
ua
rio
s
NA
NA
La versión impresa de este documento constituye una COPIA NO CONTROLADA
Analizar incidente2.1
Debe verificarse si hubo un
cambio reciente en el sistema
de la plataforma tecnológica,
con la finalidad de descartar
que la causa del incidente este
relacionado con dicha
modificación.
Proceso
Atención de Incidentes en
Apoyo Institucional a
Usuarios
2 1.8
NO¿El incidente se pudo corregir?2.2
Se brinda la atención técnica de
soporte a usuarios, si no se
puede corregir el incidente se
escalaría a otras instancias o
dirección asignada
Decisión
SI
Incorporar detalles del incidente2.4
Se envía el Registro a la Gestión
de Cambios con todas las
especificaciones generadas en el
análisis de la DAIU por medio de
correo electrónico
xxx
¿Amerita gestión de cambios?2.3
En caso de que el incidente se
resolvió en la DAIU y se requiera
modificar algún elemento de la
plataforma tecnológica
Decisión
SI
NO
Cerrar incidente2.8
En el sistema RATIONAL con los
detalles de la solución del
incidente
Proceso
Analizar oportunidad de mejora2.6
Para prevenir reiteración de
incidente para análisis de
racionalidad y costo
Elaborar registro de
oportunidades de mejora2.7
Se detalla referencia del
incidente y se adjunta la
información del análisis de
mejora para el proceso de
gestión de problemas por medio
de correo electrónico
Proceso
xxx
¿Se debe de contemplar
oportunidades de mejora?2.5
Las oportunidades de mejora se
contemplan si se quiere
determinar su causa raíz para
impedir su reiteración
Decisión
SI
NO
Análisis
2.11 2.9
NO
63
Código:
PRxxxTI01
Página:
3 de 7
Edición:
01
CRITERIOS
PROCESOS RELACIONADOS
ACTIVIDADES
SE
CU
EN
CIA
GE
ST
IÓN
DE
CA
PIT
AL
ES
CA
DE
NA
DE
VA
LO
R
EV
AL
UA
CIÓ
N Y
ME
JO
RA
RESPONSABILIDAD Y AUTORIDAD
GO
BE
RN
AB
ILID
AD
GE
ST
IÓN
DE
CA
LID
AD
NA
Dir
ec
tor
de
Se
rvic
ios
en
Pro
du
cc
ión
Dir
ec
tor
de
Ap
oy
o
Ins
titu
cio
na
l a
Us
ua
rio
s
NA
En
te E
xte
rno
NANA NA
Recibir Incidente 3.1
Atención de Incidente en
Servicios de Producción3 Si el incidente no pudo ser
corregido en la primera etapa
por parte de la DAIU pasará a
ser atendido por la DSTIP,
como soporte de segundo
nivel.
NA
La versión impresa de este documento constituye una COPIA NO CONTROLADA
1.6
SI
1.1
NO
Enviar registro2.12
Se documenta el estado actual y
acciones preventivas tomadas
para la atención del incidente.
Información base para el
siguiente nivel de atención
mediante correo electrónico
xxx
NO
¿Es necesario enviar el incidente
a otras instancias?2.9
Según el análisis realizado y la
característica del incidente se
determina si es necesario enviar
de una vez el incidente a otras
instancias
Decisión
SI
Enviar incidente2.10
2.2
2.2 NO
Proceso
Resultado de la atención
El análisis y la atención del
incidente se realiza considerando
en todo momento los sla’s
establecidas en los procesos de
Gestión de Niveles de servicio...
Atender el Incidente3.4
ProcesoAnalizar el informe3.3
Brinda el análisis según criterio
experto profesional y según los
sla’s correspondientes
Elaborar registro del incidente3.2Elaborar Registro del Reporte del
Incidentexxx
3.5
xxx
Recibir respuesta del incidente2.11
Proceso
Otras
instanci
as
Proceso
Respuesta
incidente
64
Código:
PRxxTI01
Página:
4 de 7
Edición:
01
CRITERIOS
PROCESOS RELACIONADOS
ACTIVIDADES
SE
CU
EN
CIA
GE
ST
IÓN
DE
CA
PIT
AL
ES
CA
DE
NA
DE
VA
LO
R
EV
AL
UA
CIÓ
N Y
ME
JO
RA
RESPONSABILIDAD Y AUTORIDAD
GO
BE
RN
AB
ILID
AD
GE
ST
IÓN
DE
CA
LID
AD
NA
Dir
ec
tor
de
Se
rvic
ios
en
Pro
du
cc
ión
Dir
ec
tor
de
Ing
en
ierí
a
En
te E
xte
rno
NANA NA3.4
La versión impresa de este documento constituye una COPIA NO CONTROLADA
Enviar Registro3.14RE02PR3
05TI01
Este registro se hace con las
especificaciones y características
del incidente con el fin de
documentar y brindar bases para
la atención del mismo en el
siguiente nivel de soporte.
Incorporar detalles del incidente3.6
Se envía el Registro a la Gestión
de Cambios con todas las
especificaciones generadas en el
análisis de la DSTIP por medio
de correo electrónico
xxx
NO
¿El incidente se pudo corregir?3.5
Se escala a otras instancias o a
la Dirección Asignada según
característica del incidente
Decisión
SI
Cerrar incidente 3.10
En el sistema RATIONAL con los
detalles de la solución del
incidente
Proceso
¿Es necesario enviar el incidente
a otras instancias?3.11
Según el análisis realizado y la
característica del incidente se
determina si es necesario enviar
de una vez el incidente a otras
instancias
Decisión
SI
3.5
NO
Analizar oportunidad de mejora3.8
Para prevenir reiteración de
incidente para análisis de
racionalidad y costo
Elaborar registro de
oportunidades de mejora3.9
Se detalla referencia del
incidente y se adjunta la
información del análisis de
mejora para el proceso de
gestión de problemas por medio
de correo electrónico
¿Se debe de contemplar
oportunidades de mejora?3.7
Las oportunidades de mejora se
contemplan si se quiere
determinar su causa raíz para
impedir su reiteración
Proceso
RE03PR3
05TI01
Decisión
SI
NO
Enviar incidente3.12 Proceso
3.13
4.1
Recibir respuesta del incidente3.13 Proceso
Respuesta Incidente
Resultado de la atención
Otras
instanci
as
65
Código:
PRxxxTI01
Página:
5 de 7
Edición:
01
CRITERIOS
PROCESOS RELACIONADOS
ACTIVIDADES
SE
CU
EN
CIA
GE
ST
IÓN
DE
CA
PIT
AL
ES
CA
DE
NA
DE
VA
LO
R
EV
AL
UA
CIÓ
N Y
ME
JO
RA
RESPONSABILIDAD Y AUTORIDAD
GO
BE
RN
AB
ILID
AD
GE
ST
IÓN
DE
CA
LID
AD
NA
Dir
ec
tor
de
Ing
en
ierí
a
Dir
ec
tor
Se
gu
rid
ad
y C
um
plim
ien
to
En
te E
xte
rno
NANA NA
La versión impresa de este documento constituye una COPIA NO CONTROLADA
Enviar Registro4.13
Este registro se hace con las
especificaciones y características
del incidente con el fin de
documentar y brindar bases para
la atención del mismo en el
siguiente nivel de soporte.
Cerrar incidente4.9
En el sistema RATIONAL con los
detalles de la solución del
incidente
Proceso
¿El Incidente se pudo corregir?4.4 Decisión
SI
NO
Se escala a otras instancias o a
la dirección asignada según
característica del incidente
Incorporar detalles del incidente4.5
Se envía el Registro a la Gestión
de Cambios con todas las
especificaciones generadas en el
análisis de la DISTI por medio de
correo electrónico
¿Es necesario enviar el incidente
a otras instancias?4.10
Según el análisis realizado y la
característica del incidente se
determina si es necesario enviar
de una vez el incidente a otras
instancias
Decisión
SI
4.4
NO
Analizar oportunidad de mejora4.7
Para prevenir reiteración de
incidente para análisis de
racionalidad y costo
Elaborar registro de
oportunidades de mejora4.8
Se detalla referencia del
incidente y se adjunta la
información del análisis de
mejora para el proceso de
gestión de problemas por medio
de correo electrónico
Proceso
xxx
¿Se debe de contemplar
oportunidades de mejora?4.6
Las oportunidades de mejora se
contemplan si se quiere
determinar su causa raíz para
impedir su reiteración
Decisión
NO
SI
3.14
Enviar incidente4.11 Proceso
4.12
5.1
Atención de Incidentes por
parte de Ingeniería4
Esta atención es dada por la
Dirección Ingeniería
Recibir Incidente4.1
Si en la fase de análisis inicial
por parte de la DAIU se detecta
que el incidente es a nivel
aplicativo puede direccionarse
directamente a la Dirección de
Ingeniería.
1.7 SI
Analizar el Incidente 4.2
Atender el Incidente4.3
Proceso
Proceso
Resultado de
la atención
xxx
xxx
xxx
xxx
xxx
xxx
Recibir respuesta del incidente4.12 Proceso
Otras
instan
cias
Respuesta
Incidente
El análisis y la atención del
incidente se realiza considerando
en todo momento las políticas y
lineamientos planteadas en el
proceso de Gestión de Niveles
de Servicio
66
Código:
PRxxxTI01
Página:
6 de 7
Edición:
01
CRITERIOS
PROCESOS RELACIONADOS
ACTIVIDADES
SE
CU
EN
CIA
GE
ST
IÓN
DE
CA
PIT
AL
ES
CA
DE
NA
DE
VA
LO
R
EV
AL
UA
CIÓ
N Y
ME
JO
RA
RESPONSABILIDAD Y AUTORIDAD
GO
BE
RN
AB
ILID
AD
GE
ST
IÓN
DE
CA
LID
AD
NA
Dir
ec
tor
de
Ing
en
ierí
a
Dir
ec
tor
Se
gu
rid
ad
y
Cu
mp
lim
ien
to
NANA NA4.13
La versión impresa de este documento constituye una COPIA NO CONTROLADA
Cerrar Incidente5.9
El incidente es cerrado en el
sistema RATIONAL, una vez que
este sea solucionado.
Proceso
¿El Incidente se pudo corregir?5.4
Se escala a otras instancias o a
la dirección asignada según
característica del incidente
Decisión
SI
NO
Incorporar detalles del incidente
Se envía el Registro a la Gestión
de Cambios con todas las
especificaciones generadas en el
análisis por medio de correo
electrónico
5.5
Analizar oportunidad de mejora5.7
Para prevenir reiteración de
incidente para análisis de
racionalidad y costo
Elaborar registro de
oportunidades de mejora5.8
Se detalla referencia del
incidente y se adjunta la
información del análisis de
mejora para el proceso de
gestión de problemas por medio
de correo electrónico
xxx
Proceso
¿Se debe de contemplar
oportunidades de mejora?5.6
Las oportunidades de mejora se
contemplan si se quiere
determinar su causa raíz para
impedir su reiteración
Decisión
SI
NO
Enviar incidente 5.10Según el análisis realizado y la
característica del incidente se
determina si es necesario enviar
de una vez el incidente a otras
instancias
Recibir respuesta de incidente5.11 Proceso
Analizar el incidente5.2
Atender el incidente5.3
Proceso
Proceso
Atención de Incidentes por
parte de Seguridad y
Cumplimiento
5
Se brinda la atención de cuarto
nivel que le corresponde a los
responsables de la Dirección
Seguridad y cumplimiento
Recibir Incidente5.1
El incidente presenta
características que no pueden
ser resueltas directamente por la
DAIU o por la DSTIP
El análisis y la atención del
incidente se realiza considerando
en todo momento las políticas y
lineamientos planteadas en por
el proceso de Gestión de Niveles
de Servicio
1.8 SI
Resultado de la atención
xxxx
xxx
Otras
instan
cias
Respuesta
Incidente
En
te E
xte
rno
xxx
xx
Proceso
5.4
5.11
67
8.4.3 Procedimiento para la gestión de cambios.
CRITERIOS
PROCESOS RELACIONADOS
ACTIVIDADES
SE
CU
EN
CIA
GE
ST
IÓN
DE
CA
PIT
AL
ES
CA
DE
NA
DE
VA
LO
R
EV
AL
UA
CIÓ
N Y
ME
JO
RA
RESPONSABILIDAD Y AUTORIDAD
GO
BE
RN
AB
ILID
AD
GE
ST
IÓN
DE
CA
LID
AD
Proceso: Gestión de Tecnología de InformaciónNombre: Procedimientos para la Gestión de Cambios de
TI
Código:
PRxxxTI01
Elaborado por:
Asistente de la DCTICFecha Aprobación: Fecha que Rige: Página:
1 de 4Edición:
01
Aprobado por:
Dirección Corporativa
de TI
Alcance
Este procedimiento es para uso exclusivo de la
DCTIC
ISO 9001: 8.2.3
ISO 14001: 4.5.1, 4.5.2
OHSAS 18001: 4.5.1, 4.5.2
Propósito
Establecer los lineamientos para la gestión de cambios de TI,
bajo los servicios administrados por la DCTIC
Alcance del Sistema:$
En
te e
xte
rno
NA
Dir
ec
tore
s
inv
olu
cra
do
s e
n
el c
am
bio
CA
B
NA
Simbologia:
Control de Formatos: FD06-PR01SC01 / Edición 4
MétodoImpresión
INICIO /
FINProceso
Registro
Software
$
La versión impresa de este documento constituye una COPIA NO CONTROLADA
DecisiónConector
Registrar la solicitud de cambio1.1
El seguimiento de todo el
proceso de cambio lo realiza
Análisis de Negocios y se
registra en el RATIONAL. Por
medio del sistema recibe las
características
correspondientes al cambio
para su respectivo análisis y
posterior construcción que
satisfaga las necesidades y
supere las pruebas
respectivas. Para este
procedimiento la promesa de
calidad se identifica en cada
uno de los procedimientos
referenciados
¿El cambio es factible?1.2
EL cambio no es factible en
casos que por consideración
técnica se determine que el
cambio no puede ser construido
de la manera que es solicitado.
Informar al usuario solicitante1.3
Informar vía correo al solicitante
del cambio para que haga los
ajustes pertinentes al RFC y
actualice el registro del
RATIONAL. En el caso de que el
cambio no fue autorizado indicar
las circunstancias de no
autorización o denegación
Atención y construcción
del cambio1
RATIONAL
Decisión
NO
SI
ProcesoProcesoProcesoProcesoProcesoCambio no factible
Solicitud
xxx
xxxx
RFC
Proceso
Planificar la construcción del
cambio1.4
Se define el cronograma de
trabajo con sus entregables,
actividades, responsables,
recursos, fechas entre otros
¿El cambio se autoriza?1.5 Decisión
Priorizar el cambio1.6
NO
Proceso
SI
1.3
1.5
NO
Se somete el plan de cambio a
consideración del órgano
colegiado para su autorización
formal y respectiva priorización.
Cuando el cambio proviene de la
gestión de incidentes debe darse
prioridad máxima al mismo.
Plan de
Trabajo
(Construción)
1.8
Construir el cambio1.7
Se coordina y ejecuta el plan de
cambio en su fase de
construcción según las
direcciones involucrada.
Proceso1.10
COBIT Proceso
AI6
ITIL Gestión
de Cambios
68
CRITERIOS
PROCESOS RELACIONADOS
ACTIVIDADES
SE
CU
EN
CIA
GE
ST
IÓN
DE
CA
PIT
AL
ES
CA
DE
NA
DE
VA
LO
R
EV
AL
UA
CIÓ
N Y
ME
JO
RA
RESPONSABILIDAD Y AUTORIDAD
GO
BE
RN
AB
ILID
AD
GE
ST
IÓN
DE
CA
LID
AD
NA
NA
Dir
ec
tore
s
inv
olu
cra
do
s e
n
el c
am
bio
NA
CA
B
Código:
PRxxxTI01
Página:
2 de 4
Edición:
01
Realizar pruebas1.8
Se ejecutan las pruebas en
“ambientes de pruebas” y
determinar con esto el posible
comportamiento del cambio en
las aplicaciones e infraestructura
actual.
¿El cambio supera las pruebas?1.9
Pruebas realizadas
Cambio
construido
Decisión
Gestionar la corrección de las
deficiencias1.10
En caso de que el cambio no
supere las pruebas se elabora
reporte de deficiencias
detectadas en las pruebas y se
remite a los responsables de la
construcción del cambio1.7
NO
SI
NA NA1.7
Proceso
Actualizar registros de estado del
cambio e informar a los
eventuales integrantes de su
implementación
1.11
Se actualiza el registro de
RATIONAL indicando que el
cambio está listo para su
despliegue en producción y que
se proceda a su implementaciónRATIONAL
Elaborar propuesta de
implementación2.1
En la implementación del
cambio se elabora una
propuesta de plan que debe de
llevar un cronograma, riesgos,
contingencia y valoración de
recursos
Conocer propuesta de
implementación, autorizarla y
priorizarla
2.2
Se valida la pertinencia del
cambio, proceder con su
autorización formal y la definición
y priorización de las condiciones
que regirán su implementación
Proceso
Planificar a detalle2.3
La propuesta del plan de
implementación se refina en
concurso con todos los
involucrados
Coordinar y ejecutar el plan de
implementación2.4
Se coordina con todos los
interesados la ejecución del plan
de implementación
Probar el cambio en el entorno
de producción2.5
Probar que el cambio satisfaga
los criterios de aceptación para
su puesta en producción(incluye
la ejecución del plan de
contingencia), en caso contrario
se rechaza ¿La prueba es exitosa?2.6 Decisión
Implementación del
cambio en producción2
Proceso
Proceso
Proceso
Reporte
Plan de
Trabajo
(Implementac
ión)
Simbologia:
Control de Formatos: FD06-PR01SC01 / Edición 4
MétodoImpresión
INICIO /
FINProceso
Registro
Software
$
La versión impresa de este documento constituye una COPIA NO CONTROLADA
DecisiónConector
NO
SI 2.7
69
CRITERIOS
PROCESOS RELACIONADOS
ACTIVIDADES
SE
CU
EN
CIA
GE
ST
IÓN
DE
CA
PIT
AL
ES
CA
DE
NA
DE
VA
LO
R
EV
AL
UA
CIÓ
N Y
ME
JO
RA
RESPONSABILIDAD Y AUTORIDAD
GO
BE
RN
AB
ILID
AD
GE
ST
IÓN
DE
CA
LID
AD
NA
Dir
ec
to
r A
ná
lis
is
de
l n
eg
oc
io
Dir
ec
to
re
s
inv
olu
cra
do
s e
n
el c
am
bio
CA
B
NA
Simbologia:
Control de Formatos: FD06-PR01SC01 / Edición 4
MétodoImpresión
INICIO /
FINProceso
Registro
Software
$
La versión impresa de este documento constituye una COPIA NO CONTROLADA
DecisiónConector
Código:
PRxxxTI01
Página:
3 de 4
Edición:
01
NA NA
Elaborar informe del cambio
específico2.7
Se informa del grado de éxito del
plan de implementación,
lecciones aprendidas y cierre
formal, incluye nota de
aceptación del usuario solicitante
del cambio y se envía al CAB
Información y estadístico
de la gestión de cambios3
Elaborar informe3.1
Se elabora mediante correo un
informe en el cual se
consideran todos los cambios
del periodo y se establecen las
métricas y análisis
correspondientes,
identificando las situaciones
de relevancia
Informe del
Periodo
Enviar el informe3.2
Envía mediante correo
electrónico para su conocimiento
y se archiva
Recibir informe3.3
Recibe el informe final por medio
de correo electrónico para su
archivo
Informe finalxxx
Informe
Cambio
Específico
Recibir informe2.8
Informe
Cambio
Específico
Informe cambio
específico
Informe del
Periodo
Informe del
Periodo
SI2.7
70
8.4.4 Procedimiento para la gestión de niveles de servicio.
CRITERIOS
PROCESOS RELACIONADOS
ACTIVIDADES
SE
CU
EN
CIA
GE
ST
IÓN
DE
CA
PIT
AL
ES
CA
DE
NA
DE
VA
LO
R
EV
AL
UA
CIÓ
N Y
ME
JO
RA
RESPONSABILIDAD Y AUTORIDAD
GO
BE
RN
AB
ILID
AD
GE
ST
IÓN
DE
CA
LID
AD
Proceso: Gestión de Tecnología de InformaciónNombre: Procedimientos para la Gestión de Niveles de
Servicio de TI
Código:
PRxxxTI01
Elaborado por:
DGEPTI
Fecha Aprobación: Fecha que Rige: Página:
1 de 3
Edición:
01
Aprobado por:
DCTIC
Alcance
Este procedimiento es para uso exclusivo de la
Dirección Corporativa de Tecnologías y
Comunicaciones del BNCR
ISO 9001: 5.1,7.1,7.3.1
ISO 14000: 4.2,4.4.1,4.4.6
OHSAS 18000: 4.2,4.4.1,4.4.6
Propósito
Establecer los lineamientos a seguir para la gestión de niveles
de servicio de TI.
Alcance del Sistema:$
Definición de Niveles de
Servicio1
Los niveles de servicio son
definidos para asegurar que
los objetivos del negocio se
están haciendo de manera
adecuada y acorde con los
compromisos y lineamientos
de calidad dictadas por el BN
y la DCTIC y pensados acorde
el plan estratégico de TI.
N/A
Dir
ec
tor
Arq
uit
ec
tura
de
Se
rvic
ios
xxx
Establecer los niveles de servicio
acorde con los lineamientos de
la DCTIC
2.2
Cada dirección definen los
estándares para la gestión
documental, operación y
disponibilidad de los sistemas
críticos.
Se definen los SLA´s, los OLA´s
y los CU´s, disponibilidad,
confiabilidad, continuidad y
seguridad.
El procedimiento estará a cargo
de la DGEPTI con el apoyo de
las demás direcciones.
PETID
ire
cto
r In
ge
nie
ría
de
Se
rvic
ios
de
TI
Dir
ec
tor
Se
rvic
ios
de
TI e
n P
rod
uc
ció
n
Dir
ec
tor
Ap
oy
o
Ins
titu
cio
na
l a
Us
ua
rio
s
Simbologia:Control de Formatos: FD06-PR01SC01 / Edición 4
Método ImpresiónINICIO /
FINProceso Registro
Software
$
La versión impresa de este documento constituye una COPIA NO CONTROLADA
DecisiónConector
Generar y consolidar un catalogo
de servicios.1.1
Deben priorizarse y definirse
claramente los servicios que
cada dirección oferta, de
acuerdo con la importancia que
dicho representa para el negocio
y el servicio de la DCTIC.
Estos deben contemplar y
definir claramente el alcance de
cada servicio.
El dueño del proceso debe
consolidar y actualizar
periódicamente (a criterio
experto) la información con los
insumos de todas las
direcciones tarea que
corresponde a la DGEPTI.
Proceso
Dir
ec
tor
Se
gu
rid
ad
y
Cu
mp
lim
ien
to
Dir
ec
tor
Ge
sti
ón
Es
tra
tég
ica
y
Pro
ye
cto
s d
e T
I
Dir
ec
tor
An
ális
is d
el
Ne
go
cio
xxx xxx xxxxxxxxxxxxxxx
ProcesoProceso
Definición de sistemas críticos
y prioritarios 2
Debe establecerse un modelo
de priorización de sistemas
para enfocar esfuerzos en los
que representan mayor aporte
al negocio y a la DCTIC.
Definir sistemas críticos 2.1
De acuerdo a la importancia
para el negocio se definen
cuales son los sistemas que
mayor valor agregado aportan y
por lo tanto requieren mayor
atención y seguimiento.
Proceso Proceso Proceso
ProcesoProceso
2.3
71
Código:
PRxxxTI01
Página:
2 de 3
Edición:
01
CRITERIOS
PROCESOS RELACIONADOS
ACTIVIDADES
SE
CU
EN
CIA
EV
AL
UA
CIÓ
N Y
ME
JO
RA
RESPONSABILIDAD Y AUTORIDAD
GE
ST
IÓN
DE
CA
LID
AD
GO
BE
RN
AB
ILID
AD
GE
ST
IÓN
DE
CA
PIT
AL
ES
CA
DE
NA
DE
VA
LO
R
N/A
Dir
ec
tor
Arq
uit
ec
tura
de
Se
rvic
ios
Dir
ec
tor
Ing
en
ierí
a
de
Se
rvic
ios
de
TI
Dir
ec
tor
Se
rvic
ios
de
TI e
n P
rod
uc
ció
n
Dir
ec
tor
Ap
oy
o
Ins
titu
cio
na
l a
Us
ua
rio
s
Dir
ec
tor
Se
gu
rid
ad
y
Cu
mp
lim
ien
to
Dir
ec
tor
Ge
sti
ón
Es
tra
tég
ica
y
Pro
ye
cto
s d
e T
I
Dir
ec
tor
An
ális
is d
el
Ne
go
cio
N/A N/A
Monitorear el cumplimiento de
los SLA´s y las OLA´s 3.1
Monitorear periódicamente el
cumplimiento de los SLA´s, CU´s
y las OLA´s
xx xxx
Seguimiento y mantenimiento
a los Niveles de Servicio 3
Define que medidas y
controles se seguirán para
mantener un modelo de
Gestión de Niveles de Servicio
actualizado y acorde con las
metas de la DCTIC.
2.2
La versión impresa de este documento constituye una COPIA NO CONTROLADA
Definir el plan de mejora de
servicios. 2.3
Se preparan informes de
gestión, valores meta y limites
de control. Así como las métricas
de cumplimiento y la gestión de
expectativas de los involucrados.
Este registro debe levantarse en
equipo considerando aportes
técnicos y estratégicos por parte
de las direcciones de la DCTIC
al del dueño del proceso,
DGEPTI, quien consolida los
mismos.
xxx xxxxxxxxx
Definición de plan de
contingencia 4
Se define un plan para los
sistemas críticos
Definiir plan de contingencia 4.1
Se establece un plan donde se
detalle la prioridad por atender
en caso de una eventualidad
(sistemas críticos y niveles de
servicio mínimos aceptados).
Plan que podría ser insumo para
el procedimiento de continuidad
de la infraestructura.
xxx xxxxxxxxx