ACTA DE RECEPCION Y APROBACION INFORME TECNICO
CONTRATO: “EVALUACIÓN GESTION DE TECNOLOGIAS DE
INFORMACION QUE REALIZA EL DEPARTAMENTO DE SISTEMAS
Y SERVICIOS DE INFORMACIÓN EN RED DE LA BIBLIOTECA DEL
CONGRESO NACIONAL”
FECHA: 29/07/2013
CONTRAPARTE: RENE LUCERO CHENEVARD
EN ESTA FECHA SE RECIBE CONFORME Y SE APRUEBA INFORME NUMERO 2 DEL CONTRATO SEÑALADO, QUE SE TITULA: “DIAGNÓSTICO DE PROCESOS TI”. SE ADJUNTA INFORME, COMENTARIOS DE CHRISTIAN SIFAQUI Y RESPUESTA DE EMPRESA AUDITORA.
-------------------------------------------- RENE LUCERO CHENEVARD
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 1 de 55
Junio 2013
Informe 2: Diagnóstico de los procesos TI
1. Resumen ejecutivo
El marco de referencia para realizar el diagnóstico y recomendaciones acerca del estado de madurez
de los procesos de gestión de los recursos TI de la BCN, es el estándar COBIT1.
COBIT señala que un buen Gobierno de TI tiene que asegurar:
Alineación Estratégica
Se enfoca en garantizar la alineación entre los planes de negocio y de TI; en definir,
mantener y validar la propuesta de valor de TI; y en alinear las operaciones de TI con las
operaciones de la empresa.
Entrega de Valor
Se refiere a ejecutar la propuesta de valor a todo lo largo del ciclo de entrega, asegurando
que las TI generen los beneficios prometidos en la estrategia, concentrándose en optimizar
los costos y en brindar el valor intrínseco de la TI.
Administración de Riesgos
Se requiere conciencia de los riesgos por parte de los altos ejecutivos de la empresa, un claro
entendimiento del apetito de riesgo que tiene la empresa, comprender los requerimientos de
cumplimiento, transparencia de los riesgos significativos para la empresa, y la inclusión de
las responsabilidades de administración de riesgos dentro de la organización.
Administración de Recursos
Se trata de la inversión óptima, así como la administración adecuada de los recursos críticos
de TI; aplicaciones, información, infraestructura y personas. Los temas claves se refieren a
la optimización de conocimiento y de infraestructura.
Medición del Desempeño
Rastrea y monitorea la estrategia de implementación, la terminación del proyecto, el uso de
los recursos, el desempeño de los procesos y la entrega del servicio, con el uso, por ejemplo,
de balanced scorecards que traducen la estrategia en acción para lograr las metas medibles
más allá del registro convencional.
1 COBIT: Control Objectives for Information and related Technology desarrollado por la
Information Systems Audit and Control Association (ISACA)
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 2 de 55
Junio 2013
Para que esto ocurra, COBIT propone la existencia y el control de un conjunto de procesos
destinados a:
a. planificar y organizar las actividades de TI,
b. adquirir e implementar aplicaciones e infraestructura,
c. operar la infraestructura, entregar los servicios aplicativos y brindar soporte, y
d. monitorear el cumplimiento de los niveles de servicio, los estándares de seguridad, el
desempeño de la TI dentro de la organización.
Las recomendaciones relacionadas con los principales procesos se describen en las tablas que
siguen. El detalle se encuentra en el informe.
En promedio, la madurez de los procesos de TI de la BCN se encuentra entre un nivel Inexistente e
Inicial (existe pero no hay un procedimiento formal asociado) y nuestra recomendación es
trasladarlos a un nivel cercano a Definidos (el proceso, los recursos, los roles y responsabilidades se
encuentran documentados y formalizado):
Nombre del
proceso
Estado
actual
Recomendación Priori
dad
PO1: Definición de
un plan estratégico
de TI
Indefinido Implementar este proceso al menos con un nivel de
madurez 2 (repetible), en lo posible 3 (definido o
gestionado). Este proceso debiera llevarse a cabo cada 3
o 4 años, y evaluarse/corregirse anualmente. Nuestra
sugerencia es que forme parte del proceso de
Planificación Estratégica de la BCN
1
PO2: definición de
la arquitectura de
la información
Inicial Implementar este proceso al menos con un nivel de
madurez repetible, en lo posible definido o gestionado.
Este proceso debiese tener un responsable que podría ser
el responsable del modelo corporativo de datos.
2
P04: definición de
procesos de TI,
organización y
Inicial Implementar al menos con un nivel de madurez 2
(repetible), deseable 3. Se deben identificar y
documentar los principales procesos y procedimientos
1
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 3 de 55
Junio 2013
relaciones de gestión de los recursos informáticos. En lo posible se
deben también medir.
P05: Gestión de la
inversión en
tecnología
Repetible Se deben mejorar los procesos de formulación y
ejecución presupuestaria. En particular, el presupuesto
debe reflejar el plan de trabajo del año siguiente. El plan
estratégico de TI puede ayudar a mejorar el vínculo
entre plan y presupuesto.
Es importante que Sistemas se entere oportunamente del
presupuesto disponible, y que tenga el control sobre la
ejecución (p.e., a través de un V°B°). También es
importante que rinda cuentas de la ejecución a los
Comités que debiesen crearse.
1
P07: Gestión de los
RRHH de TI
Inicial Es importante definir con precisión qué servicios se
externalizarán y cuáles quedarán dentro de la BCN. A
partir de esta definición, se debe determinar la dotación,
y describir los perfiles de cargos. Debe existir una
evaluación regular del desempeño del personal y un plan
de desarrollo que permita cerrar las brechas encontradas
en la evaluación. Es importante también hacer una
buena gestión del conocimiento, en particular de aquel
conocimiento considerado crítico para el
funcionamiento de la BCN, y respaldar ese
conocimiento experto
1
P09: Validación y
gestión del riesgo
de la TI
Inicial Pasar a estado Definido. Implementar un mapa de
riesgos de la BCN con sus respectivos planes de
mitigación. De manera análoga, hacerlo para los
procesos de TI (p.e., ¿qué pasa si se entrega el texto
actualizado de una ley, defectuoso? ¿qué consecuencias
tiene que se entregue una asesoría de mala calidad?, o
bien ¿qué ocurre si se entrega información errónea
acerca de la actividad de un parlamentario?). Esto se
tornará aún más crítico cuando la BCN tenga la
responsabilidad de entregar la versión oficial de los
códigos
1
P10: Gestión de
proyectos
Inicial Pasar a un estado de madurez 4 (administrado) o 5
(optimizado). Se requiere definir y socializar una
manera de gestionar proyectos en la BCN (un “BCN
way”) que incorpore las mejores prácticas en este
dominio. Probablemente una versión localizada del
estándar PMBOK (“Project Management Body of
Knowledge”) del Project Management Institute, o
Prince. También es importante capacitar a los Jefes de
Proyecto en torno a esta metodología
1
P11: definir
política de
seguridad
Repetible Transformar el proceso en “definido”. Asegurarse de
que la Política de Seguridad Informática esté
actualizada y comunicada.
1
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 4 de 55
Junio 2013
AI1: Identificación
de soluciones
Definido Nos parece que el mecanismo de captura de iniciativas
debiese cambiar desde uno basado en la construcción
de una lista de necesidades que luego se plasman en
metas a uno en que las iniciativas se deriven de la
planificación informática y el criterio de corte sea el
impacto al logro de los Objetivos de la BCN. Toda
iniciativa debiese tener en primer lugar un análisis de
alineamiento con el plan estratégico, luego un análisis
de factibilidad seguido de una evaluación costo
beneficio basada en un estudio de las alternativas:
desarrollo interno o externo, operación local o
tercerizada. Tenemos dudas respecto de la
conveniencia de que un proceso tan crítico esté fuera
de Sistemas
AI4: Facilidad de
uso
Repetible Se recomienda diseñar un programa especial de
formación de “liderazgo tecnológico” para los
directivos. Se recomienda diseñar un “manual de
capacitadores” que defina con precisión aspectos de
didáctica y también de evaluación de la calidad e
impacto de las capacitaciones realizadas.
Se recomienda desarrollar ayudas en línea y/o
tutoriales para las principales aplicaciones
2
AI7: Instalación y
acreditación de
soluciones y
cambios
Repetible Recomendamos formalizar y documentar el
procedimiento de paso a producción, el cual debe
considerar condiciones mínimas, como el test de
aceptación por parte de operaciones, definición de
SLAs etc. Idealmente, operaciones debiese tomar el
control de la aplicación, una vez aceptada.
2
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 5 de 55
Junio 2013
DS1: Definición y
gestión de los
niveles de servicio
(SLA) con
usuarios/clientes
Inexistent
e
Es fundamental definir cuáles son los niveles de
servicio que se requieren y que se entregarán. Los
SLAs - en particular aspectos tales como
disponibilidad, seguridad, soporte, confiabilidad -,
deben formar parte de las metas del Departamento de
Sistemas. De lo contrario, se producen malos
entendidos y frustración.
1
DS3: Gestión del
rendimiento y la
capacidad
Inexistent
e
Recomendamos realizar anualmente un “capacity
planning” y, a partir de sus resultados, elaborar un plan
de acciones que podría hacer replantarse la arquitectura
de la plataforma, o realizar una inversión en la
plataforma de producción, entre otros.
1
DS5: Garantizar la
seguridad
Repetible Creemos que la administración de la seguridad y las
medidas que está tomando la BCN son adecuadas, sin
embargo, es importante formalizar este proceso.
Es también importante realizar regularmente un
monitoreo de la seguridad (tipo hacking ético) e
implementar las recomendaciones que de allí surjan.
2
DS6: Identificar y
asignar costos
Inexistent
e
Nuestra recomendación es implementar un proceso que
permita llevar una contabilidad por centros de costo y
por proyecto. Posiblemente, la adquisición de un ERP
facilite esta medida.
1
DS10: Gestión de
problemas
Inicial Recomendamos implementar este proceso. Una
efectiva administración de problemas requiere la
identificación y clasificación de problemas, el análisis
de las causas desde su raíz, y la resolución de éstas. El
proceso de administración de problemas también
incluye la identificación de recomendaciones para la
mejora, el mantenimiento de registros de problemas y
la revisión del estatus de las acciones correctivas
2
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 6 de 55
Junio 2013
ME1:
Monitorización y
evaluación del
rendimiento
Inicial Recomendamos implementar este proceso con
urgencia. El convenio de desempeño que se construya
debe considerar indicadores que reflejen cosas tales
como valor aportado al negocio, cumplimientos de
SLAs, eficiencia, etc. Lo que no se mide, no se corrige
ni se mejora
1
ME4: Proveer
auditoría
independiente
Inexistent
e
Recomendamos implementar este proceso mediante
auditorías independientes desarrolladas a intervalos
regulares de tiempo; esto significa que los auditores no
deberán estar relacionados con la sección o
departamento que esté siendo auditado.
2
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 7 de 55
Junio 2013
2. Introducción
El marco de referencia para realizar el diagnóstico y recomendaciones respecto del tipo de
organización de TI requerida por la BCN, así como también evaluar los procesos que esa
organización debiese tener operativos para administrar los recursos TI de la BCN, es el estándar
COBIT.
El estándar COBIT fue creado por agrupaciones de auditores, que se enfrentaron a la necesidad de
realizar auditorías en ambientes informatizados, y no tenían un marco de referencia para entender lo
que allí ocurría, es decir, no sabían qué evaluar ni cómo hacerlo.
COBIT ha evolucionado hasta convertirse en un estándar para las auditorías informáticas, dado que
ofrece un conjunto de “mejores prácticas” para la gestión de los recursos informáticos y de los
sistemas de información de cualquier organización.
El objetivo principal de COBIT consiste en proporcionar una guía de alto nivel sobre puntos en los
que se deben establecer controles internos con tal de:
Asegurar el buen gobierno, protegiendo los intereses de los “stakeholders” (clientes,
accionistas, empleados, etc.)
Garantizar el cumplimiento normativo del sector al que pertenece la organización
Mejorar la eficacia y eficiencia de los procesos y actividades de la organización
Garantizar la confidencialidad, integridad y disponibilidad de la información
El estándar define el término control como: “Políticas, procedimientos, prácticas y estructuras
organizacionales diseñadas para asegurar razonablemente de que se lograrán los objetivos del
negocio y se prevendrán, detectarán y corregirán los eventos no deseables”
Por tanto, la definición abarca desde aspectos organizativos (p.ej. flujo para pedir autorización a
determinada información, procedimiento para reportar incidencias, selección de proveedores, etc.)
hasta aspectos más tecnológicos (p.ej. control de acceso a los sistemas, monitorización de los
sistemas mediante herramientas automatizadas, etc.).
ASPECTOS CLAVES EN GOBIERNO DE TI
Los aspectos clave que la alta dirección de una empresa debe gestionar respecto a las tecnologías de
la información, son:
- Adecuación de la planificación de TI a la planificación general de la Organización
La planificación de TI es un proceso fundamental de la gestión de TI, pero la alta dirección
de las empresas debe asegurarse de que los planes de TI se integran adecuadamente con la
planificación general.
- Posición de la Organización de TI en el organigrama general de la Empresa
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 8 de 55
Junio 2013
Sin que exista una regla general sobre cuál debiera ser la posición del CIO (Chief
Information Officer) y de la organización de TI en el organigrama general, existe acuerdo
en que una adecuada ubicación de esta unidad será crítica para el éxito de la estrategia de TI
de la compañía.
- Criticidad de los servicios y el conocimiento de TI para el negocio. Fórmula óptima de
aprovisionamiento de servicios de TI.
Resulta vital evaluar la criticidad de los servicios que TI proporciona para el negocio y,
especialmente, la relevancia del conocimiento del negocio incluido en los sistemas de
información y en las personas que los construyen y mantienen. Este nivel de criticidad será
un input esencial para decidir la fórmula óptima de aprovisionamiento de servicios de TI,
que puede combinar en diferentes grados un equipo puramente interno, una combinación
con servicios adquiridos externamente, e incluso una externalización total ("outsourcing").
- Nivel de inversión / gasto razonable en TI
Una de las decisiones más difíciles para los órganos de gobierno de las empresas, es el nivel
de inversión. Por una parte, siempre se encuentran necesidades insatisfechas en las áreas de
negocio y, por otra parte, existen posibilidades tecnológicas propuestas por la gente de TI.
En la mayor parte de las ocasiones es muy difícil hacer un análisis costo-beneficio riguroso
de las alternativas posibles, lo que obliga a establecer un nivel de gasto e inversión
considerado "razonable", normalmente en base anual. En la práctica lo más habitual es
regirse por comparaciones (benchmarking) con otras empresas similares del mismo sector, y
ajustarlo según las pretensiones de avance tecnológico relativo.
- Información periódica y puntual desde el CIO a la alta dirección. Métricas de rendimiento.
La alta dirección debe disponer de una información periódica y consistente del rendimiento
de los servicios, los proyectos, los procesos y la situación financiera de la TI. Para ello se
deben establecer métricas que resulten significativas y estadísticamente rigurosas.
- Participación de las áreas de negocio y otras áreas de soporte en la planificación y la gestión de la
demanda
En determinados procesos de la gestión de TI, especialmente en la planificación y gestión de
la demanda, deben participar las áreas de negocio y otras áreas de soporte (por ejemplo:
RRHH), manteniendo una colaboración armoniosa.
- Imputación de los costos de TI a las áreas de negocio y sus productos, procesos o clientes
La alta dirección debe decidir cuáles han de ser los criterios de imputación de los costos de
TI al resto de las áreas. En muchas ocasiones no es algo pacífico, puesto que puede tratarse
de costos que impacten de forma relevante en las cuentas de resultados de las áreas de
negocio.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 9 de 55
Junio 2013
- Requisitos de seguridad de la información y los procesos
El nivel de exigencia en cuanto a requisitos de seguridad tiene un fuerte impacto en los
costos y la gestión diaria de la TI. Por lo tanto, será importante establecer el nivel óptimo
que equilibre los costos y los riesgos globales. Muchas veces una seguridad excesiva supone
un derroche, pero en otras, una seguridad laxa pone en riesgo la supervivencia de la
empresa.
La preocupación central del modelo de referencia COBIT es que los recursos informáticos que
dispone una organización (aplicaciones, infraestructura, instalaciones físicas, RRHH, datos) se
administren de manera adecuada para cubrir los requerimientos del negocio, es decir:
Efectividad (cumplimiento de objetivos)
Eficiencia (consecución de los objetivos con el máximo aprovechamiento de los recursos)
Confidencialidad
Integridad
Disponibilidad
Cumplimiento regulatorio
Confiabilidad
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 10 de 55
Junio 2013
3. Areas de enfoque de Gobierno de TI2
Alineación Estratégica
Se enfoca en garantizar la alineación entre los planes de negocio y de TI; en definir,
mantener y validar la propuesta de valor de TI; y en alinear las operaciones de TI con las
operaciones de la empresa.
Entrega de Valor
Se refiere a ejecutar la propuesta de valor a todo lo largo del ciclo de entrega, asegurando
que las TI generen los beneficios prometidos en la estrategia, concentrándose en optimizar
los costos y en brindar el valor intrínseco de la TI.
Administración de Riesgos
Se requiere conciencia de los riesgos por parte de los altos ejecutivos de la empresa, un claro
entendimiento del apetito de riesgo que tiene la empresa, comprender los requerimientos de
cumplimiento, transparencia de los riesgos significativos para la empresa, y la inclusión de
las responsabilidades de administración de riesgos dentro de la organización.
2 Sistemas de Información para la Gestión, Fac.de Cs. Económicas, Jurídicas y Sociales –
Universidad Nacional de Salta
Gobierno de TI
Medición de desempeño Entrega de valor
Alineación estratégica
Administración de recursos Administración de riesgos
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 11 de 55
Junio 2013
Administración de Recursos
Se trata de la inversión óptima, así como la administración adecuada de los recursos críticos
de TI; aplicaciones, información, infraestructura y personas. Los temas claves se refieren a
la optimización de conocimiento y de infraestructura.
Medición del Desempeño
Rastrea y monitorea la estrategia de implementación, la terminación del proyecto, el uso de
los recursos, el desempeño de los procesos y la entrega del servicio, con el uso, por ejemplo,
de balanced scorecards que traducen la estrategia en acción para lograr las metas medibles
más allá del registro convencional.
Para que esto ocurra, COBIT propone la existencia y el control de un conjunto de procesos (ver
ilustración 1) destinados a:
e. planificar y organizar las actividades de TI,
f. adquirir e implementar aplicaciones e infraestructura,
g. operar la infraestructura, entregar los servicios aplicativos y brindar soporte, y
h. monitorear el cumplimiento de los niveles de servicio, los estándares de seguridad, el
desempeño de la TI dentro de la organización.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 12 de 55
Junio 2013
Ilustración 1: procesos de TI de COBIT
Cada dominio contiene procesos desglosables en actividades, para los cuales se pueden establecer
objetivos de control e implementar controles organizativos o automatizados.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 13 de 55
Junio 2013
4. Madurez de procesos
Cabe destacar que Cobit también ofrece mecanismos para la medición de las capacidades de los
procesos con el objeto de conseguir una mejora continua. Para ello, proporciona indicaciones para
valorar la madurez en función de la misma clasificación utilizada por estándares como ISO:
Nivel 0 – Proceso inexistente o incompleto: El proceso no existe o no cumple con los
objetivos
Nivel 1 – Proceso inicial o ejecutado
Nivel 2 – Proceso repetible o gestionado: el proceso no solo se encuentra en
funcionamiento, sino que es planificado, monitorizado y ajustado.
Nivel 3 – Proceso definido: el proceso, los recursos, los roles y responsabilidades se
encuentran documentados y formalizado.
Nivel 4 – Proceso administrado o predecible: se han definido técnicas de medición de
resultados y controles.
Nivel 5 – Proceso optimizado: todos los cambios son verificados para determinar el impacto,
se han definido mecanismos para la mejora continua, etc.
5. Procesos COBIT
5.1. Dominio Planificación y Organización Este dominio cubre las estrategias y las tácticas, y tiene que ver con identificar la manera en que las
TI pueden contribuir de la mejor manera al logro de los objetivos del negocio. Además, la
realización de la visión estratégica requiere ser planeada, comunicada y administrada desde
diferentes perspectivas. Finalmente, se debe implementar una estructura organizacional y una
estructura tecnológica apropiada. Este dominio cubre los siguientes cuestionamientos típicos de la
gerencia:
• ¿Están alineadas las estrategias de TI y del negocio?
• ¿La empresa está alcanzando un uso óptimo de sus recursos?
• ¿Entienden todas las personas dentro de la organización los objetivos de TI?
• ¿Se entienden y administran los riesgos de TI?
• ¿Es apropiada la calidad de los sistemas de TI para las necesidades del negocio?
Para ello, COBIT presenta 10 procesos:
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 14 de 55
Junio 2013
PO1 – Definición de un plan estratégico de TI: gestión del valor, alineación con las
necesidades del negocio, planes estratégicos y tácticos.
Situación actual BCN:
En términos de madurez, este proceso se encuentra entre el nivel 0“Indefinido” y el nivel 1
“Inicial”.
El Jefe de Sistemas señala que recibió instrucciones de la antigua administración en el sentido
de que no era necesario realizar un plan informático, más importante era responder
oportunamente a la dinámica de los acontecimientos. Tampoco existe un Plan estratégico de la
BCN del cual derivar el Plan Informático.
En lugar de plan informático se realizan planes operativos anuales que se expresan como un
conjunto de metas (que incluyen elementos de continuidad y proyectos nuevos) y una carta
Gantt. El proceso que se sigue es el siguiente: anualmente, la BCN realiza una reunión de
Comité de Estrategia en la que se definen las grandes líneas de acción del año siguiente (ej:
“potenciar los servicios”, “potenciar la asesoría”, “edificio nuevo”, “reestructuración de la
planta”). Luego los Departamentos plantean metas alineadas con esas estrategias. Los
Departamentos de Sistemas y el Area de Arquitectura de la Información participan en todas las
reuniones y analizan si las metas de los departamentos incluirán esfuerzos de TI. A veces se
generan metas transversales (p.e., “definir y modelar ontologías de la BCN”), y otras
específicas. A fines de Diciembre, las metas de TI están acordadas con la Dirección y se
firman. Luego, durante su ejecución, hay revisiones de avance trimestrales, y se pueden
renegociar algunas metas. Toda esta conversación no está alineada con el presupuesto, ya que
ocurren a destiempo.
Existen además lineamientos estratégicos de TI definidos en el 2004 por el Jefe de Sistemas y
que se han mantenido a lo largo de estos años.
Revisadas las metas de TI, éstas se parecen más a una lista de actividades que a metas que
miden el valor que agrega al negocio, la eficiencia, la satisfacción de los usuarios, el
cumplimiento de los niveles de servicio etc.
Recomendaciones:
Implementar con alta prioridad un proceso de Planificación Informática en la BCN al menos
con un nivel de madurez 2 (repetible), en lo posible 3 (definido o gestionado). Este proceso
debiera llevarse a cabo cada 3 o 4 años, y evaluarse/corregirse anualmente. Nuestra sugerencia
es que forme parte del proceso de Planificación Estratégica de la BCN. Métricas: - Existencia de un plan estratégico de TI
- El porcentaje de proyectos de TI en el plan estratégico de TI, que dan soporte al plan
estratégico del negocio
- ROI del plan informático
Fundamentación:
La planificación estratégica de TI es necesaria para gestionar y dirigir todos los recursos de TI
en línea con la estrategia y prioridades de la BCN. La BCN debe asegurar obtener el valor
óptimo de los proyectos de TI. El plan estratégico asegura que la estrategia de negocio y
prioridades se reflejen en el portafolio de iniciativas. Se evita la aparición de iniciativas o
proyectos que son producto de demandas específicas pero que tienen poco que ver con la
misión y objetivos de la BCN (ej creación de sitio “Nicanor Parra”).
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 15 de 55
Junio 2013
P02 – Definición de la arquitectura de información: modelo de arquitectura, diccionario
de datos, clasificación de la información, gestión de la integridad.
Situación actual BCN:
En términos de madurez, este proceso se encuentra en estado “Inicial”.
El Jefe de Sistemas señala que no existe un modelo de información, sin embargo se está
trabajando con un enfoque de modelo ontológico, en extender las ontologías a todos los
modelos de datos de la BCN, ya que actualmente estas ontologías no contemplan DAF,
Repositorios, Sistema Bibliográfico, Noticias, entre otras. Existe también un proceso
instalado para mantener las ontologías. Actualmente se están analizando los diferentes
sistemas para unificar sus datos, ya que hay muchos sistemas antiguos “Legacy”
(heredados) cuyas estructuras de información no están documentadas.
Recomendaciones:
Implementar con alta prioridad este proceso en la BCN al menos con un nivel de madurez
2 (repetible), en lo posible 3 (definido o gestionado). Este proceso debiese tener un
responsable que podría ser el “arquitecto” o el responsable del modelo corporativo de
datos. Debiesen existir responsables de dominios de información así como políticas de
seguridad sobre éstos. Sugerimos medir este proceso con: • El porcentaje de elementos de datos redundantes / duplicados
• El porcentaje de aplicaciones que no cumplen con la metodología de arquitectura de la
información usada por la BCN
Fundamentación:
El Departamento de Sistemas debe crear y actualizar de forma regular un modelo de
información del negocio y definir los sistemas apropiados para optimizar el uso de esta
información. Esto incluye el desarrollo de un diccionario corporativo de datos que contiene
las reglas de sintaxis de los datos de la organización, el esquema de clasificación de datos y
los niveles de seguridad. Este proceso mejora la calidad de la toma de decisiones directivas
asegurándose que se proporciona información confiable y segura, y permite racionalizar los
recursos de los sistemas de información. Este proceso de TI también es necesario para
incrementar la responsabilidad sobre la integridad y seguridad de los datos y para mejorar
la efectividad y control de la información compartida a lo largo de las aplicaciones y de las
entidades.
Las ontologías complementan, pero no sustituyen la necesidad de contar con modelos de
información.
Ontologías: al igual que los tesauros, son herramientas que sirven para estructurar
conceptualmente determinados ámbitos del conocimiento por medio de vocabularios
controlados; son sistemas de representación del conocimiento que resultan de seleccionar
un dominio o ámbito del conocimiento, y aplicar sobre él un método con el fin de obtener
una representación formal de los conceptos que contiene y de las relaciones que existen
entre dichos conceptos (tuplas). Además, una ontología se construye en relación a un
contexto de utilización.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 16 de 55
Junio 2013
P03 – Determinar las directrices tecnológicas: análisis de tecnologías emergentes,
monitorizar tendencias y regulaciones.
Situación actual BCN:
Actualmente este proceso se lleva a cabo, aunque de manera informal y no documentada.
Se encuentra en el nivel 2. Los mecanismos que se utilizan son: - El responsable de TI mantiene contacto permanente con la Academia
- El responsable de TI monitorea permanentemente lo que ocurre en el entorno, las
tendencias tecnológicas etc.
- La BCN pertenece a la IFLA y el responsable de TI participa de un grupo de Jefes de
Informática de la IFLA, en el que participan las bibliotecas de EEUU, Inglaterra y
Alemania, consideradas como las mejores prácticas.
- Desde el punto de vista de la infraestructura, la BCN analiza anualmente su plataforma
de servidores y se hace un plan de crecimiento/migración basado en lo que está
ocurriendo en el mercado, y en resolver problemas que le impiden escalar (p.e., frente a
los problemas de energía y de espacio en la sala de servidores, han optado por migrar a
servidores blade que comparten la información en storage area network)
Recomendaciones:
Recomendamos mantener este proceso como está, pero sí documentarlo.
Fundamentación:
La BCN es una institución altamente innovadora; la innovación en procesos y
productos/servicios, así como la búsqueda de la excelencia operacional (“Promover un
estilo de liderazgo en gestión pública y modernización del Estado, constituyéndose en sí
misma como modelo de servicio”) forman parte de la declaración misional, por lo que es
fundamental mantener procesos de innovación en áreas como la gestión de TI, que juegan
un rol cada vez más importante en la eficiencia de los procesos y en la entrega de los
productos/servicios.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 17 de 55
Junio 2013
P04 – Definición de procesos de TI, organización y relaciones: análisis de los procesos,
comités, estructura organizativa, responsabilidades, propietarios de la información,
supervisión, segregación de funciones, políticas de contratación.
Situación actual BCN:
En términos de su madurez, este proceso se encuentra en estado “Inicial”. En efecto, no
existe un proceso formal de definición y documentación de los procesos de gestión de los
recursos TI.
En cuanto al diagnóstico organizacional y las recomendaciones en este ámbito, éstos
forman parte del Informe 3 de esta asesoría.
Recomendación:
Implementar con alta prioridad este proceso en la BCN al menos con un nivel de madurez
2 (repetible), deseable 3. Se deben identificar y documentar los principales procesos y
procedimientos de gestión de los recursos informáticos. En lo posible se deben también
medir. Deben ser conocidos por las personas del área TI y sus clientes y deben ser
comunicados para conocimiento de la organización. Se recomienda el uso de un sistema
documental con control de versiones para su almacenamiento, pues los documentos son
dinámicos. La BCN propone utilizar un sistema de gestión documental con control de
versiones de código abierto, como openKM, http://www.openkm.com/es
Proponemos utilizar el modelo COBIT como modelo de referencia para la definición de los
procesos. Medición: - % de procesos documentados con procedimientos definidos
Fundamentación:
La BCN depende cada vez más de la TI para la producción así como para la entrega de sus
productos y servicios. Por lo mismo, los recursos tecnológicos deben ser adecuadamente
administrados y resguardados. Lo único que garantiza este objetivo, es asegurar un nivel
adecuado de madurez de los procesos que le permita gestionar los recursos tecnológicos y
la información.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 18 de 55
Junio 2013
P05 – Gestión de la inversión en tecnología: gestión financiera, priorización de proyectos,
presupuestos, gestión de los costes y beneficios.
Situación actual BCN:
En términos de madurez, este proceso se encuentra en estado “Repetible”. No obstante ello,
se identifican importantes deficiencias que se describen a continuación.
El proceso responde aproximadamente a la siguiente lógica: en junio, el Departamento de
Sistemas hace su presupuesto para el año siguiente (a esas alturas las metas no están
definidas). Luego, el Departamento de Sistemas no participa de la negociación (la que es
liderada por el DAF) y sólo se entera de los resultados en enero, en que conoce sólo
algunas de las partidas, directamente a través de la publicación del presupuesto que realiza
la DIPRES. En Marzo se entera a través del DAF del detalle, lo que resulta tardío para
planificar la ejecución.
Desde el punto de vista de la ejecución, el área a cargo de las TI no tiene el control
completo de su presupuesto ya que a menudo otras áreas imputan sus inversiones al
presupuesto de TI y no lo informan.
Finalmente, las asignaciones de los recursos no siempre corresponden a los subtítulos e
ítems contables solicitados por el Departamento de Sistemas.
Recomendaciones:
Se deben mejorar los procesos de formulación y ejecución presupuestaria. En particular, el
presupuesto debe reflejar el plan de trabajo del año siguiente, tanto en su componente de
continuidad, como en su componente de expansión (nuevos proyectos). El plan estratégico
de TI puede ayudar a mejorar el vínculo entre plan y presupuesto.
Es importante que el Departamento de Sistemas se entere oportunamente del presupuesto
disponible, de modo de planificar oportunamente las compras.
En relación a la ejecución, es importante que el Departamento de Sistemas tenga el control
sobre su presupuesto (p.e., a través de un V°B°), más allá de que otras áreas pudiesen ser
responsables de ciertas partidas. También es importante que rinda cuentas de la ejecución a
los Comités que debiesen crearse. Finalmente, es importante construir un buen plan de
cuentas con manejo de centros de costos y cuidar que las imputaciones vayan a las cuentas
y centros de costo que corresponde, para realizar un buen control presupuestario y análisis
de costos. Métricas: - Ejecución presupuestaria
- Informes mensuales de gestión del presupuesto
- Alineamiento del Presupuesto con el Plan
Fundamentación:
Establecer y mantener un proceso presupuestal formal y una administración contra ese
presupuesto fomenta la asociación entre TI y los interesados del negocio, los que son
consultados para identificar y controlar sus costos y beneficios totales y tomar medidas
correctivas en caso de ser necesario; facilita el uso efectivo y eficiente de recursos de TI, y
brinda transparencia y responsabilidad, la materialización de los beneficios del negocio y el
retorno sobre las inversiones en TI.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 19 de 55
Junio 2013
P06 – Gestión de la comunicación: políticas y procedimientos, concienciación de usuarios.
Situación actual BCN:
En términos de madurez, este proceso se encuentra en estado “Inexistente”.
Se han hecho esfuerzos esporádicos de informar a la comunidad de los logros en TI, sin
embargo no forma parte de un proceso regular. Se informan novedades a través de la
Intranet, pero no se evalúa la llegada de estos mensajes. No hay un comité directivo donde
plantear inquietudes y problemas en la gestión de TI, estos intercambios se realizan
mediante conversaciones aisladas o intercambios de correos con la dirección.
Recomendaciones:
Se recomienda implementar con alta prioridad este proceso en la BCN, al menos con un
nivel de madurez 2 (repetible). Recomendamos elaborar un relato acerca de la forma en
que las TI contribuyen a los logros de los propósitos fundamentales de la BCN (p.e.,
agregar valor al proceso legislativo, acercar las leyes a las personas y por tanto a formar un
“mejor ciudadano” etc.). Luego la BCN debe identificar sus diferentes comunidades o
“stakeholders” y transformar ese relato en mensajes y en canales de comunicación
diferenciados, que podrían ser los mismos que utiliza la propia BCN para implementar su
estrategia comunicacional. Este proceso debe ser liderado por el responsable de TI de la
BCN y desplegado en coordinación con el equipo de comunicaciones de la BCN.
Sugerimos medirlo con:
- Indicador que mide la visión de la organización acerca del rol de la TI
- Auditoría comunicacional; porcentaje de interesados que entienden el marco de trabajo
de TI
- Porcentaje de interesados que no cumple las políticas
Fundamentación:
Las comunicaciones son fundamentales para el logro de los objetivos de TI y aseguran la
toma de conciencia de los usuarios acerca de sus deberes y derechos, en particular el
entendimiento de los riesgos de negocio y de TI. Forman parte y son un apoyo al complejo
proceso de gestión del cambio. Un programa de comunicación a cargo del responsable de
TI se debe implementar para articular la visión, misión, los objetivos de servicio, las
políticas y procedimientos, etc., aprobados y apoyados por la dirección.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 20 de 55
Junio 2013
P07 – Gestión de los recursos humanos de las TI: contratación, competencias del
personal, roles, planes de formación, evaluación del desempeño de los empleados.
Situación actual BCN:
En términos de madurez, este proceso se encuentra en estado “Inicial”.
La Planta de TI está definida en la Ley Orgánica y es inamovible. La actual organización se
heredó, no ha sido planificada. Se han incorporado unos pocos cargos nuevos.
Existe una definición muy básica de los perfiles de cargo. Se trató de hacer algo con el
Eucip (European Certification of Informatics Professionals), pero las brechas eran
enormes. Esa iniciativa se abortó.
El Departamento Sistemas cuenta con funcionarios de planta y de contrata. Es la DAF a
través del área de RRHH de la BCN quien administra los RRHH del Departamento de
Sistemas, con sugerencias de esta misma área. Esto incluye sueldos, vacaciones, etc. El
esquema es rígido, no permite incentivos. La calificación del personal es un instrumento
formal que no sirve a los propósitos de evaluar desempeño
Hay personas que tienen conocimientos que son críticos para la organización y que no
están del todo respaldados, lo que constituye un riesgo.
Recomendaciones:
Es importante definir con precisión qué servicios se externalizarán y cuáles quedarán
dentro de la BCN. A partir de esta definición, se debe determinar la dotación, y describir
los perfiles de cada cargo. Debe existir una evaluación regular del desempeño del personal
y un plan de desarrollo que permita cerrar las brechas encontradas en la evaluación. Es
importante que las personas de TI trabajen motivadas y que existan incentivos a la
excelencia. Es importante también hacer una buena gestión del conocimiento, en particular
de aquel conocimiento considerado crítico para el funcionamiento de la BCN, y respaldar
ese conocimiento experto. Algunas métricas: • El nivel de satisfacción de los clientes respecto a la experiencia y habilidades del personal
• La rotación de personal de TI
• Porcentaje de personal de TI certificado de acuerdo a las necesidades del negocio
Fundamentación:
Adquirir, mantener y motivar una fuerza de trabajo para la creación y entrega de servicios
de TI para el negocio se logra siguiendo prácticas definidas y aprobadas que apoyan el
reclutamiento, entrenamiento, la evaluación del desempeño y el desarrollo de carrera. Este
proceso es muy importante, ya que las personas son activos fundamentales en la BCN, y el
ambiente de gobierno y de control interno depende fuertemente de la motivación y
competencia del personal.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 21 de 55
Junio 2013
P08 – Gestión de la calidad: mejora continua, orientación al cliente, sistemas de medición
y monitorización de la calidad, estándares de desarrollo y adquisición.
Situación actual BCN:
Estado: Inicial
No está instalado un proceso formal de aseguramiento de calidad en los diferentes procesos
de gestión de TI de la BCN, de hecho muchos de ellos no están documentados y no se
miden. En particular, no existe un proceso de calidad asociado a la provisión de soluciones
informáticas que permita realizar la trazabilidad de los requerimientos, evaluar la calidad
de los diseños, métricas, productividad, testing de las aplicaciones, calidad de los manuales
etc..
Los procesos que se miden actualmente en términos de operación y solución de los
problemas, son soporte y operación de Ley Chile.
El área de Sistemas está contratando un QA para Historia de la Ley y Labor Parlamentaria;
esta es una práctica exclusiva para los proyectos grandes.
Se utilizan las herramientas - Selenium para la automatización del testing.
- WAPT: herramienta para pruebas de desempeño, carga y stress de sitios Web.
Recomendaciones:
Este proceso debe pasar al estado 3 de madurez (Definido).
Recomendamos que exista una función (no necesariamente de dedicación exclusiva)
responsable de elaborar y mantener un sistema de administración de la calidad y cautelar
este aspecto en los procesos de TI. Podría ser una tarea compartida con control de gestión.
Los requerimientos de calidad se deben manifestar y documentar con indicadores
cuantificables y alcanzables.
Recomendamos que la BCN certifique algunos de sus procesos de gestión de TI según la
norma ISO de calidad (otros estándares como CMM pueden resultar onerosos). En otros,
basta adoptar buenas prácticas y monitorear que se cumplan ciertos estándares de calidad.
Igualmente, si va a externalizar servicios, debe evaluar exigir certificaciones de calidad a
sus proveedores.
Fundamentación:
La administración de calidad es esencial para garantizar que TI está dando valor al negocio,
mejora continua y transparencia para los clientes. Además, es la forma de asegurar que los
procesos de gestión de la TI sean confiables.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 22 de 55
Junio 2013
P09 – Validación y gestión del riesgo de las TI
Situación actual BCN:
Estado: Inicial
La BCN no tiene un mapa de los riesgos asociados a la entrega de sus productos y servicios
Como consecuencia de lo anterior, el departamento de sistemas no tiene un mapa de
riesgos de continuidad operacional que responda a la pregunta de ¿cómo afecta a la BCN
un mal servicio de TI?
La BCN hace una evaluación de riesgos por proyecto.
El departamento de Sistemas realiza un monitoreo automatizado de su plataforma mediante
una herramienta llamada Nagios, que monitorea los signos vitales de los servidores, y
también la disponibilidad de las aplicaciones. Asimismo, hay una política de respaldos de
los principales servidores. Es un buen punto de partida pero no es suficiente.
Recomendaciones:
Pasar a estado Definido.
Implementar un mapa de riesgos de la BCN con sus respectivos planes de mitigación. De
manera análoga, hacerlo para los procesos de TI. Métricas: • Porcentaje de objetivos críticos de TI cubiertos por la evaluación de riesgos
• Porcentaje de riesgos críticos de TI identificados con planes de acción elaborados
• Porcentaje de planes de acción de administración de riesgos aprobados para su
implantación
Fundamentación:
Las organizaciones enfrentan grandes riesgos como son las amenazas de fraudes e
indisciplinas que incluyen la destrucción de la reputación de las empresas, la disminución
del valor de la marca, la pérdida patrimonial, daños penales y severas multas (p.e., ¿qué
pasa si se entrega el texto actualizado de una ley, defectuoso? ¿qué consecuencias tiene que
se entregue una asesoría de mala calidad?, o bien ¿qué ocurre si se entrega información
errónea acerca de la actividad de un parlamentario?). Esto se tornará aún más crítico
cuando la BCN tenga la responsabilidad de entregar la versión oficial de los códigos
(cabe recordar las consecuencias de una reciente mala entrega de información por parte del
Servel acerca de la fecha de inscripción de un candidato a la presidencia).
Administrar las áreas de mayor riego del negocio puede ayudar a asegurar que los fraudes
potenciales sean prevenidos y que cualquier riesgo reputacional sea administrado. La
Administración Superior de una organización debe estar segura de que sus programas y
controles internos sean realmente efectivos.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 23 de 55
Junio 2013
P10 – Gestión de proyectos: planificación, definición de alcance, asignación de recursos,
etc.
Situación actual BCN:
Estado: inicial
Los "proyectos grandes y complejos" son desarrollados por el área de Proyectos
Tecnológicos, responsable de la gestión de los siguientes proyectos: ley Chile, Labor
parlamentaria, Web semántica e Historia de la Ley, los que se desarrollan esencialmente
con apoyo de terceros. No hay un proceso formal que define la forma en que se gestionan
estos proyectos, sin embargo existe una plantilla que describe las etapas de un proyecto, y
que se basa en la metodología Rational Unified Process RUP(*).
Los proyectos "pequeños" en cambio, los desarrolla el área de Ingeniería y Desarrollo con
recursos internos y ocasionalmente outsourcing de personal. Algunos proyectos “grandes”
también han sido conducidos por esta área (p.e., workflow BCN y portal ciudadano).
Estos no siguen un proceso formal de gestión de proyectos, no hay estándares respecto de
las etapas de un proyecto (factibilidad, análisis, diseño, construcción, testing etc..)
Como herramientas de apoyo, todos utilizan: - Wrike para el seguimiento y control de los proyectos
- PSP para llevar un control de la actividad diaria.
- Wiki para la documentación (manuales) (wikimanuales.bcn)
No existe una PMO, ni en la BCN ni en Sistemas. Los Jefes de Sección controlan el avance
de sus proyectos. Tienen reuniones semanales de coordinación en que se revisan estos
avances. Todos reportan via Wrike. Algunos proyectos de TI están asociados a metas; en
estos casos, el control de gestión de la BCN hace un control trimestral de avance.
(*) RUP: Junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más
utilizada para el análisis, diseño, implementación y documentación de sistemas orientados a objetos. RUP no
es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y
necesidades de cada organización
Recomendación:
Este es otro proceso crítico. Recomendamos pasar a un estado de madurez 4 (administrado)
o 5 (optimizado) Se requiere definir y socializar una manera de gestionar proyectos en la
BCN (un “BCN way”) que incorpore las mejores prácticas en este dominio.
Probablemente una versión simplificada y localizada del estándar PMBOK (“Project
Management Body of Knowledge”) del Project Management Institute, o Prince. También
es importante capacitar a los Jefes de Proyecto en torno a esta metodología.
Fundamentación:
La gestión de proyectos es una competencia clave para asegurar que los proyectos se
ejecuten en tiempo, en costo y sobre todo, con la calidad requerida por los clientes. La
BCN puede externalizar una buena cantidad de tareas relacionadas con la gestión de TI,
pero esta es una de las que debe quedar al interior.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 24 de 55
Junio 2013
P11 – Definición de política de seguridad
Situación actual BCN:
Estado: Repetible
En la BCN existe una política de seguridad así como un documento de derechos y deberes
de los usuarios (no así un proceso periódico de revisión, actualización y aprobación).
Ambos documentos se encuentran publicados en la Intranet. Parte importante de la política
se implementa en el firewall. La filosofía en esta materia es: “no hay nada que ocultar, el
grueso de la información es pública; pero es inaceptable que alguien altere la
información”. El Departamento de Sistemas es fuertemente partidario del Opendata
BCN tiene un servicio de monitoreo de intrusos (IPS Fortigate). Están en un plan de tener
single sign on. Este año van a contratar un “hacking ético”
Recomendaciones:
Transformar el proceso en “definido”. Asegurarse de que la Política de Seguridad
Informática esté actualizada y considere los siguientes elementos:
Alcance de la política, incluyendo facilidades, sistemas y personal sobre la cual aplica.
Objetivos de la política y descripción clara de los elementos involucrados en su
definición.
Responsabilidades por cada uno de los servicios y recursos informáticos aplicado a
todos los niveles de la organización.
Requerimientos mínimos para configuración de la seguridad de los sistemas que abarca
el alcance de la política.
Definición de violaciones y sanciones por no cumplir con las políticas.
Responsabilidades de los usuarios con respecto a la información a la que tiene acceso.
Es muy importante hacer participar a la Dirección en esta política así como difundirla
Fundamentación:
La seguridad informática es el área de la informática que se enfoca en la protección de la
infraestructura computacional y todo lo relacionado con ésta (incluyendo la información
contenida). Para ello existen una serie de estándares, protocolos, métodos, reglas,
herramientas y leyes concebidas para minimizar los posibles riesgos a la infraestructura o a
la información. La seguridad informática comprende software, bases de datos, metadatos,
archivos y todo lo que la organización valore (activo) y signifique un riesgo si ésta llega a
manos de otras personas. Este tipo de información se conoce como información
privilegiada o confidencial. Las políticas de seguridad informática surgen como una
herramienta organizacional para concientizar a los colaboradores de la organización sobre
la importancia y sensibilidad de la información y servicios críticos que permiten a la
empresa crecer y mantenerse competitiva.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 25 de 55
Junio 2013
Nota:
Podemos encontrar puntos de conexión con otros estándares y marcos de trabajo que pueden servir
de soporte:
Cobit Relacionado
P04 – Definición de procesos IT, organización y
relaciones Procesos según ISO
3
P05 – Gestión de la inversión en tecnología Val IT
4 y VMM
5 (Value Measuring
Methodology)
P08 – Gestión de la calidad ISO 90006
P09 – Validación y gestión del riesgo de las
tecnologías de la información
BS 7799-3 (Guidelines for information
security risk management)
P10 – Gestión de proyectos PMBok7 y PRINCE2
8
3 http://www.marblestation.com/?p=645
4 http://en.wikipedia.org/wiki/Val_IT
55 http://en.wikipedia.org/wiki/Value_Measuring_Methodology
6 http://en.wikipedia.org/wiki/Iso_9000
77 http://en.wikipedia.org/wiki/Project_Management_Body_of_Knowledge
8 http://en.wikipedia.org/wiki/Prince2
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 26 de 55
Junio 2013
5.2. Dominio Adquisición e Implementación Para llevar a cabo la estrategia de TI, las soluciones de TI necesitan ser identificadas, desarrolladas
o adquiridas, así como implementadas e integradas en los procesos del negocio. Además, el cambio
y el mantenimiento de los sistemas existentes está cubierto por este dominio para garantizar que las
soluciones sigan satisfaciendo los objetivos del negocio. Este dominio, por lo general, cubre los
siguientes cuestionamientos de la gerencia: ¿Es probable que los nuevos proyectos generan soluciones que satisfagan las necesidades del
negocio?
¿Es probable que los nuevos proyectos sean entregados a tiempo y dentro del presupuesto?
¿Trabajarán adecuadamente los nuevos sistemas una vez sean implementados?
¿Los cambios no afectarán a las operaciones actuales del negocio?
Con el objeto de garantizar que las adquisiciones de aplicaciones comerciales, el desarrollo de
herramientas a medida y su posterior mantenimiento se encuentren alineados con las necesidades
del negocio, el estándar Cobit define los siguientes 7 procesos:
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 27 de 55
Junio 2013
AI1 – Identificación de soluciones: análisis funcional y técnico, análisis del riesgo, estudio de la
viabilidad.
Situación actual BCN:
Estado: definido. Este proceso lo desarrolla el área de Arquitectura de la Información (AI),
externa a Sistemas (salvo en proyectos grandes como Ley Chile). El proceso sigue
aproximadamente los siguientes pasos: AI es el principal captador de necesidades de sistemas
de información. Trabaja con los clientes levantando alcances, requerimientos, hasta elaborar
maquetas en las que plasma el diseño de las aplicaciones. Las comparte con el Departamento
de Sistemas y empieza un proceso de negociación sobre duración y recursos hasta llegar a
acuerdo. TI empieza entonces el proceso de construcción. Una vez terminado el sistema, se
entrega a AI para su revisión, requisito previo a la entrega al cliente.
AI tiene parcialmente documentado el proceso. En la descripción del proceso, Sistemas
aparece como una fábrica de software.
Recomendaciones:
Algunos aspectos de este proceso deberían formalizarse más de lo que están, en particular lo
que dice relación con las interfaces entre Sistemas y Arquitectura.
Nos parece que el mecanismo de captura de iniciativas debiese cambiar desde uno basado en
la construcción de una lista de necesidades que luego se plasman en metas a uno en que las
iniciativas se deriven de y una planificación informática y el criterio de corte sea el impacto al
logro de los Objetivos de la BCN. Toda iniciativa debiese tener en primer lugar un análisis de
alineamiento con el plan estratégico, luego un análisis de factibilidad seguido de una
evaluación costo beneficio basada en un estudio de las alternativas: desarrollo interno o
externo, operación local o tercerizada. Sugerimos ampliar las alternativas y evaluar contratar
en modalidad “Software como un servicio” SaaS, en particular para aquellas aplicaciones que
no forman parte del core de la BCN.
Tenemos serias dudas respecto de la conveniencia de que un proceso tan crítico esté fuera de
Sistemas. Entendemos que pueden existir razones de tipo coyunturales para aquello, pero no
nos parece deseable que en el largo plazo la relación de Sistemas con los clientes sea
intermediada. Métricas: - Número de proyectos donde los beneficios establecidos no se lograron debido a suposiciones
de factibilidad incorrectas
- Porcentaje de estudios de factibilidad autorizados por el dueño del proceso
- Porcentaje de usuarios satisfechos con la funcionalidad entregada
Fundamentación:
La necesidad de una nueva aplicación o función debe surgir desde un análisis de impacto o
valor agregado (plan). Una vez aprobado el proyecto, debe existir un segundo análisis de
alternativas que asegure que los requisitos del negocio se satisfacen con un enfoque efectivo y
eficiente. Este proceso cubre la definición de las necesidades, considera las fuentes
alternativas, realiza una revisión de la factibilidad tecnológica y económica, ejecuta un análisis
de riesgo y de costo-beneficio y concluye con una decisión final de “desarrollar” o “comprar”.
Todos estos pasos permiten a las organizaciones minimizar el costo para Adquirir e
Implementar soluciones, mientras que al mismo tiempo facilitan el
logro de los objetivos del negocio.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 28 de 55
Junio 2013
AI2 – Adquisición y mantenimiento de aplicaciones: Diseño, controles sobre la seguridad,
desarrollo, configuración, verificación de la calidad, mantenimiento.
Situación actual BCN:
Estado: repetible
Frente a cualquier nuevo proyecto, se toma la decisión de hacerlo con recursos internos o
contratarlo dependiendo de la envergadura del proyecto y de la disponibilidad de recursos.
La política al respecto no es del todo clara.
En todos los casos, BCN se queda con el know-how, y es responsable de la mantención y
operación de la solución. No se contempla una modalidad de contratación de Software
como Servicio.
Desde el punto de vista operativo, se realiza una licitación a través de Chilecompras, en
dos modalidades: a) se licita el análisis y la construcción por separado; b) se contratan HH
por convenio marco y se dirige el proyecto desde la BCN.
Se están estandarizando los contratos, pero aún hay gran desorden entre DAF y Sistemas en
relación a quién elabora los contratos, quién les hace seguimiento, quién decide si se cobra
una boleta de garantía, etc. Al licitar se anexan las políticas disponibles. No se piden
certificaciones de calidad.
En caso de decidir desarrollo interno: - No hay una metodología bien definida de desarrollo. Hay algunas directrices (p.e., separar
capa de datos de capa de aplicaciones)
- Hay arquitectura base, documentada en el año 2005, no actualizada. Sus piezas
principales son Plone, Zope, Python, Postgresql, Varnish, Apache, Java y Oracle
- No hay estándares de documentación de código
- Usan arquitectura SOA: servicios Web documentados para integrar aplicaciones, y
promueven el reuso de componentes, aunque de manera informal. Para ello, realizan
reuniones semanales del equipo de desarrollo.
Herramientas: - Mantis bug-tracker: reporte de incidentes
- Wricke – administración de proyectos
- SVN: manejador de versiones
- Altova: modelamiento UML, XML
- Virtuoso es la base de datos semántica
- "Wing-IDE" para Python
Es preocupante que la contratación del ERP de la BCN no pase por Sistemas. Más aún, la
persona de sistemas que iba a acompañar el proceso, fue contratada por Administración. El
riesgo de esto es que cada área termine armando su propio centro de Sistemas. Entendemos
que el rol de sistemas es apoyar a las áreas en el logro de sus metas administrando el
conjunto de recursos de TI, buscando sinergias, integración y favoreciendo una arquitectura
homogénea.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 29 de 55
Junio 2013
Recomendaciones:
Este es otro proceso crítico que debiese estar documentado.
Se recomienda - Tener políticas definidas en relación a qué se desarrolla internamente y qué se
externaliza.
- Contar con un modelo de trabajo bien definido que integre las áreas funcionales y
Sistemas en un equipo con roles claros. Por ejemplo, crear un directorio de proyecto,
definir un Gerente de proyecto funcional y un Jefe de Proyecto de Sistemas, etc (ver
informe 2)
- Contar con bases de licitación estandarizadas, incluyendo anexos técnicos que definen la
arquitectura, políticas y modelos de interoperabilidad.
- Contar con un procedimiento definido para ser contraparte de empresas desarrolladoras
externas.
- Se recomienda revisar con urgencia el modelo de implementación del ERP. En nuestra
opinión, debe estar en manos de Sistemas
Métricas: • Número de problemas en producción por aplicación, que causan tiempo perdido
significativo
• Porcentaje de usuarios satisfechos con la funcionalidad entregada
Fundamentación
Las aplicaciones deben estar disponibles de acuerdo con los requerimientos del negocio.
Este proceso cubre el diseño de las aplicaciones, la inclusión apropiada de controles
aplicativos y requerimientos de seguridad, y el desarrollo y la configuración en sí de
acuerdo a los estándares. Esto permite a las organizaciones apoyar la operatividad del
negocio de forma apropiada con las aplicaciones automatizadas correctas
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 30 de 55
Junio 2013
AI3 – Adquisición y mantenimiento de la infraestructura tecnológica: Plan de
infraestructuras, controles de protección y disponibilidad, mantenimiento.
Situación actual BCN:
Estado: Repetible
La infraestructura se planifica para el año. Los criterios principales son los de
obsolescencia para equipos menores, y requerimientos de escalabilidad. Se compra a través
de licitaciones o convenios marco de Chilecompras. Durante el año, hay contingencias que
obligan a disponer de un presupuesto reservado para esos fines.
Por política, compran equipamiento, no lo arriendan, aunque les gustaría hacerlo.
En este concepto es donde se presentan los principales problemas con la ejecución
presupuestaria, movilidad entre cuentas etc.
Datacenter: las instalaciones tienen controles precarios, la situación de la BCN en este
ámbito es de riesgo; la razón para no externalizarlo es principalmente de costos (muchos
costos actuales están subvencionados). La sala no cumple con los estándares de datacenter,
tiene problemas de temperatura, humedad, alimentación eléctrica. Están a la espera de
construir una nueva sala de servidores. Además, visualizan disponer de una segunda sala de
respaldo y una cintoteca, en el nuevo edificio de Catedral, respaldándose mutuamente.
Actualmente no tienen un site de contingencia.
Enlaces de comunicaciones: tienen una conexión de la empresa GTD entre Valparaíso y
Santiago. La conexión hacia afuera (Internet) está contratada a Claro. No están conectados
dentro del Congreso con las Cámaras. Los Parlamentarios y sus asesores acceden a los
servicios de la BCN a través de Internet.
Recomendaciones:
Recomendamos documentar las políticas relacionadas con la plataforma.
Recomendamos además: - Revisar el modelo de aprovisionamiento del equipamiento computacional menor; evaluar
la contratación de un servicio integral de arriendo con disponibilidad garantizada por el
proveedor. Esto permite concentrar los esfuerzos en los aspectos core del negocio
- Revisar los costos asociados a externalizar el datacenter (TIER 3), incluyendo servicios de
administración básica de la infraestructura. A la BCN le conviene disponer de un datacenter
seguro y confiable, aunque eso signifique algunos recursos adicionales. Además, con la
oferta de “cloud computing”, los costos se hacen significativamente más atractivos.
Fundamentación:
La plataforma tecnológica determina los grados de libertad para implementar la estrategia de
negocios. La plataforma tecnológica agrupa al conjunto de componentes que, actuando
juntos, crean un ambiente propicio para la ejecución de las aplicaciones y por ende, el
desarrollo del negocio. Constituyen una fundación, y como tal, debe ser sólida.
La plataforma es a menudo invisible para los clientes, ellos la usan y esperan que responda
adecuadamente, por lo mismo, a menudo recibe menos atención que las aplicaciones. Sin
embargo, es igual de importante y debe ser planificada y administrada con cuidado.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 31 de 55
Junio 2013
AI4 – Facilidad de uso: Formación a gerencia, usuarios, operadores y personal de soporte.
Situación actual BCN:
Estado: repetible
El rol de capacitar a los usuarios en torno a las aplicaciones recae principalmente en
Arquitectura de la Información. En otras ocasiones son los propios usuarios avanzados los
que capacitan a sus pares.
Sistemas hace algunas capacitaciones en particular aquellas relacionadas con los “sistemas
grandes”; son capacitados los usuarios, la mesa de ayuda y Arquitectura que muchas
veces replica esta capacitación.
No existe un “manual de capacitadores”, que defina qué cosas debe considerar una buena
capacitación, cómo se evalúa su calidad e impactos posteriores.
Pocas aplicaciones tienen una ayuda en línea, y si lo tienen es un pdf.
Soporte detecta a menudo necesidades de capacitación y aprovechando los espacios de
contacto con los usuarios, hace pequeñas capacitaciones (fueron entrenados para eso), pero
esto no funciona del todo bien en opinión de algunos entrevistados.
No hay un programa de formación especial para los directivos.
Recomendaciones:
Se recomienda diseñar un programa especial de formación de “liderazgo tecnológico” para
los directivos.
Se recomienda diseñar un “manual de capacitadores” que defina con precisión aspectos de
didáctica y también de evaluación de la calidad e impacto de las capacitaciones realizadas.
Se recomienda desarrollar ayudas en línea y/o tutoriales para las principales aplicaciones.
Estos temas debiesen trabajarse con Desarrollo de las Personas. Métricas:
- El porcentaje de dueños de negocios satisfechos con el entrenamiento de aplicación
y los materiales de apoyo.
- El número de aplicaciones que cuentan con un adecuado entrenamiento de apoyo al
usuario y a la operación
Fundamentación:
Una buena capacitación acelera el ciclo de apropiación de la tecnología, reduce la cantidad
de llamados a soporte, los incidentes de seguridad, mejora la calidad del servicio prestado a
los clientes y permite también que se especifiquen y diseñen mejores aplicaciones.
Asimismo, el conocimiento sobre los nuevos sistemas debe estar disponible. Este proceso
requiere la generación de documentación y manuales para usuarios y para TI.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 32 de 55
Junio 2013
AI5 – Obtención de recursos tecnológicos: control y asignación de los recursos disponibles,
gestión de contratos con proveedores, procedimientos de selección de proveedores.
Situación actual BCN:
Estado:Inicial
Uno de los principales problemas en este ámbito es que las áreas no tienen muchas
restricciones en pedir ya que TI es un centro de costo, y existe una sensación de que los
usuarios piden más de lo que necesitan.
No hay políticas de rotación de equipos. En general, se cambian los equipos obsoletos
(más de 4 años para notebooks).
El parque de PCs es variado, aunque han estado intentando estandarizar.
Existe un inventario de equipos.
Para los equipos menores, el proceso es aproximadamente el siguiente: TI licita, la DAF
recibe e inventaría los equipos (les pone etiqueta), con ese número asignado TI los ingresa
al sistema informático KBox y los configura a partir de discos imágenes. Los incidentes
sobre el equipo se registran en ese sistema Kbox.
Herramientas: - KBox permite un gestión del inventario de equipos (PCs, impresoras, palms,…), tiene
funcionalidades interesantes como diseminar parches e instalar aplicaciones. Se tiene la
percepción de que no se le ha sacado todo el provecho a esta herramienta.
Los servidores están inventariados en otro sistema.
El áreas de TI gestiona las garantías.
Tienen un registro de proveedores muy rudimentario (Excel), no utilizan el registro de
proveedores de Chilecompras.
Recomendaciones: - Diseñar un mecanismo que permita regular la demanda
- Definir un procedimiento para la renovación/rotación de equipos, en que el criterio
mandatorio tenga relación con las necesidades.
- Sacar el máximo provecho a la herramienta KBox
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 33 de 55
Junio 2013
AI6 – Controles de cambios: Procedimientos de solicitud/autorización de cambios,
verificación del impacto y priorización, cambios de emergencia, seguimiento de los
cambios, actualización de documentos.
Situación actual BCN:
Estado: Repetible
Las áreas de Arquitectura y de Ingeniería y Desarrollo capturan los requerimientos de
mantenciones perfectivas/correctivas. Hay muchas peticiones de cambios y
permanentemente se negocian. No hay un proceso definido que establezca criterios para la
priorización de las solicitudes de cambio, y luego trazabilidad completa de éstos, que
asegure que los cambios se reflejen en las diferentes documentaciones del sistema. Cuando
hay empresas externas involucradas, se hace un seguimiento más detallado de los cambios.
La herramienta que se usa para registrar las solicitudes de cambios es Google Docs.
Los cambios solicitados a la sección de Ingeniería y Desarrollo quedan registrados en
Redmine, que es complementaria al uso de Wrike (http://redmine.bcn.cl).
Respecto de la actualización de parches de las plataformas, se evalúa la conveniencia, se
hace un laboratorio y prueba, y, si todo está conforme, se implementa.
Recomendaciones:
Se recomienda formalizar el proceso, documentarlo y medirlo.
También se recomienda explorar una herramienta que permita hacer trazabilidad de los
cambios. Métricas:
- Porcentaje de Requerimientos de cambios aceptados y aprobados.
- Número de cambios realizados clasificados por impacto y prioridad y filtrados
temporalmente.
- Tiempo medio del cambio dependiendo del impacto y la prioridad
Fundamentación:
Las principales razones para la realización de cambios son:
- Solución de errores conocidos.
- Desarrollo de nuevos funcionalidades/servicios.
- Mejora de las funcionalidades/servicios existentes.
- Imperativo legal.
El principal objetivo de la Gestión de Cambios es la evaluación y planificación del proceso
de cambio para asegurar que, si éste se lleva a cabo, se haga de la forma más eficiente,
siguiendo los procedimientos establecidos y asegurando en todo momento la calidad y
continuidad del servicio TI.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 34 de 55
Junio 2013
AI7 – Instalación y acreditación de soluciones y cambios: Formación, pruebas técnicas y de
usuario, conversiones de datos, test de aceptación por el cliente, traspaso a producción.
Situación actual BCN:
Estado: repetible
Existe un proceso definido (no documentado) para paso a producción de los proyectos
grandes. No ocurre lo mismo con los otros proyectos. Sin embargo, el proceso tiene serias
falencias. La delimitación de responsabilidades entre Operaciones y las áreas de Proyectos
e Ingeniería en el proceso no es clara. Estas últimas no se desligan de los aspectos
operativos, una vez que entran en producción las aplicaciones, y siguen soportando la
operación, con lo cual la responsabilidad frente a un problema se diluye. El área de
operaciones no establece un “procedimiento de aceptación” de las aplicaciones antes de
subirlas a producción. No siempre las aplicaciones están documentadas.
También hay una zona gris entre Sistemas y Arquitectura en relación a la aceptación por
parte del cliente.
Actualmente, Proyectos/Ingeniería capacitan a las personas que darán soporte, se definen
los procedimientos de respaldos, monitoreo, claves de acceso, etc..
Los ambientes de desarrollo, testing y producción están segregados, lo que es una buena
práctica.
Habitualmente, la carga inicial de datos la hace Proyectos/Ingeniería, a pesar de que
debiese ser responsabilidad del área de contenidos
Una vez puesto en producción, Arquitectura monitorea y evalúa el uso de las aplicaciones,
tasa de problemas etc.
Herramientas: Se usa el SVN: Subversion como manejador de versiones
Recomendaciones:
Recomendamos formalizar y documentar el procedimiento de paso a producción, el cual
debe considerar condiciones mínimas, como el test de aceptación por parte de operaciones,
definición de SLAs etc. Idealmente, operaciones debiese tomar el control de la aplicación,
una vez aceptada. Métricas
- Tiempo perdido de la aplicación o problemas de datos provocados por pruebas
Inadecuadas
- Porcentaje de sistemas que satisfacen los beneficios esperados, medidos en el
proceso posterior a la implantación
- Porcentaje de proyectos con plan de prueba documentado y aprobado
Fundamentación:
Los nuevos sistemas necesitan estar funcionales una vez que su desarrollo se completa.
Esto requiere pruebas adecuadas en un ambiente dedicado con datos de prueba
relevantes, definir la transición e instrucciones de migración, planear la liberación y la
transición en sí al ambiente de producción, y revisar la post-implantación. Esto garantiza
que los sistemas operativos estén en línea con las expectativas convenidas y con los
resultados.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 35 de 55
Junio 2013
Es posible identificar relaciones entre los procesos de este apartado con los presentados por el
estándar ISO 122079:
Cobit ISO 12207
AI1 – Identificación de soluciones 5.1 Adquisición
AI2 – Adquisición y mantenimiento de
aplicaciones
5.1 Adquisición, 5.2 Suministro, 5.3 Desarrollo, 5.5
Mantenimiento, 6.2 Gestión de configuraciones
AI3 – Adquisición y mantenimiento de la
infraestructura tecnológica
5.1 Adquisición, 5.2 Suministro, 5.5 Mantenimiento, 7.2
Infraestructura
AI4 – Facilidad de uso 6.1 Documentación, 6.8 Resolución de problemas, 7.1
Gerencia, 7.4 Formación
AI5 – Obtención de recursos
tecnológicos 7.2 Infraestructuras
AI6 – Gestión de cambios 5.2 Suministro, 5.5 Mantenimiento, 7.3 Mejoras
AI7 – Instalación y acreditación de
soluciones y cambios
6.3 Verificación de la calidad, 6.4 Verificación, 6.5
Validación, 6.6 Integración, 6.7 Auditoría
Como soporte a los procesos de este apartado es posible utilizar metodologías de desarrollo y
modelos de capacidad como ISO 15504 y CMMI10
.
9 http://www.marblestation.com/blog/?p=644
10 http://www.marblestation.com/blog/?p=644
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 36 de 55
Junio 2013
5.3. Dominio Entrega y Soporte
La entrega y soporte de servicios se encuentran constituidos por diversos procesos orientados a
asegurar la eficacia y eficiencia de los sistemas de información. El estándar COBIT ha definido 13
procesos diferentes:
DS1 – Definición y gestión de los niveles de servicio (SLA) con usuarios/clientes
Situación actual BCN:
Este proceso no está instalado en la BCN. No hay acuerdos de niveles de servicio con las
áreas clientes ni con la BCN para las aplicaciones en producción. La falta de estos
acuerdos genera expectativas que no reflejan la realidad y pueden significar frustraciones
(p.e. que los sistemas y sus soportes tienen que funcionar 24x7) .
La periodicidad de los respaldos está definida (son automatizados) y el proceso de
recuperación de los datos ha sido probado.
Tampoco hay SLAs para soporte del equipamiento menor o para los servicios de
impresión. En cambio, se miden los tiempos y tareas realizadas y solicitudes cerradas, así
como la calificación del usuario a la atención del problema. Esto último, sólo en el caso
que a la solicitud le haya sido asignado un ticket (lo que no siempre ocurre)
Recomendaciones:
Es fundamental implementar este proceso y aclarar cuáles son los niveles de servicio que
se requieren y que se entregarán. Los SLAs, en particular aspectos tales como
disponibilidad, seguridad, soporte, confiabilidad, deben formar parte de las metas del
Departamento de Sistemas. De lo contrario, se producen malos entendidos y frustración.
Métricas:
El cumplimiento de los SLAs medidos
El porcentaje de Interesados satisfechos de que la entrega del servicio cumple con los
niveles previamente acordados
El número de servicios entregados que no están en el catálogo
El número de reuniones formales de revisión del Acuerdo de Niveles de Servicio (SLA) con
las personas de negocio por año
Fundamentación:
Contar con una definición documentada y un acuerdo de servicios de TI y de niveles de
servicio, hace posible una comunicación efectiva entre la gerencia de TI y los clientes de
negocio respecto de los servicios requeridos. Este proceso también incluye el monitoreo y
la notificación oportuna a los Interesados sobre el cumplimiento de los niveles de servicio.
Este proceso permite la alineación entre los servicios de TI y los requerimientos de negocio
relacionados.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 37 de 55
Junio 2013
DS2 – Gestión de servicios de terceros: gestión de las relaciones con proveedores, valoración del
riesgo (confidencialidad, Non-disclosure agreement - NDA), monitorización del servicio.
Situación actual BCN:
Se tienen contratos tipo para desarrollos, que incluyen NDA, propiedad intelectual etc. Son
algo antiguos y al Departamento de Sistemas le falta apoyo para revisar sistemáticamente
los contratos.
En los contratos con terceros se establecen SLAs que consideran multas ante
incumplimientos (p.e., contrato con empresa GTD que provee enlace inter-sedes). Sin
embargo, no maneja SLAs con proveedores internos de servicios tales como climatización
o energía de la sala de máquinas.
Los PCs se compran con 3 años de garantía, se manejan equipos de reemplazo y repuestos.
Todo el equipamiento crítico está respaldado con contratos de mantención (p.e., servidores
con Adexus).
Hasta ahora no han contratado en modalidad “software como servicio” (SaaS) e incluso
operación de terceros de los sistemas. La primera experiencia será con la empresa Browse,
contrato en el que Sistemas no va a tener ninguna injerencia.
Recomendaciones:
Recomendamos normar y documentar el procedimiento de “gestión de servicios de
terceros” y capacitar a quiénes tienen la responsabilidad de administrar esos contratos.
Adicionalmente, recomendamos llevar un registro de proveedores.
También recomendamos una mejor coordinación de Sistemas con el equipo jurídico de la
BCN para la revisión de los formatos tipo de contratos y también para la revisión caso a
caso de los contratos, en particular en aquellas cláusulas que fijan los niveles de servicio,
acuerdos de confidencialidad etc.
Finalmente, recomendamos que la BCN se abra a evaluar nuevas modalidades de
contratación (SaaS, outsourcing de PCs etc.).
Métricas: • El número de quejas de los usuarios debidas a los servicios contratados
• El porcentaje de los principales proveedores que cumplen claramente los requerimientos
definidos y los niveles de servicio
• El porcentaje de los principales proveedores sujetos a monitoreo
Fundamentación:
La necesidad de asegurar que los servicios provistos por terceros cumplan con los
requerimientos del negocio, requiere de un proceso efectivo de administración de terceros.
Este proceso se logra por medio de una clara definición de roles, responsabilidades y
expectativas en los acuerdos con los terceros, así como con la revisión y monitoreo de la
efectividad y cumplimiento de dichos acuerdos. Una efectiva administración de los
servicios de terceros minimiza los riesgos del negocio asociados con proveedores que no se
desempeñan de forma adecuada.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 38 de 55
Junio 2013
DS3 – Gestión del rendimiento y la capacidad: planes de capacidad, monitorización del
rendimiento, disponibilidad de recursos.
Situación actual BCN:
No hay en la BCN un proceso formal de planificación de la capacidad (“capacity planning”
es el proceso para determinar la capacidad que tiene una compañía para afrontar el
crecimiento en la demanda de sus productos; habitualmente se simula la carga esperada de
las aplicaciones, y se dimensiona la plataforma requerida). No obstante ello, se hace una
planificación anual de la infraestructura.
La BCN monitorea el desempeño de la infraestructura y aplicaciones, y cuando se llega a
umbrales, se gatillan alarmas via correo. La utilización del software de monitoreo permite
realizar mantenciones preventivas (por ej: limpieza/borrado para evitar llenado de disco o
asignación de espacio adicional para Base de Datos)
El Departamento de Sistemas tiene planificado a contratar monitoreo externo para ver
tiempos de descarga de páginas (se evalúa la herramienta monitis.com). Herramientas: - Nagios para el monitoreo de los signos vitales de los equipos y disponibilidad de las
aplicaciones. Se monitorea:
o Servidores: Utilización Espacio disco, disponibilidad (ping), estado de hardware,
ejecución de aplicaciones, uso de CPU,
o Bases de datos: disponibilidad, utilización espacio disco
o Switches: disponibilidad (ping)
o Access Point: disponibilidad (ping)
o Disponibilidad de servicios: web, FTP, bases de datos, puertos específicos,
directorios montados vía NFS.
- Virtual Center: administración de la plataforma virtual de la BCN. Actualmente está
configurada solamente para alertar el consumo excesivo de CPU de la máquina virtual.
- Software storage Hitachi (Hi-Track): Software propietario de Hitachi que monitorea estado
de storage, enviando alertas cuando el sistema se encuentra con problemas.
- Software administración Blade: Software propietario de HP que monitorea estado del
chassis blade y sus hojas (servidores), enviando alertas cuando encuentra problemas.
La BCN ha hecho esfuerzos por contar con una infraestructura escalable (basada en
servidores blade, virtualización, unidades de storage compartido para almacenamiento). Sin
embargo, no hay asignación dinámica de recursos
Recomendaciones:
Recomendamos realizar anualmente un “capacity planning” y, a partir de sus resultados,
elaborar un plan de acciones que podría hacer replantarse la arquitectura de la plataforma,
o realizar una inversión en la plataforma de producción, entre otros. El proceso requiere
como entrada, la definición de SLAs. Existe información histórica que puede ser
aprovechada para estos fines.
Recomendamos seguir monitoreando el desempeño y signos vitales de los equipos, con el
software de monitoreo. Esta es una buena práctica
Fundamentación:
El capacity planning permite conocer cuáles son los riesgos reales de la plataforma TI y
cómo dichos riesgos impactan en el negocio.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 39 de 55
Junio 2013
DS4 – Asegurar la continuidad del servicio: plan de continuidad, recursos críticos,
recuperación de servicios, copias de seguridad.
Situación actual BCN:
Existe un proceso formal para asegurar la continuidad de servicio para Ley Chile; forma
parte de la certificación ISO de ese proceso.
Sin embargo, no existe un proceso de este tipo para las otras aplicaciones.
La BCN tienen procedimientos de respaldos, se han hecho simulaciones de restauración y
han funcionado.
Comunicaciones: cuando se cae GTD (proveedor del enlace entre Santiago y Valparaíso),
los usuarios de la BCN pueden entrar a los sistemas a través de Internet. Si se cae Claro
(proveedor de Internet), los usuarios de la BCN mantienen la conexión entre ellos, no así
los usuarios que acceden desde fuera, p.e., los Parlamentarios.
Frente a un corte de energía, la UPS da un margen de 10 minutos para hacer una bajada
ordenada de los servidores.
Recomendaciones:
Recomendamos identificar los procesos/sistemas críticos y definir para cada uno de ellos
un plan de continuidad del servicio.Métricas: • Número de horas perdidas por usuario por mes, debidas a interrupciones no planeadas
• Número de procesos críticos de negocio que dependen de TI, que no están cubiertos por
un plan de continuidad
Fundamentación:
La necesidad de brindar continuidad en los servicios de TI requiere desarrollar, mantener y
probar planes de continuidad de TI, almacenar respaldos fuera de las instalaciones y
entrenar de forma periódica sobre los planes de continuidad. Un proceso efectivo de
continuidad de servicios, minimiza la probabilidad y el impacto de interrupciones mayores
en los servicios de TI, sobre funciones y procesos claves del negocio.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 40 de 55
Junio 2013
DS5 – Garantizar la seguridad de los sistemas: gestión de identidades, gestión de usuarios,
monitorización y test de seguridad, protecciones de seguridad, prevención y corrección de
software malicioso, seguridad de la red, intercambio de datos sensibles.
Situación actual BCN:
La política de seguridad se implementa en el entramado de firewalls, antispam, antivirus, y
sistemas de detección de intrusos que conforman la plataforma tecnológica. La BCN no ha
tenido incidentes de seguridad relevantes, en cambio se han detectado intentos de intrusión.
Las políticas de claves son débiles. Sólo se monitorea que las claves no sean el nombre de
las personas. Ante 3 intentos fallidos se bloquean las cuentas.
Este año implementará Active Directory con single sign-on, es decir, los usuarios serán
validados contra un Directorio, y sólo tendrán que ingresar una única password para
acceder a todos los sistemas a los que tienen derecho de acceder.
La sala de máquinas tiene estándares bajos de seguridad.
Recomendaciones:
Creemos que la administración de la seguridad y las medidas que está tomando la BCN son
adecuadas, sin embargo, es importante formalizar este proceso.
Es también importante realizar regularmente un monitoreo de la seguridad (tipo hacking
ético) e implementar las recomendaciones que de allí surjan.
Fundamentación:
La política de seguridad de la BCN apunta a proteger la alteración/modificación de la
información, así como a garantizar la continuidad del servicio, no así la confidencialidad,
ya que la BCN considera que toda su información es pública.
No obstante ello, la gravedad de que información de las bases de datos pueda ser alterada,
tanto por las consecuencias que ello pudiese tener en el proceso legislativo, como también
por el daño de imagen que pudiese sufrir la propia biblioteca, obligan a extremar la
implementación de las medidas de seguridad que derivan de la política.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 41 de 55
Junio 2013
DS6 – Identificar y asignar costos
Situación actual BCN:
En Sistemas, no hay un proceso de asignación de costos a productos/servicios.
Actualmente, es muy difícil saber cuánto cuesta construir y luego operar los diferentes
productos o servicios informáticos.
El Departamento de Sistemas lleva presupuestos por proyectos, pero no se prorratean los
costos indirectos.
Recomendaciones:
Nuestra recomendación es implementar un proceso que permita llevar una contabilidad por
centros de costo y por proyecto. Posiblemente, la adquisición de un ERP facilite esta
medida.
Fundamentación:
Una forma de saber qué tan eficiente es la BCN en la gestión de sus recursos informáticos
es a través del benchmarking de costos. Si los costos internos son superiores a la de los
proveedores externos, hay que revisar lo que se está haciendo. Si son inferiores, se puede
tener algún nivel de tranquilidad, a menos que el servicio sea mal evaluado por los clientes.
La asignación de costos permite también crear conciencia en los clientes internos, de que
pedir recursos informáticos tiene costo para la BCN.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 42 de 55
Junio 2013
DS7 – Formación a usuarios: identificar necesidades, planes de formación.
Situación actual BCN:
No existe un proceso de evaluación de las competencias digitales de los trabajadores de la
BCN. El Departamento de Sistemas no participa del diseño de los “planes de
capacitación” que realiza RRHH. La formación es de acuerdo a la demanda, pero no hay
planes construidos basados en un análisis de brechas. A menudo, la detección de las
brechas las realiza la gente de soporte. Tampoco se mide el impacto de la capacitación.
Recomendaciones:
Se sugiere establecer un estándar mínimo de competencias digitales para todo el personal
que labora en la BCN y realizar un diagnóstico y análisis de brechas. Para cerrar las
brechas, se recomienda elaborar/adquirir un curso de alfabetización digital, que incorpore
también la difusión de las principales herramientas tecnológicas de la Biblioteca y de los
derechos y deberes de los usuarios informáticos. Este curso de inducción/nivelación podría
ser full e-learning y formar parte del proceso de inducción a la BCN. Debe permitir una
evaluación de los aprendizajes.
Además, deberían proveerse capacitaciones específicas orientadas a quienes generan
contenido visible desde Internet y que generan URL tanto de páginas como de documentos,
audios, videos e imágenes, para asegurar el cumplimiento de estándares y políticas de
publicación.
Métricas:
Número de llamadas de soporte debido a problemas de entrenamiento
Porcentaje de satisfacción de los Interesados con el entrenamiento recibido
Lapso de tiempo entre la identificación de la necesidad de entrenamiento y la
impartición del mismo
Fundamentación:
Dada la importancia de las TI en la BCN, se requiere que cualquier persona que trabaje en
ella tenga un piso de destrezas en el uso de la tecnología, algo así como una “licencia de
manejar” computadores.
Un programa efectivo de entrenamiento incrementa el uso efectivo de la tecnología al
disminuir los errores, incrementando la productividad y el cumplimiento de los controles
clave tales como las medidas de seguridad de los usuarios.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 43 de 55
Junio 2013
DS8 – Gestión de incidentes y Help Desk: registro y escalado de incidencias, análisis de
tendencias.
Situación actual BCN:
Este proceso existe, está estructurado; aún cuando no tuvimos evidencia de que estuviese
documentado. Se está empezando a medir y a estructurar la información que se obtiene en
este proceso.
Se gestionan los incidentes, sin embargo, la clasificación de éstos es insuficiente para hacer
una gestión que vaya más allá de la casuística.
Hay escalamiento en la atención de los incidentes, pero las personas que desempeñan la
función de segundo nivel y a las que se les derivan los casos que no pueden ser resueltos en
el primer nivel, no son usuarios del “workflow”, por lo tanto no tienen alarmas, ni pueden
registrar lo que hacen. Son los analistas de la mesa de ayuda los responsables de cerrar, y
para eso deben “perseguir” al segundo nivel.
La mesa de ayuda tiene 3 canales de acceso: a través de un sistema, un llamado telefónico
o correo. No todos los llamados derivan en un ticket.
Al término de la atención, las personas evalúan el servicio.
Herramienta: Kbox es el sistema de atención/workflow de la mesa de ayuda.
Recomendaciones:
Recomendamos documentar el proceso, y definir una buena taxonomía/clasificación de
incidentes, para luego poder hacer gestión de problemas y resolver estructuralmente lo
que la mesa de ayuda resuelve caso a caso. Métricas:
Satisfacción del usuario con el soporte de primera línea
Porcentaje de incidentes resueltos dentro de un lapso de tiempo aceptable / acordado.
Índice de abandono de llamadas
Fundamentación:
Responder de manera oportuna y efectiva a las consultas y problemas de los usuarios de TI,
requiere de una mesa de servicio bien diseñada y bien ejecutada, y de un proceso de
administración de incidentes. Este proceso incluye la creación de una función de mesa de
servicio con registro, escalamiento de incidentes, análisis de tendencia, análisis causa/raíz y
resolución. Los beneficios del negocio incluyen el incremento en la productividad gracias a
la resolución rápida de consultas. Además, el negocio puede identificar la causa raíz (tales
como un pobre entrenamiento a los usuarios) a través de un proceso de reporte efectivo.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 44 de 55
Junio 2013
DS9 – Gestión de configuraciones: definición de configuraciones base, análisis de integridad
de configuraciones.
Situación actual BCN:
A nivel de estaciones de trabajo, se utiliza un sistema (Kbox) para llevar un registro de las
configuraciones; se actualiza remotamente. Kbox detecta la configuración, los programas
que están corriendo, licencias etc. Desde el punto de vista de carga/restitución de la
configuración, se hace con disco imagen y es el que se instala.
Respecto de los servidores, el área de operaciones lleva un registro de las configuraciones
en una planilla (tanto a nivel de hardware como de los servidores virtualizados)
Recomendaciones:
El proceso nos parece adecuado, se podría tal vez sacar más provecho a la herramienta.
Recomendamos documentar el proceso. Métricas:
El número de problemas de cumplimiento del negocio debido a inadecuada configuración
de los activos.
El número de desviaciones identificadas entre el repositorio de configuración y la
configuración actual de los activos.
Porcentaje de licencias compradas y no registradas en el repositorio
Fundamentación:
Garantizar la integridad de las configuraciones de hardware y software requiere establecer
y mantener un repositorio de configuraciones completo y preciso. Este proceso incluye la
recolección de información de la configuración inicial, el establecimiento de normas, la
verificación y auditoría de la información de la configuración y la actualización del
repositorio de configuración conforme se necesite. Una efectiva administración de la
configuración facilita una mayor disponibilidad, minimiza los problemas de producción y
resuelve los problemas más rápido.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 45 de 55
Junio 2013
DS10 – Gestión de problemas: identificación y clasificación, seguimiento, integración con la
gestión de incidentes y configuraciones.
Situación actual BCN:
No existe un proceso formal de gestión de problemas.
Recomendaciones:
Recomendamos implementar este proceso. Una efectiva administración de problemas
requiere la identificación y clasificación de problemas, el análisis de las causas desde su
raíz, y la resolución de éstas. El proceso de administración de problemas también incluye la
identificación de recomendaciones para la mejora, el mantenimiento de registros de
problemas y la revisión del estatus de las acciones correctivas. Métricas:
Número de problemas recurrentes con impacto en el negocio
Porcentaje de problemas resueltos dentro del período de tiempo solicitado
Frecuencia de los reportes o actualizaciones sobre un problema en curso, con base en la
severidad del problema
Fundamentación:
Un efectivo proceso de administración de problemas mejora los niveles de servicio, reduce
costos y mejora la conveniencia y satisfacción del usuario.
En particular, una buena gestión de problemas debe traducirse en una:
Disminución del número de incidentes y una más rápida resolución de los mismos.
Mayor eficacia en la resolución de problemas.
Gestión proactiva, que permita identificar problemas potenciales antes de que éstos
se manifiesten o provoquen una seria degradación de la calidad del servicio.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 46 de 55
Junio 2013
DS11 – Gestión de los datos: acuerdos para la retención y almacenaje de los datos, copias de
seguridad, pruebas de recuperación.
Situación actual BCN:
Las validaciones a la entrada de datos para asegurar la calidad del registro, no son
responsabilidad de Sistemas, sino que de las áreas de contenidos. Sistemas sólo participa en
la construcción de las reglas de validación embebidas en el código de la aplicación.
Los servidores comparten una unidad de almacenamiento (storage)
Respaldo de datos: 1. Almacenamiento de cintas en Valparaíso: El almacenamiento de cintas las cuales contiene
respaldo de datos de servidores, bases de datos, máquinas virtuales y archivos de
usuarios, se realiza en mueble metálico con llave ubicado en sala de servidores 5º Piso.
2. Almacenamiento de cintas en Santiago: El almacenamiento de cintas las cuales contiene
copia de respaldo de datos de servidores, bases de datos y máquinas virtuales, se realiza
en mueble ubicado en ofician de soporte (Huérfanos)
3. Consistencia de respaldos: Al finalizar cada respaldo de datos de servidores, bases de
datos, máquinas virtuales y archivos de usuarios, se realiza chequeo de cinta bajo
modalidad revisión/lectura de header de cada archivo de la cinta, es decir, si el header del
archivo puede ser leído por el software de respaldo éste asume que la data es segura, en
caso contrario, la información del error queda almacenada en el log de la actividad de
respaldo. Al finalizar chequeo de la cinta de respaldo, el servidor donde se está ejecutando
el respaldo de los datos, envía correo electrónico con resultado de respaldo de datos y su
verificación.
4. Rotulación de cintas: Las cintas que contienen respaldos y que son almacenadas tanto en
Valparaíso como en Santiago, se anota el contenido del respaldo en la hoja que se
encuentra en la caja de la cinta. Además cada cinta posee un código de barra.
Recuperación de datos 1. No existe una política de recuperación de datos ni de pruebas. En promedio, han tenido
que hacer 2 recuperaciones parciales de datos por año, a pedido de clientes (usuarios).
Recomendaciones: Formalizar y documentar el proceso
Métricas:
Satisfacción del usuario con la disponibilidad de los datos.
Porcentaje de restauraciones exitosas de datos.
Número de incidentes en los que tuvo que recuperarse datos sensitivos después que los
medios habían sido desechados
Fundamentación:
Este proceso tiene por objetivo asegurar que los datos permanezcan completos, precisos y
válidos durante su entrada, actualización, salida y almacenamiento.
Sistemas debe asegurar la integridad, autenticidad y confidencialidad de los datos
almacenados, definiendo e implementando procedimientos para tal fin.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 47 de 55
Junio 2013
DS12 – Gestión del entorno físico: acceso físico, medidas de seguridad, medidas de
protección medioambientales.
Situación actual BCN:
La seguridad del datacenter es muy débil. La sala es compartida con el Senado. Se entra
con una tarjeta de identificación. La cámara filmadora no está operativa. Es cierto que el
edificio del Congreso tiene medidas de seguridad superiores a las de la mayoría de los
edificios, pero eso no es suficiente.
Se mide la temperatura y humedad de la sala, y hay alarmas que gatillan correos. Se
analiza el consumo eléctrico.
Recomendaciones:
Evaluar alternativas tales como traslado a un datacenter TIER 3, aunque esto tenga costos
adicionales. De lo contrario, cambiarse a una sala distinta a la actual y reforzar las medidas
de seguridad. Los activos TI de la BCN son demasiado importantes como para estar
expuestos a este nivel de riesgo.
Fundamentación:
El objetivo es proporcionar un ambiente físico conveniente que proteja al equipo y al
personal de TI contra peligros naturales (fuego, polvo, calor excesivos) o fallas humanas lo
cual se hace posible con la instalación de controles físicos y ambientales adecuados que
sean revisados regularmente para su funcionamiento apropiado definiendo procedimientos
que provean control de acceso del personal a las instalaciones y contemplen su seguridad
física.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 48 de 55
Junio 2013
DS13 – Gestión de las operaciones: planificación de tareas, mantenimiento preventivo.
Situación actual BCN: No existe una propiamente una planificación de tareas de administración de operaciones. No se realiza mantención preventiva de Hardware. Solamente se realizan mantenciones correctivas de hardware (cambio de partes y piezas en caso de falla). En el caso del software, no parece existir una política muy clara para la instalación de parches
1. La instalación de parches para servidores Linux no se realiza porque afectaría
funcionalidad de sistemas desarrollados. Sólo ante pedido de Desarrollo.
2. La instalación de parches para servidores Vmware se realiza en la medida que exista una
ventana de tiempo y no provoque cortes de servicios en horario de oficina.
3. Los productos de bases de datos Sybase se encuentran con su último nivel de parche, sin
embargo, estos productos se encuentran sin soporte por parte del proveedor debido a su
obsolescencia.
4. La instalación de parches en bases de datos Oracle no se realiza.
5. Mantenciones bases de datos: se realizan chequeo periódicos de logs y ejecución de
chequeo de consistencia y actualizaciones de estadísticas.
Recomendaciones: Formalizar y documentar procedimientos para las operaciones de TI, a través de una calendarización de actividades de soporte que sea registrada y completada en cuanto al logro de todas las actividades. Los procedimientos deberán ser revisados periódicamente para garantizar su eficiencia y cumplimiento
Fundamentación:
El objetivo es asegurar que las funciones importantes de soporte de TI estén siendo
llevadas a cabo regularmente y de una manera ordenada.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 49 de 55
Junio 2013
En general, gran parte de los aspectos descritos se encuentran relacionados con las guías
proporcionadas por ITIL11
(Information Technology Infraestructure Library) y el estándar ISO
20000.
Por otra parte, existen procesos determinados que pueden ser vinculados a otros estándares:
Cobit Relacionado
DS2 – Gestión de servicios de
terceros eSCM-CL Client Organization
12 y eSCM-SP Service Provider
DS4 – Asegurar la
continuidad del servicio
BS 25999-113
(Business Continuity Management) y guías BCI14
(Business Continuity Institute)
DS5 – Garantizar la seguridad
de los sistemas
Open Source Security Tests methodology (OSSTMM)15
y
Information System Security Assessment Framework16
DS6 – Identificar y asignar
costes Activity-Based Costing (ABC)
17
11
http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library 12
http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library 13
http://en.wikipedia.org/wiki/BS_25999 14
http://en.wikipedia.org/wiki/Business_Continuity_Institute 15
http://en.wikipedia.org/wiki/The_Open_Source_Security_Testing_Methodology_Manual 16
http://www.oissg.org/ 17
http://en.wikipedia.org/wiki/Activity-based_costing
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 50 de 55
Junio 2013
5.4. Supervisión y Evaluación
El último dominio se centra en la supervisión de los sistemas con el objetivo de:
Garantizar la alineación con la estrategia del negocio
Verificar las desviaciones en base a los acuerdos de niveles de servicio
Validar el cumplimiento regulatorio
Esta supervisión implica paralelamente la verificación de los controles por parte de auditores
(internos o externos), ofreciendo una visión objetiva de la situación y con independencia del
responsable del proceso.
El estándar Cobit define los siguientes 4 procesos:
ME1 – Monitorización y evaluación del rendimiento
Situación actual BCN:
No existe un convenio de desempeño entre el Departamento de Sistemas y la BCN.
Existen metas, que se asemejan a una lista de actividades esperadas pero están lejos de ser
un instrumento de gestión que permita evaluar el desempeño de la actividad.
El área de gestión de la BCN hace una evaluación de las metas y TI envía un informe con
medios de verificación. Se calcula el porcentaje de cumplimiento.
Se monitorean los signos vitales de los servidores y algunos parámetros de las aplicaciones,
con fines operacionales (p.e., detectar caídas), pero no se utilizan para medir el
rendimiento.
Recomendaciones:
Recomendamos implementar este proceso con urgencia. El convenio de desempeño que se
construya debe considerar indicadores que reflejen cosas tales como valor aportado al
negocio, cumplimientos de SLAs, eficiencia, etc.
Lo que no se mide, no se corrige ni se mejora. Métrica
Satisfacción de la Dirección con los reportes de desempeño
Número de acciones de mejoramiento impulsadas por las actividades de monitoreo
Porcentaje de procesos críticos monitoreados
Fundamentación:
El objetivo es asegurar el logro de los objetivos establecidos para los procesos de TI, lo
cual se logra definiendo por parte de la Dirección reportes e indicadores de desempeño
gerenciales y la implementación de sistemas de soporte así como la atención regular a los
reportes emitidos y la planificación de medidas expeditas cuando existan desviaciones..
El monitoreo se requiere para garantizar que las cosas correctas se hagan y que estén de
acuerdo con el conjunto de direcciones y políticas
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 51 de 55
Junio 2013
ME2 – Monitorización y evaluación del control interno
Situación actual BCN:
Este proceso no ocurre actualmente en la BCN.
Recomendaciones:
Establecer un programa de control interno efectivo para TI, lo que requiere definir e
implementar los controles internos en relación a los principales procesos de gestión de los
recursos informáticos. Este proceso incluye el monitoreo y el reporte de las excepciones de
control, resultados de las auto-evaluaciones y revisiones por parte de terceros.
Medición: • Número de brechas importantes del control interno
• Número de iniciativas para la mejora del control
• Número y cubrimiento de auto evaluaciones de control
Fundamentación:
El objetivo es asegurar el logro de las metas de control interno establecidos para los
procesos de TI. Para ello se debe monitorear la efectividad de los controles internos a
través de actividades administrativas y de supervisión, comparaciones, reconciliaciones y
otras acciones rutinarias, evaluar su efectividad y emitir reportes sobre ellos en forma
regular. Estas actividades de monitoreo continuo deberán revisar la existencia de puntos
vulnerables y problemas de seguridad. Un beneficio clave del monitoreo del control interno
es proporcionar seguridad respecto a las operaciones eficientes y efectivas y el
cumplimiento de las leyes y regulaciones aplicables.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 52 de 55
Junio 2013
ME3 – Asegurar el cumplimiento con requerimientos externos
Situación actual BCN:
Sistemas hace revisión de cumplimientos de SLAs comprometidos por parte de terceros,
pero no existe un proceso formal que da cuenta de aquello.
Jurídica hace revisión de cumplimiento de leyes (p.e., laborales) y normativas.
Recomendaciones:
Recomendamos formalizar el proceso de aseguramiento de cumplimiento de compromisos
de terceros.
Métrica: • El costo del no cumplimiento de TI, incluyendo arreglos y multas
• Tiempo promedio de demora entre la identificación de los problemas externos de
cumplimiento y su resolución
• Frecuencia de revisiones de cumplimiento
Fundamentación:
Una supervisión efectiva del cumplimiento requiere del establecimiento de un proceso de
revisión para garantizar el cumplimiento de las leyes, regulaciones y requerimientos
contractuales de los proveedores. Este proceso incluye la identificación de requerimientos
de cumplimiento, optimizando y evaluando la respuesta, obteniendo aseguramiento que los
requerimientos se han cumplido y, finalmente integrando los reportes de cumplimiento de
TI con el resto del negocio.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 53 de 55
Junio 2013
ME4 – Proveer auditoría independiente
Situación actual BCN:
En la BCN recién se está instalando la función de auditoría. Hasta ahora no se había
realizado una auditoría informática.
Recomendaciones:
Recomendamos implementar este proceso mediante auditorías independientes
desarrolladas a intervalos regulares de tiempo; esto significa que los auditores no deberán
estar relacionados con la sección o departamento que esté siendo auditado. Los auditores
deben ser técnicamente competentes en el tema, de modo de asegurar tareas efectivas y
eficientes de auditoría.
Métricas: • La frecuencia de los reportes de TI hacia el consejo directivo (incluyendo el nivel de
madurez)
• Frecuencia de revisiones independientes del cumplimiento de TI
Fundamentación:
El objetivo de este proceso es incrementar los niveles de confianza y beneficiarse de
recomendaciones basadas en mejores prácticas.
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 54 de 55
Junio 2013
Anexo1: Equipo: Servicios Digitales
I. Metas año 2013
1. Contar con un mínimo de 2.500 tickets ingresados a través de la mesa de ayuda web
2. Disponer de un módulo de Content Management operativo para el Proyecto Historia
de la Ley, que permitirá mejorar el acceso de los parlamentarios a las Historias de la
Ley
3. Disponer de un sistema de noticias BCN potenciado mediante la estandarización de
todos los Archivos provenientes de invesdoc a formato de noticias.bcn.cl, permitiendo
una búsqueda de texto completo
4. Migrar la plataforma de Intranet a Plone 4.2 para mejorar las tareas de edición de
contenidos y tiempos de respuesta
5. Disponer de Active Directory en alta disponibilidad, para single sign on. y de
unificación de: dominio windows, CGP, SSO, SSP, Kbox, Barracuda, para facilitar la
entrada a todos los servicios con una sola contraseña.
II. Metas comprometidas de otras áreas que requieren HH de Servicios Digitales
Meta N° Equipo Detalle Coordinación
vía meta
2.- Disponer de una herramienta informática
para gestionar eficientemente, las funciones de contabilidad de la BCN
DAF Contraparte Técnica
3. Disponer de una
herramienta informática para gestionar eficientemente las funciones de presupuesto
y tesorería.
DAF Contraparte Técnica
4.- Disponer de una
herramienta informática para gestionar eficientemente las funciones de Adquisiciones, Existencias y Activo Fijo
DAF Contraparte Técnica
4. Disponer de 300
nuevos objetos
digitales en el Portal
de HPL para relevar el
aporte histórico del
Congreso Nacional y
HP/AP Ajustes programación Portal
Biblioteca del Congreso Nacional de Chile
Diagnóstico Informático
Organización y procesos de
gestión TI
Página 55 de 55
Junio 2013
Meta N° Equipo Detalle Coordinación
vía meta
sus parlamentarios al
desarrollo político y
legislativo del país 1. Generar aprendizaje a través de los nuevos
estándares de tratamiento de autoridades personales
aplicando RDA y FRAD a 164 registros de senadores y diputados autores
Producción Programación de presentación final
3. Ampliar en 150 títulos el acervo disponible de publicaciones electrónicas (anuarios y revistas) de acceso abierto publicadas
por los organismos del Estado para disponer de información para el análisis y estudios destinados a la comunidad parlamentaria
Producción Programación de Delivery
7. Implementación de
herramienta para la gestión de fuentes
Producción Contraparte técnica
1. Disponer del Módulo de labor parlamentaria en
línea para mejorar el trabajo parlamentario y la transparencia de la información legislativa
Recursos Legales
Construcción de plataforma
5. Enriquecer la
radiografía Comunal
2013 para el apoyo del
trabajo parlamentario
en terreno.
Servicios
Legislativos Contraparte técnica
III. Áreas de las cuales requiere Servicios Digitales para cumplir sus metas
Meta N° Equipo Detalle Coordinación vía meta
2 Producción Arquitectura de la Información (Entrada para S. D. / Maqueta de Interacción Hombre/Máquina)
3 Producción
Procesamiento de Prensa (Informe que muestre el 100 % de la normalización de los registros
Invesdoc.)
Comentarios a Informe 2: Diagnóstico de los procesos TI
Comentarios generales
En general se está de acuerdo con el informe.
Se detectó que la gran mayoría de las sugerencias se pueden solucionar mediante un buen proceso de documentación y de una formalización de éstos. La experiencia de documentar y formalizar se ha adquirido por el proceso ISO9001-2008, pero este experiencia sólo está aplicada al alcance definido en el manual de calidad. Creemos que extender esta proceso requiere, por la carga de trabajo diaria, un nuevo cargo como QA o Asistente de gestión, para poder realizar este proceso de documentación y estandarización.
Estamos de acuerdo en la necesidad de asignar a una persona la tarea de coordinar la
documentación de los procesos.
La asesoría utiliza COBIT para evaluar el departamento de Sistemas y Servicios de Información en Red. Se sugiere contar con una adecuada capacitación sobre la metodología COBIT, para entender en profundidad y detalle las conclusiones del informe en cuestión. Una capacitación en COBIT es recomendable, pero no necesaria, ya que fue el marco de referencia para el trabajo de auditoría, pero no hemos recomendado que la BCN adhiera a este modelo. Tal vez sería interesante que la auditora se capacitara en COBIT.
Como trabajo inicial sugerimos que el consultor realice una presentación detallada del informe y sus recomendaciones. Para así pasar a la siguiente etapa que debe ser la evaluación e implementación de algunas o todas las sugerencias recibidas. Antes de iniciar esta etapa se requiere la mencionada capacitación para todos los actores involucrados. Estamos disponibles para realizar una presentación de las principales conclusiones, la misma realizada ya al Director.
El documento hace reiteradas menciones a la Estrategia BCN, al Plan Informático y a las Metas BCN anuales. Sin embargo, no existe al momento de la Auditoría, una Estrategia BCN definida y formalizada, por ende, tampoco un Plan Informático alineado con estrategia alguna. Lo que sí existe es un proceso anual que define Metas para toda la BCN y que efectivamente está descoordinado con la definición de Presupuesto Anual, y que no surge de una revisión del Valor Agregado a la Estrategia, pues -de nuevo- tal Estrategia BCN no existe.
Esto lo constata el informe.
Comentarios específicos
P01 – Definición de un plan estratégico de TI De acuerdo. Dado que se detecta la existencia de nivel 0, requerimos ayuda o apoyo para hacer un plan estratégico TI, una vez que tengamos el plan estratégico del negocio. El documento sugiere cambios en las Metas de TI, así como en la forma de evaluar su cumplimiento. Este cambio no puede enfocarse solamente de el Departamento de TI, pues Informática es una función de apoyo transversal a toda la organización. Así, se debería detallar el mecanismo de definición de Metas para involucrar a toda la BCN, y ajustar su cumplimiento con la entrega de los incentivos económicos actualmente existentes, lo que debería pasar por la validación de las respectivas entidades sindicales, a saber, la Asociación de Funcionarios y la Asociación de Empleados. El mecanismo mediante el cual la BCN establece acuerdos de desempeño con las áreas, y los incentivos asociados, exceden el ámbito de esta asesoría. En todo caso, creemos que la entrega de incentivos por resultados es positiva, sin embargo esto no debiese condicionar el establecimiento de acuerdos de desempeño.
P02 – Definición de la arquitectura de información De acuerdo. Al describir la "Situación Actual", el documento dice que "existe un modelo ontológico que permite modelar todas las estructuras de información". En realidad se está trabajando en extender las ontologías a todos los modelos de datos de la BCN, ya que actualmente estas ontologías no contemplan DAF, Repositorios, Sistema Bibliográfico, Noticias, entre otras. Se sugiere tener un arquitecto responsable de los datos. Se hace necesario conocer los estándares que se utilizan para obtener el modelo corporativo de datos.
Corregiremos el informe en lo que respecta las Ontologías.
Está dentro de las recomendaciones contar con un Arquitecto. No necesariamente es
dedicación exclusiva.
P03 – Determinar las directrices tecnológicas De acuerdo.
P04 – Definición de procesos de TI, organización y relaciones De acuerdo. Como insumo se cree necesario el modelamiento de un mapa de procesos de la BCN.
Junto a la recomendación del documento, se plantea la propuesta de utilizar un sistema de gestión documental con control de versiones de código abierto, como openKM, http://www.openkm.com/es
Creemos necesario que la BCN tenga su propio mapa de procesos, sin embargo los
procesos de gestión de TI no dependen de aquello.
Incorporaremos la recomendación acerca del sistema de gestión documental
P05 – Gestión de la inversión en tecnología De acuerdo. Estamos regidos por fechas y entregables ya establecidos. El cambio aquí debe ir acompañado con cambios a nivel superior y departamental, del funcionamiento de la BCN actualmente. Así lo hemos planteado.
P06 – Gestión de la comunicación De acuerdo. Normalmente estamos en todos los proyectos y gran parte del éxito de tales proyectos se debe a logros del depto. de TI. Los trabajadores de la BCN dan por hecho que el depto TI va a cumplir con lo comprometido en los proyectos. A menudo los logros TI no son muy comprendidos ya que no todo el personal de la BCN es alfabetizado tecnológicamente, sólo son usuarios básicos de TI. La encuesta a usuarios refleja algo diferente, los usuarios señalan mayoritariamente manejarse en un nivel avanzado con las principales herramientas.
P07 – Gestión de los recursos humanos de las TI De acuerdo. La experiencia nos ha indicado que no es factible dar incentivos al personal TI. En la práctica el único incentivo real es un ascenso (subir de jerarquía), pero esta posibilidad que es casi nula para los funcionarios, es inexistente para los que tienen cargos superiores. Estamos de acuerdo con las evaluaciones, pero hay que concordarlas, ya que al igual que las Metas TI, la evaluación de desempeño del personal debería extenderse a toda la BCN y establecer claramente cómo funcionará con el actual sistema de listas de desempeño. En tal proceso de definición tanto la Asociación de Funcionarios como la Asociación de Empleados tendrán opiniones al respecto.
Misma respuesta que P01
P08 – Gestión de la calidad De acuerdo. Creemos que es un buen ejercicio que procesos BCN puedan ser sometidos a certificación. No se menciona el uso de la herramienta WAPT.
Creemos que algunos procesos debiesen ser certificados (los más críticos) y en otros es suficiente con la adopción de buenas prácticas. Incorporaremos el uso de esa herramienta al informe.
P09 – Validación y gestión del riesgo de las TI De acuerdo. Además consideramos que es relevante contar con apoyo legal en su confección. De acuerdo.
P10 – Gestión de proyectos De acuerdo. Es un buena práctica apegarse a estándares, pero creemos que éstos deben ser flexibles (por ejemplo, en ley chile se usó algo de prince2), ya que hay proyectos o desarrollos pequeños para los cuales no tiene gran sentido el seguir un conjunto de etapas que tomen tiempo. El día a día en desarrollo es intenso, por los requerimientos y expectativas de los usuarios. Asimismo creemos que el resto de la organización debe poder acompañar estos procesos más rigurosos y administrados. No es sólo TI. Es precisamente lo que hemos planteado: adaptar las buenas prácticas de modelos como PMBOK o Prince a la realidad de la BCN.
P11 – Definición de política de seguridad De acuerdo. Falta reforzar no sólo la difusión, sino también la educación en este sentido. Respecto de la siguiente oración: "la BCN considera que toda su información es pública", hay que considerar que en la BCN se redactan muchos documentos de carácter confidencial. La frase sobre la información pública no es cosecha de los consultores, fue extraída de alguna entrevista, pero haremos la corrección.
AI1 – Identificación de soluciones: análisis funcional y técnico, análisis del riesgo, estudio de la viabilidad. De acuerdo. Pero respecto a este punto, hay que hacer notar que influyen otras unidades y/o bien órdenes superiores que deben acatarse. Se cree difícil establecer una política clara para determinar cuándo un desarrollo es interno o externo, ya que el tema va más allá de la envergadura, también influyen, la carga de trabajo del depto. TI, el conocimiento nuevo que se requiere, o simplemente si es conveniente que el mismo proveedor continúe un proyecto porque es el más idóneo y seguro. Nos parece razonable que esta función, actualmente realizada fuera del Departamento de TI, se realice nuevamente dentro. Esto significa que el área de Arquitectura de Información debería depender jerárquicamente del Jefe del Departamento de TI, con lo cual vuelva a quedar dentro de TI la administración del
Sistema Bibliográfico y de los Repositorios de Objetos Digitales, ambos fundamentales para una biblioteca. Dentro de las "Recomendaciones", el documento sugiere evaluar la contratación de software como servicio para aquellas aplicaciones que no forman parte del "core" de la BCN, sin embargo no define cuáles son aquellas aplicaciones. ¿Las debe definir el jefe de TI? ¿No deberían surgir de manera natural al realizar un mapeo de las aplicaciones y su apoyo a la Estrategia BCN? Creemos que debe existir una política de “sourcing (“outsourcing” o “insourcing”)” de las aplicaciones de la BCN que ordene, independientemente de que criterios temporales o de otra naturaleza, recomienden hacer excepciones a la política. Los productos priorizados por la BCN son :
1. Leyes vigentes y actualizadas
2. Elaboración de estudios, investigaciones y otras solicitudes
3. Acompañamiento a Comisiones
4. Catálogo bibliográfico
5. Historia de la ley
6. Bases de datos de información territorial
Al menos las aplicaciones asociadas a esos productos debiesen mantenerse dentro, las
otras son potencialmente externalizables, pero se requiere un análisis caso a caso que
considere más variables.
Respecto de Arquitectura, nuestra recomendación es que al menos la función de
levantamiento de requerimientos e intermediación con usuarios debiese pasar a TI. No
tenemos una opinión formada respecto de las otras funciones.
AI2 – Adquisición y mantenimiento de aplicaciones: Diseño, controles sobre la seguridad, desarrollo, configuración, verificación de la calidad, mantenimiento. De acuerdo. Este punto está relacionado con las problemáticas expuestas en el punto anterior. Al describir la "Situación Actual", no incluye el uso de Postgresql, Varnish y Apache junto a las "piezas principales", dentro de las que cuenta Plone, Zope, Python, Java y Oracle. Tampoco incluye el uso del "Wing-IDE" para Python, dentro de las herramientas utilizadas.
Hemos incorporado las componentes que faltaban en la descripción de la arquitectura de
desarrollo y tecnológica de la BCN.
AI3 – Adquisición y mantenimiento de la infraestructura tecnológica: Plan de infraestructuras, controles de protección y disponibilidad, mantenimiento De acuerdo. Creemos que es una buena opción la contratación de un servicio integral de arriendo. Ya se han hecho evaluaciones de externalización del data center, y éstas no nos ha dejado conformes, por los costos involucrados, ya que en este caso hay muchos costos “escondidos” o “solventados” por el depto. TI o la infraestructura del Edificio.
Es importante comparar el “Costo total de propiedad” (TCO) con las opciones de externalizar, o de lo contrario, debido a una suma de costos ocultos, las opciones de contratación siempre irán en desventaja.
AI4 – Facilidad de uso: Formación a gerencia, usuarios, operadores y personal de soporte. De acuerdo. En este momento las capacitaciones las hace Arquitectura o los mismos usuarios.
AI5 – Obtención de recursos tecnológicos: control y asignación de los recursos disponibles, gestión de contratos con proveedores, procedimientos de selección de proveedores. De acuerdo.
AI6 – Controles de cambios: Procedimientos de solicitud/autorización de cambios, verificación del impacto y priorización, cambios de emergencia, seguimiento de los cambios, actualización de documentos. De acuerdo. Una observación aquí es que hay cambios que son ordenados desde Dirección los cuales cambian las prioridades del ordenamiento que hasta ese entonces existe. En la "Situación Actual" falta incluir lo siguiente: los cambios solicitados a la sección de Ingeniería y Desarrollo quedan registrados en Redmine, que es complementaria al uso de Wrike (http://redmine.bcn.cl). Incorporamos la observación al informe.
AI7 – Instalación y acreditación de soluciones y cambios: Formación, pruebas técnicas y de usuario, conversiones de datos, test de aceptación por el cliente, traspaso a producción. De acuerdo. En general los traspasos a producción correspondientes a sistemas medianos o grandes quedan soportados por la persona o grupo que tuvo ingerencia en su desarrollo. No se ve tan factible que esto pase a operaciones, debido a la carencia de más personal calificado. Las aplicaciones quedan soportadas por las personas más idóneas. El traspaso es factible sólo a nivel básico, que es la situación actual. Nuestra sugerencia forma parte de un rediseño del área, que incluye revisar el área de operaciones. No es necesariamente malo que la persona que tuvo injerencia en el desarrollo de una aplicación, mantenga vinculación con ésta en un nivel de soporte de segundo nivel. El problema se suscita cuando las responsabilidades se diluyen. Nuestra propuesta es que exista un único responsable de operar las aplicaciones, y un traspaso formal a ese responsable desde desarrollo.
DS1 – Definición y gestión de los niveles de servicio (SLA) con usuarios/clientes De acuerdo.
En este punto, TI siempre trabaja en los diversos desarrollos o servicios sobre acuerdos con los clientes, pero aquí también está el rol del grupo de Arquitectura. Creemos que falta formalizar más estos acuerdos.
DS2 – Gestión de servicios de terceros: gestión de las relaciones con proveedores, valoración del riesgo (confidencialidad, Non-disclosure agreement - NDA), monitorización del servicio. De acuerdo.
DS3 – Gestión del rendimiento y la capacidad: planes de capacidad, monitorización del rendimiento, disponibilidad de recursos. De acuerdo. Un capacity planning nos ayudará a tener ciertas ideas para ver que umbrales de aumento de demanda podemos afrontar. Ahora bien, la planificación de infraestructura queda sujeta a las asignaciones de presupuesto y a la aprobación por parte de la dirección de la BCN.
DS4 – Asegurar la continuidad del servicio: plan de continuidad, recursos críticos, recuperación de servicios, copias de seguridad. De acuerdo.
DS5 – Garantizar la seguridad de los sistemas: gestión de identidades, gestión de usuarios, monitorización y test de seguridad, protecciones de seguridad, prevención y corrección de software malicioso, seguridad de la red, intercambio de datos sensibles. De acuerdo.
DS6 – Identificar y asignar costos De acuerdo. Creemos que sería muy conveniente extender esta identificación a otras unidades de la BCN. El Depto TI pareciera ser muy caro ya que tiene un gran presupuesto, pero en él se incluye toda la infraestructura que soporta la BCN: servidores, notebooks, impresoras, red, internet, seguridad, etc, lo que en realidad son costos transversales para la BCN. Tengo la sensación que esto no está tan claro y la impresión del porcentaje de presupuesto que se lleva TI pesa más. Dentro de las "Recomendaciones", el documento sugiere el uso de un ERP. Hay que analizar si la reciente adquisición del ERP de Browse satisface tanto las necesidades de DAF como de TI. Respecto del presupuesto de TI, es efectivo que es un costo transversal. Al ser TI un área de soporte, sus costos debiesen prorratearse entre las unidades responsables de los productos/servicios de la BCN. Es una manera de transparentar los “consumos” informáticos.
Es importante que al parametrizar el ERP, se tomen en consideración las recomendaciones en este ámbito, de costeo por producto así como algún modelo que permita traspasar los costos de TI a las áreas que consumen estos recursos.
DS7 – Formación a usuarios: identificar necesidades, planes de formación. De acuerdo. Junto a las "Recomendaciones" incluidas en el documento, vemos necesaria que deberían definirse capacitaciones específicas orientadas a quienes generan contenido visible desde Internet y que generan URL tanto de páginas como de documentos, audios, videos e imágenes, para asegurar el cumplimiento de estándares y políticas de publicación.
Incorporamos esta recomendación en el informe.
DS8 – Gestión de incidentes y Help Desk: registro y escalado de incidencias, análisis de tendencias. De acuerdo.
DS9 – Gestión de configuraciones: definición de configuraciones base, análisis de integridad de configuraciones. De acuerdo.
DS10 – Gestión de problemas: identificación y clasificación, seguimiento, integración con la gestión de incidentes y configuraciones. De acuerdo.
DS11 – Gestión de los datos: acuerdos para la retención y almacenaje de los datos, copias de seguridad, pruebas de recuperación. De acuerdo. Normalmente si los datos no están buenos se tiende a pensar que el depto. TI es el responsable, y con frecuencia funcionarios del TI corrigen los datos, cuando el problema viene del área usuaria. De acuerdo.
DS12 – Gestión del entorno físico: acceso físico, medidas de seguridad, medidas de protección medioambientales. De acuerdo.
DS13 – Gestión de las operaciones: planificación de tareas, mantenimiento preventivo. De acuerdo.
ME1 – Monitorización y evaluación del rendimiento De acuerdo.