acta de recepcion y aprobacion informe tecnico contrato: “evaluaciÓn gestion de ... ·...

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)




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




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




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




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




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




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




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.




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




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




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.




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.




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:




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”).




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.


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.




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.


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.




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.


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.

http://www.openkm.com/es




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.


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.




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.


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.




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.


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.




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.


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.




gestión TI

Página 22 de 55

Junio 2013

P09 – Validación y gestión del riesgo de las TI


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.




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.


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.

http://es.wikipedia.org/wiki/UML




gestión TI

Página 24 de 55

Junio 2013

P11 – Definición de política de seguridad


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.




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




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:




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.


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.




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.


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.




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




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.


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.




gestión TI

Página 31 de 55

Junio 2013

AI4 – Facilidad de uso: Formación a gerencia, usuarios, operadores y personal de soporte.


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.




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.


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




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.


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.

http://redmine.bcn.cl/




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.


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.




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




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


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.




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.


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.




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.


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.




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.


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.




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.


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.




gestión TI

Página 41 de 55

Junio 2013

DS6 – Identificar y asignar costos


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.




gestión TI

Página 42 de 55

Junio 2013

DS7 – Formación a usuarios: identificar necesidades, planes de formación.


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.




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.


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.




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.


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.




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.


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.




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.


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.




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.


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.




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.




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




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


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




gestión TI

Página 51 de 55

Junio 2013

ME2 – Monitorización y evaluación del control interno


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.




gestión TI

Página 52 de 55

Junio 2013

ME3 – Asegurar el cumplimiento con requerimientos externos


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.




gestión TI

Página 53 de 55

Junio 2013

ME4 – Proveer auditoría independiente


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.




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.


4.- Disponer de una

herramienta informática para gestionar eficientemente las funciones de Adquisiciones, Existencias y Activo Fijo


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




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.

http://www.openkm.com/es

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.

http://redmine.bcn.cl/

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.

ME2 – Monitorización y evaluación del control interno De acuerdo.

ME3 – Asegurar el cumplimiento con requerimientos externos De acuerdo.

ME4 – Proveer auditoría independiente De acuerdo.

acta de recepcion y aprobacion informe tecnico contrato: “evaluaciÓn gestion de ... ·...

Documents