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: XXXX XXXXXX XXXXXXXXX

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 XXXXXXXXX XXXXXXX Y RESPUESTA DE EMPRESA AUDITORA.

XXXX XXXXXX XXXXXXXXX

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)

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

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

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 xx xxxxx 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

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.

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

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

ME4: Proveer auditoría independiente

Inexistent e

departamento que esté siendo auditado.

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

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.

- 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

3. Areas de enfoque de Gobierno de TI2

Alineación estratégica

Medición de desempeño

Entrega de valor

Gobierno de TI

Administración de recursos Administración de riesgos

Alineación Estratégica

Entrega de Valor

Administración de Riesgos

2 Sistemas de Información para la Gestión, Xxx.xx Cs. Económicas, Jurídicas y Sociales – Universidad Nacional xx Xxxxx

Administración de Recursos

Medición del Desempeño

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.

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.

4. Madurez de procesos

Cabe destacar que Xxxxx 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:

Xxxxx 0 – Proceso inexistente o incompleto: El proceso no existe o no cumple con los objetivos

Xxxxx 0 – Proceso inicial o ejecutado

Xxxxx 0 – Proceso repetible o gestionado: el proceso no solo se encuentra en funcionamiento, sino que es planificado, monitorizado y ajustado.

Xxxxx 0 – Proceso definido: el proceso, los recursos, los roles y responsabilidades se encuentran documentados y formalizado.

Xxxxx 0 – Proceso administrado o predecible: se han definido técnicas de medición de resultados y controles.

Xxxxx 0 – 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:

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 Xxxxx. 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”, “xxxxxxxx xxxxx”, “xxxxxxxxxxxxxxxx xx xx xxxxxx”). 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 “Xxxxxxx Xxxxx”).

P02 – Definición de la arquitectura de información: modelo de arquitectura, diccionario de datos, clasificación de la información, gestión de la integridad.

Situación actual BCN:

En términos de madurez, este proceso se encuentra en estado “Inicial”.

El Jefe de Sistemas señala que no existe un modelo de información, sin embargo se está trabajando con un enfoque de modelo ontológico, en extender las ontologías a todos los modelos de datos de la BCN, ya que actualmente estas ontologías no contemplan DAF, Repositorios, Sistema Bibliográfico, Noticias, entre otras. Existe también un proceso instalado para mantener las ontologías. Actualmente se están analizando los diferentes sistemas para unificar sus datos, ya que hay muchos sistemas antiguos “Legacy” (heredados) cuyas estructuras de información no están documentadas.

Recomendaciones:

Implementar con alta prioridad este proceso en la BCN al menos con un nivel de madurez 2 (repetible), en lo posible 3 (definido o gestionado). Este proceso debiese tener un responsable que podría ser el “arquitecto” o el responsable del modelo corporativo de datos. Debiesen existir responsables de dominios de información así como políticas de seguridad sobre éstos. Sugerimos medir este proceso con:

• El porcentaje de elementos de datos redundantes / duplicados

• El porcentaje de aplicaciones que no cumplen con la metodología de arquitectura de la información usada por la BCN

Fundamentación:

El Departamento de Sistemas debe crear y actualizar de forma regular un modelo de información del negocio y definir los sistemas apropiados para optimizar el uso de esta información. Esto incluye el desarrollo de un diccionario corporativo de datos que contiene las reglas de sintaxis de los datos de la organización, el esquema de clasificación de datos y los niveles de seguridad. Este proceso mejora la calidad de la toma de decisiones directivas asegurándose que se proporciona información confiable y segura, y permite racionalizar los recursos de los sistemas de información. Este proceso de TI también es necesario para incrementar la responsabilidad sobre la integridad y seguridad de los datos y para mejorar la efectividad y control de la información compartida a lo largo de las aplicaciones y de las entidades.

Las ontologías complementan, pero no sustituyen la necesidad de contar con modelos de información.

Ontologías: al igual que los tesauros, son herramientas que sirven para estructurar conceptualmente determinados ámbitos del conocimiento por medio de vocabularios controlados; son sistemas de representación del conocimiento que resultan de seleccionar un dominio o ámbito del conocimiento, y aplicar sobre él un método con el fin de obtener una representación formal de los conceptos que contiene y de las relaciones que existen entre dichos conceptos (tuplas). Además, una ontología se construye en relación a un contexto de utilización.

P03 – Determinar las directrices tecnológicas: análisis de tecnologías emergentes, monitorizar tendencias y regulaciones.

Situación actual BCN:

Actualmente este proceso se lleva a cabo, aunque de manera informal y no documentada. Se encuentra en el nivel 2. Los mecanismos que se utilizan son:

- El responsable de TI mantiene contacto permanente con la Academia

- El responsable de TI monitorea permanentemente lo que ocurre en el entorno, las tendencias tecnológicas etc.

- La BCN pertenece a la IFLA y el responsable de TI participa de un grupo de Jefes de Informática de la IFLA, en el que participan las bibliotecas de EEUU, Inglaterra y Alemania, consideradas como las mejores prácticas.

- Desde el punto de vista de la infraestructura, la BCN analiza anualmente su plataforma de servidores y se hace un plan de crecimiento/migración basado en lo que está ocurriendo en el mercado, y en resolver problemas que le impiden escalar (p.e., frente a los problemas de energía y de espacio en la sala de servidores, han optado por migrar a servidores blade que comparten la información en storage area network)

Recomendaciones:

Recomendamos mantener este proceso como está, pero sí documentarlo.

Fundamentación:

La BCN es una institución altamente innovadora; la innovación en procesos y productos/servicios, así como la búsqueda de la excelencia operacional (“Promover un estilo de liderazgo en gestión pública y modernización del Estado, constituyéndose en sí misma como modelo de servicio”) forman parte de la declaración misional, por lo que es fundamental mantener procesos de innovación en áreas como la gestión de TI, que juegan un rol cada vez más importante en la eficiencia de los procesos y en la entrega de los productos/servicios.

P04 – Definición de procesos de TI, organización y relaciones: análisis de los procesos, comités, estructura organizativa, responsabilidades, propietarios de la información, supervisión, segregación de funciones, políticas de contratación.

Situación actual BCN:

En términos de su madurez, este proceso se encuentra en estado “Inicial”. En efecto, no existe un proceso formal de definición y documentación de los procesos de gestión de los recursos TI.

En cuanto al diagnóstico organizacional y las recomendaciones en este ámbito, éstos forman parte del Informe 3 de esta asesoría.

Recomendación:

Implementar con alta prioridad este proceso en la BCN al menos con un nivel de madurez 2 (repetible), deseable 3. Se deben identificar y documentar los principales procesos y procedimientos de gestión de los recursos informáticos. En lo posible se deben también medir. Deben ser conocidos por las personas del área TI y sus clientes y deben ser comunicados para conocimiento de la organización. Se recomienda el uso de un sistema documental con control de versiones para su almacenamiento, pues los documentos son dinámicos. La BCN propone utilizar un sistema de gestión documental con control de versiones de código abierto, como openKM, xxxx://xxx.xxxxxx.xxx/xx

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.

P05 – Gestión de la inversión en tecnología: gestión financiera, priorización de proyectos, presupuestos, gestión de los costes y beneficios.

Situación actual BCN:

En términos de madurez, este proceso se encuentra en estado “Repetible”. No obstante ello, se identifican importantes deficiencias que se describen a continuación.

El proceso responde aproximadamente a la siguiente lógica: en junio, el Departamento de Sistemas hace su presupuesto para el año siguiente (a esas alturas las metas no están definidas). Luego, el Departamento de Sistemas no participa de la negociación (la que es liderada por el DAF) y sólo se entera de los resultados en enero, en que conoce sólo algunas de las partidas, directamente a través de la publicación del presupuesto que realiza la DIPRES. En Xxxxx 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.

P06 – Gestión de la comunicación: políticas y procedimientos, concienciación de usuarios.

Situación actual BCN:

En términos de madurez, este proceso se encuentra en estado “Inexistente”.

Se han hecho esfuerzos esporádicos de informar a la comunidad de los logros en TI, sin embargo no forma parte de un proceso regular. Se informan novedades a través de la Intranet, pero no se evalúa la llegada de estos mensajes. No hay un comité directivo donde plantear inquietudes y problemas en la gestión de TI, estos intercambios se realizan mediante conversaciones aisladas o intercambios de correos con la dirección.

Recomendaciones:

Se recomienda implementar con alta prioridad este proceso en la BCN, al menos con un nivel de madurez 2 (repetible). Recomendamos elaborar un relato acerca de la forma en que las TI contribuyen a los logros de los propósitos fundamentales de la BCN (p.e., agregar valor al proceso legislativo, acercar las leyes a las personas y por tanto a formar un “mejor ciudadano” etc.). Luego la BCN debe identificar sus diferentes comunidades o “stakeholders” y transformar ese relato en mensajes y en canales de comunicación diferenciados, que podrían ser los mismos que utiliza la propia BCN para implementar su estrategia comunicacional. Este proceso debe ser liderado por el responsable de TI de la BCN y desplegado en coordinación con el equipo de comunicaciones de la BCN. Sugerimos medirlo con:

- Indicador que mide la visión de la organización acerca del rol de la TI

- Auditoría comunicacional; porcentaje de interesados que entienden el marco de trabajo de XX

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

P07 – Gestión de los recursos humanos de las TI: contratación, competencias del personal, roles, planes de formación, evaluación del desempeño de los empleados.

Situación actual BCN:

En términos de madurez, este proceso se encuentra en estado “Inicial”.

La Planta de TI está definida en la Ley Orgánica y es inamovible. La actual organización se heredó, no ha sido planificada. Se han incorporado unos pocos cargos nuevos.

Existe una definición muy básica de los perfiles de cargo. Se trató de hacer algo con el Eucip (European Certification of Informatics Professionals), pero las brechas eran enormes. Esa iniciativa se abortó.

El Departamento Sistemas cuenta con funcionarios de planta y de contrata. Es la DAF a través del área de RRHH de la BCN quien administra los RRHH del Departamento de Sistemas, con sugerencias de esta misma área. Esto incluye sueldos, vacaciones, etc. El esquema es rígido, no permite incentivos. La calificación del personal es un instrumento formal que no sirve a los propósitos de evaluar desempeño

Hay personas que tienen conocimientos que son críticos para la organización y que no están del todo respaldados, lo que constituye un riesgo.

Recomendaciones:

Es importante definir con precisión qué servicios se externalizarán y cuáles quedarán dentro de la BCN. A partir de esta definición, se debe determinar la dotación, y describir los perfiles de cada cargo. Debe existir una evaluación regular del desempeño del personal y un plan de desarrollo que permita cerrar las brechas encontradas en la evaluación. Es importante que las personas de TI trabajen motivadas y que existan incentivos a la excelencia. Es importante también hacer una buena gestión del conocimiento, en particular de aquel conocimiento considerado crítico para el funcionamiento de la BCN, y respaldar ese conocimiento experto. Algunas métricas:

• El nivel de satisfacción de los clientes respecto a la experiencia y habilidades del personal

• La rotación de personal de TI

• Porcentaje de personal de TI certificado de acuerdo a las necesidades del negocio

Fundamentación:

Adquirir, mantener y motivar una fuerza de trabajo para la creación y entrega de servicios de TI para el negocio se logra siguiendo prácticas definidas y aprobadas que apoyan el reclutamiento, entrenamiento, la evaluación del desempeño y el desarrollo xx xxxxxxx. 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.

P08 – Gestión de la calidad: mejora continua, orientación al cliente, sistemas de medición y monitorización de la calidad, estándares de desarrollo y adquisición.

Situación actual BCN:

Estado: Inicial

No está instalado un proceso formal de aseguramiento de calidad en los diferentes procesos de gestión de TI de la BCN, de hecho muchos de ellos no están documentados y no se miden. En particular, no existe un proceso de calidad asociado a la provisión de soluciones informáticas que permita realizar la trazabilidad de los requerimientos, evaluar la calidad de los diseños, métricas, productividad, testing de las aplicaciones, calidad de los manuales etc..

Los procesos que se miden actualmente en términos de operación y solución de los problemas, son soporte y operación xx Xxx 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.

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

Situación actual BCN:

Estado: Inicial

La BCN no tiene un mapa de los riesgos asociados a la entrega de sus productos y servicios Como consecuencia de lo anterior, el departamento de sistemas no tiene un mapa de riesgos de continuidad operacional que responda a la pregunta de ¿cómo afecta a la BCN un mal servicio de TI?

La BCN hace una evaluación de riesgos por proyecto.

El departamento de Sistemas realiza un monitoreo automatizado de su plataforma mediante una herramienta llamada Nagios, que monitorea los signos vitales de los servidores, y también la disponibilidad de las aplicaciones. Asimismo, hay una política de respaldos de los principales servidores. Es un buen punto xx xxxxxxx 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.

P10 – Gestión de proyectos: planificación, definición de alcance, asignación de recursos, etc.

Situación actual BCN:

Estado: inicial

Los "proyectos grandes y complejos" son desarrollados por el área de Proyectos Tecnológicos, responsable de la gestión de los siguientes proyectos: ley Chile, Labor parlamentaria, Web semántica e Historia de la Ley, los que se desarrollan esencialmente con apoyo de terceros. No hay un proceso formal que define la forma en que se gestionan estos proyectos, sin embargo existe una plantilla que describe las etapas de un proyecto, y que se basa en la metodología Rational Unified Process RUP(*).

Los proyectos "pequeños" en cambio, los desarrolla el área de Ingeniería y Desarrollo con recursos internos y ocasionalmente outsourcing de personal. Algunos proyectos “grandes” también han sido conducidos por esta área (p.e., workflow BCN y portal ciudadano).

Estos no siguen un proceso formal de gestión de proyectos, no hay estándares respecto de las etapas de un proyecto (factibilidad, análisis, diseño, construcción, testing etc..)

Como herramientas de apoyo, todos utilizan:

- Wrike para el seguimiento y control de los proyectos

- PSP para llevar un control de la actividad diaria.

- Wiki para la documentación (manuales) (xxxxxxxxxxxx.xxx)

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.

P11 – Definición de política de seguridad

Situación actual BCN:

Estado: Repetible

En la BCN existe una política de seguridad así como un documento de derechos y deberes de los usuarios (no así un proceso periódico de revisión, actualización y aprobación).

Ambos documentos se encuentran publicados en la Intranet. Parte importante de la política se implementa en el firewall. La filosofía en esta materia es: “no hay nada que ocultar, el grueso de la información es pública; pero es inaceptable que alguien altere la

información”. El Departamento de Sistemas es fuertemente partidario del Opendata

BCN tiene un servicio de monitoreo de intrusos (IPS Fortigate). Están en un plan de tener single sign on. Este año van a contratar un “hacking ético”

Recomendaciones:

Transformar el proceso en “definido”. Asegurarse de que la Política de Seguridad Informática esté actualizada y considere los siguientes elementos:

Alcance de la política, incluyendo facilidades, sistemas y personal sobre la cual aplica. Objetivos de la política y descripción clara de los elementos involucrados en su definición.

Responsabilidades por cada uno de los servicios y recursos informáticos aplicado a todos los niveles de la organización.

Requerimientos mínimos para configuración de la seguridad de los sistemas que abarca el alcance de la política.

Definición de violaciones y sanciones por no cumplir con las políticas. Responsabilidades de los usuarios con respecto a la información a la que tiene acceso.

Es muy importante hacer participar a la Dirección en esta política así como difundirla

Fundamentación:

La seguridad informática es el área de la informática que se enfoca en la protección de la infraestructura computacional y todo lo relacionado con ésta (incluyendo la información contenida). Para ello existen una serie de estándares, protocolos, métodos, reglas, herramientas y leyes concebidas para minimizar los posibles riesgos a la infraestructura o a la información. La seguridad informática comprende software, bases de datos, metadatos, archivos y todo lo que la organización valore (activo) y signifique un riesgo si ésta llega a manos de otras personas. Este tipo de información se conoce como información privilegiada o confidencial. Las políticas de seguridad informática surgen como una herramienta organizacional para concientizar a los colaboradores de la organización sobre la importancia y sensibilidad de la información y servicios críticos que permiten a la empresa crecer y mantenerse competitiva.

Nota:

Podemos encontrar puntos de conexión con otros estándares y xxxxxx de trabajo que pueden servir de soporte:

Cobit	Relacionado
P04 – Definición de procesos IT, organización y relaciones	Procesos según ISO3
P05 – Gestión de la inversión en tecnología	Val IT4 y VMM5 (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	XX 0000-0 (Guidelines for information security risk management)
P10 – Gestión de proyectos	PMBok7 y PRINCE28

3 xxxx://xxx.xxxxxxxxxxxxx.xxx/?xx000

4 xxxx://xx.xxxxxxxxx.xxx/xxxx/Xxx_XX

55 xxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxxx_Xxxxxxxxx_Xxxxxxxxxxx

6 xxxx://xx.xxxxxxxxx.xxx/xxxx/Xxx_0000

77 xxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxxxxx_Xxxxxxxxxx_Xxxx_xx_Xxxxxxxxx

8 xxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxxxx0

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:

AI1 – Identificación de soluciones: análisis funcional y técnico, análisis del riesgo, estudio de la viabilidad.

Situación actual BCN:

Estado: definido. Este proceso lo desarrolla el área de Arquitectura de la Información (AI), externa a Sistemas (salvo en proyectos grandes como Ley Chile). El proceso sigue aproximadamente los siguientes pasos: AI es el principal captador de necesidades de sistemas de información. Trabaja con los clientes levantando alcances, requerimientos, hasta elaborar maquetas en las que plasma el diseño de las aplicaciones. Las comparte con el Departamento de Sistemas y empieza un proceso de negociación sobre duración y recursos hasta llegar a acuerdo. TI empieza entonces el proceso de construcción. Una vez terminado el sistema, se entrega a AI para su revisión, requisito previo a la entrega al cliente.

AI tiene parcialmente documentado el proceso. En la descripción del proceso, Sistemas aparece como una fábrica de software.

Recomendaciones:

Algunos aspectos de este proceso deberían formalizarse más de lo que están, en particular lo que dice relación con las interfaces entre Sistemas y Arquitectura.

Nos parece que el mecanismo de captura de iniciativas debiese cambiar desde uno basado en la construcción de una lista de necesidades que luego se plasman en metas a uno en que las iniciativas se deriven de y una planificación informática y el criterio xx xxxxx 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.

AI2 – Adquisición y mantenimiento de aplicaciones: Diseño, controles sobre la seguridad, desarrollo, configuración, verificación de la calidad, mantenimiento.

Situación actual BCN:

Estado: repetible

Frente a cualquier nuevo proyecto, se toma la decisión de hacerlo con recursos internos o contratarlo dependiendo de la envergadura del proyecto y de la disponibilidad de recursos. La política al respecto no es del todo clara.

En todos los casos, BCN se queda con el know-how, y es responsable de la mantención y operación de la solución. No se contempla una modalidad de contratación de Software como Servicio.

Desde el punto de vista operativo, se realiza una licitación a través de Chilecompras, en dos modalidades: a) se licita el análisis y la construcción por separado; b) se contratan HH por convenio marco y se dirige el proyecto desde la BCN.

Se están estandarizando los contratos, pero aún hay gran desorden entre DAF y Sistemas en relación a quién elabora los contratos, quién les hace seguimiento, quién decide si se cobra una boleta de garantía, etc. Al licitar se anexan las políticas disponibles. No se piden certificaciones de calidad.

En caso de decidir desarrollo interno:

- No hay una metodología bien definida de desarrollo. Hay algunas directrices (p.e., separar capa de datos de capa de aplicaciones)

- Hay arquitectura base, documentada en el año 2005, no actualizada. Sus piezas principales son Plone, Zope, Python, Postgresql, Varnish, Apache, Java y Oracle

- No hay estándares de documentación de código

- Usan arquitectura SOA: servicios Web documentados para integrar aplicaciones, y promueven el reuso de componentes, aunque de manera informal. Para ello, realizan reuniones semanales del equipo de desarrollo.

Herramientas:

- Mantis bug-tracker: reporte de incidentes

- Wricke – administración de proyectos

- SVN: manejador de versiones

- Altova: modelamiento UML, XML

- Virtuoso es la base de datos semántica

- "Wing-IDE" para Python

Es preocupante que la contratación del ERP de la BCN no pase por Sistemas. Más aún, la persona de sistemas que iba a acompañar el proceso, fue contratada por Administración. El riesgo de esto es que cada área termine xxxxxxx 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.

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

AI3 – Adquisición y mantenimiento de la infraestructura tecnológica: Plan de infraestructuras, controles de protección y disponibilidad, mantenimiento.

Situación actual BCN:

Estado: Repetible

La infraestructura se planifica para el año. Los criterios principales son los de obsolescencia para equipos menores, y requerimientos de escalabilidad. Se compra a través de licitaciones o convenios marco de Chilecompras. Durante el año, hay contingencias que obligan a disponer de un presupuesto reservado para esos fines.

Por política, compran equipamiento, no lo arriendan, aunque les gustaría hacerlo. En este concepto es donde se presentan los principales problemas con la ejecución presupuestaria, movilidad entre cuentas etc.

Datacenter: las instalaciones tienen controles precarios, la situación de la BCN en este ámbito es de riesgo; la razón para no externalizarlo es principalmente de costos (muchos costos actuales están subvencionados). La sala no cumple con los estándares de datacenter, tiene problemas de temperatura, humedad, alimentación eléctrica. Están a la espera de construir una nueva sala de servidores. Además, visualizan disponer de una xxxxxxx xxxx 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.

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

Situación actual BCN:

Estado: repetible

El rol de capacitar a los usuarios en torno a las aplicaciones recae principalmente en Arquitectura de la Información. En otras ocasiones son los propios usuarios avanzados los que capacitan a sus pares.

Sistemas hace algunas capacitaciones en particular aquellas relacionadas con los “sistemas grandes”; son capacitados los usuarios, la mesa de ayuda y Arquitectura que muchas veces replica esta capacitación.

No existe un “manual de capacitadores”, que defina qué cosas debe considerar una buena capacitación, cómo se evalúa su calidad e impactos posteriores.

Pocas aplicaciones tienen una ayuda en línea, y si lo tienen es un pdf.

Soporte detecta a menudo necesidades de capacitación y aprovechando los espacios de contacto con los usuarios, hace pequeñas capacitaciones (fueron entrenados para eso), pero esto no funciona del todo bien en opinión de algunos entrevistados.

No hay un programa de formación especial para los directivos.

Recomendaciones:

Se recomienda diseñar un programa especial de formación de “liderazgo tecnológico” para los directivos.

Se recomienda diseñar un “manual de capacitadores” que defina con precisión aspectos de didáctica y también de evaluación de la calidad e impacto de las capacitaciones realizadas. Se recomienda desarrollar ayudas en línea y/o tutoriales para las principales aplicaciones. Estos temas debiesen trabajarse con Desarrollo de las Personas. Métricas:

- El porcentaje de dueños de negocios satisfechos con el entrenamiento de aplicación y los materiales de apoyo.

- El número de aplicaciones que cuentan con un adecuado entrenamiento de apoyo al usuario y a la operación

Fundamentación:

Una buena capacitación acelera el ciclo de apropiación de la tecnología, reduce la cantidad de llamados a soporte, los incidentes de seguridad, mejora la calidad del servicio prestado a los clientes y permite también que se especifiquen y diseñen mejores aplicaciones.

Asimismo, el conocimiento sobre los nuevos sistemas debe estar disponible. Este proceso requiere la generación de documentación y manuales para usuarios y para TI.

AI5 – Obtención de recursos tecnológicos: control y asignación de los recursos disponibles, gestión de contratos con proveedores, procedimientos de selección de proveedores.

Situación actual BCN:

Estado:Inicial

Uno de los principales problemas en este ámbito es que las áreas no tienen muchas restricciones en pedir ya que TI es un centro de costo, y existe una sensación de que los usuarios piden más de lo que necesitan.

No hay políticas de rotación de equipos. En general, se cambian los equipos obsoletos (más de 4 años para notebooks).

El parque de PCs es variado, aunque han estado intentando estandarizar.

Existe un inventario de equipos.

Para los equipos menores, el proceso es aproximadamente el siguiente: TI licita, la DAF recibe e inventaría los equipos (les pone etiqueta), con ese número asignado TI los ingresa al sistema informático KBox y los configura a partir de discos imágenes. Los incidentes sobre el equipo se registran en ese sistema Kbox.

Herramientas:

- KBox permite un gestión del inventario de equipos (PCs, impresoras, palms,…), tiene funcionalidades interesantes como diseminar parches e instalar aplicaciones. Se tiene la percepción de que no se le ha sacado todo el provecho a esta herramienta.

Los servidores están inventariados en otro sistema. El áreas de TI gestiona las garantías.

Tienen un registro de proveedores muy rudimentario (Excel), no utilizan el registro de proveedores de Chilecompras.

Recomendaciones:

- Diseñar un mecanismo que permita regular la demanda

- Definir un procedimiento para la renovación/rotación de equipos, en que el criterio mandatorio tenga relación con las necesidades.

- Sacar el máximo provecho a la herramienta KBox

AI6 – Controles de cambios: Procedimientos de solicitud/autorización de cambios, verificación del impacto y priorización, cambios de emergencia, seguimiento de los cambios, actualización de documentos.

Situación actual BCN:

Estado: Repetible

Las áreas de Arquitectura y de Ingeniería y Desarrollo capturan los requerimientos de mantenciones perfectivas/correctivas. Hay muchas peticiones de cambios y permanentemente se negocian. No hay un proceso definido que establezca criterios para la priorización de las solicitudes de cambio, y luego trazabilidad completa de éstos, que asegure que los cambios se reflejen en las diferentes documentaciones del sistema. Cuando hay empresas externas involucradas, se hace un seguimiento más detallado de los cambios.

La herramienta que se usa para registrar las solicitudes de cambios es Google Docs. Los cambios solicitados a la sección de Ingeniería y Desarrollo quedan registrados en Redmine, que es complementaria al uso xx Xxxxx (xxxx://xxxxxxx.xxx.xx).

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.

AI7 – Instalación y acreditación de soluciones y cambios: Formación, pruebas técnicas y de usuario, conversiones de datos, test de aceptación por el cliente, traspaso a producción.

Situación actual BCN:

Estado: repetible

Existe un proceso definido (no documentado) para paso a producción de los proyectos grandes. No ocurre lo mismo con los otros proyectos. Sin embargo, el proceso tiene serias falencias. La delimitación de responsabilidades entre Operaciones y las áreas de Proyectos e Ingeniería en el proceso no es clara. Estas últimas no se desligan de los aspectos operativos, una vez que entran en producción las aplicaciones, y siguen soportando la operación, con lo cual la responsabilidad frente a un problema se diluye. El área de operaciones no establece un “procedimiento de aceptación” de las aplicaciones antes de subirlas a producción. No siempre las aplicaciones están documentadas.

También hay una zona gris entre Sistemas y Arquitectura en relación a la aceptación por parte del cliente.

Actualmente, Proyectos/Ingeniería capacitan a las personas que darán soporte, se definen los procedimientos de respaldos, monitoreo, claves de acceso, etc..

Los ambientes de desarrollo, testing y producción están segregados, lo que es una buena práctica.

Habitualmente, la carga inicial de datos la hace Proyectos/Ingeniería, a pesar de que debiese ser responsabilidad del área de contenidos

Una vez puesto en producción, Arquitectura monitorea y evalúa el uso de las aplicaciones, tasa de problemas etc.

Herramientas: Se usa el SVN: Subversion como manejador de versiones

Recomendaciones:

Recomendamos formalizar y documentar el procedimiento de paso a producción, el cual debe considerar condiciones mínimas, como el test de aceptación por parte de operaciones, definición de SLAs etc. Idealmente, operaciones debiese tomar el control de la aplicación, una vez aceptada. Métricas

- Tiempo perdido de la aplicación o problemas de datos provocados por pruebas Inadecuadas

- Porcentaje de sistemas que satisfacen los beneficios esperados, medidos en el proceso posterior a la implantación

- Porcentaje de proyectos con plan de prueba documentado y aprobado

Fundamentación:

Los nuevos sistemas necesitan estar funcionales una vez que su desarrollo se completa. Esto requiere pruebas adecuadas en un ambiente dedicado con datos de prueba relevantes, definir la transición e instrucciones de migración, planear la liberación y la transición en sí al ambiente de producción, y revisar la post-implantación. Esto garantiza que los sistemas operativos estén en línea con las expectativas convenidas y con los resultados.

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 xxxx://xxx.xxxxxxxxxxxxx.xxx/xxxx/?xx000

10 xxxx://xxx.xxxxxxxxxxxxx.xxx/xxxx/?xx000

5.3. Dominio Entrega y Soporte

La entrega y soporte de servicios se encuentran constituidos por diversos procesos orientados a asegurar la eficacia y eficiencia de los sistemas de información. El estándar COBIT ha definido 13 procesos diferentes:

DS1 – Definición y gestión de los niveles de servicio (SLA) con usuarios/clientes

Situación actual BCN:

Este proceso no está instalado en la BCN. No hay acuerdos de niveles de servicio con las áreas clientes ni con la BCN para las aplicaciones en producción. La falta de estos acuerdos genera expectativas que no reflejan la realidad y pueden significar frustraciones (p.e. que los sistemas y sus soportes tienen que funcionar 24x7) .

La periodicidad de los respaldos está definida (son automatizados) y el proceso de recuperación de los datos ha sido probado.

Tampoco hay SLAs para soporte del equipamiento menor o para los servicios de impresión. En cambio, se miden los tiempos y tareas realizadas y solicitudes cerradas, así como la calificación del usuario a la atención del problema. Esto último, sólo en el caso que a la solicitud le haya sido asignado un ticket (lo que no siempre ocurre)

Recomendaciones:

Es fundamental implementar este proceso y aclarar cuáles son los niveles de servicio que se requieren y que se entregarán. Los SLAs, en particular aspectos tales como disponibilidad, seguridad, soporte, confiabilidad, deben formar parte de las metas del Departamento de Sistemas. De lo contrario, se producen malos entendidos y frustración. Métricas:

El cumplimiento de los SLAs medidos

El porcentaje de Interesados satisfechos de que la entrega del servicio cumple con los niveles previamente acordados

El número de servicios entregados que no están en el catálogo

El número de reuniones formales de revisión del Acuerdo de Niveles de Servicio (SLA) con las personas de negocio por año

Fundamentación:

Contar con una definición documentada y un acuerdo de servicios de TI y de niveles de servicio, hace posible una comunicación efectiva entre la gerencia de TI y los clientes de negocio respecto de los servicios requeridos. Este proceso también incluye el monitoreo y la notificación oportuna a los Interesados sobre el cumplimiento de los niveles de servicio. Este proceso permite la alineación entre los servicios de TI y los requerimientos de negocio relacionados.

DS2 – Gestión de servicios de terceros: gestión de las relaciones con proveedores, valoración del riesgo (confidencialidad, Non-disclosure agreement - NDA), monitorización del servicio.

Situación actual BCN:

Se tienen contratos tipo para desarrollos, que incluyen NDA, propiedad intelectual etc. Son algo antiguos y al Departamento de Sistemas le falta apoyo para revisar sistemáticamente los contratos.

En los contratos con terceros se establecen SLAs que consideran multas ante incumplimientos (p.e., contrato con empresa GTD que provee enlace inter-sedes). Sin embargo, no maneja SLAs con proveedores internos de servicios tales como climatización o energía de la sala de máquinas.

Los PCs se compran con 3 años de garantía, se manejan equipos de reemplazo y repuestos. Todo el equipamiento crítico está respaldado con contratos de mantención (p.e., servidores con Adexus).

Hasta ahora no han contratado en modalidad “software como servicio” (SaaS) e incluso operación de terceros de los sistemas. La primera experiencia será con la empresa Browse, contrato en el que Sistemas no va a tener ninguna injerencia.

Recomendaciones:

Recomendamos normar y documentar el procedimiento de “gestión de servicios de

terceros” y capacitar a quiénes tienen la responsabilidad de administrar esos contratos. Adicionalmente, recomendamos llevar un registro de proveedores.

También recomendamos una mejor coordinación de Sistemas con el equipo jurídico de la BCN para la revisión de los formatos tipo de contratos y también para la revisión caso a caso de los contratos, en particular en aquellas cláusulas que fijan los niveles de servicio, acuerdos de confidencialidad etc.

Finalmente, recomendamos que la BCN se abra a evaluar nuevas modalidades de contratación (SaaS, outsourcing de PCs etc.).

Métricas:

• El número de quejas de los usuarios debidas a los servicios contratados

• El porcentaje de los principales proveedores que cumplen claramente los requerimientos definidos y los niveles de servicio

• El porcentaje de los principales proveedores sujetos a monitoreo

Fundamentación:

La necesidad de asegurar que los servicios provistos por terceros cumplan con los requerimientos del negocio, requiere de un proceso efectivo de administración de terceros. Este proceso se logra por medio de una clara definición de roles, responsabilidades y expectativas en los acuerdos con los terceros, así como con la revisión y monitoreo de la efectividad y cumplimiento de dichos acuerdos. Una efectiva administración de los servicios de terceros minimiza los riesgos del negocio asociados con proveedores que no se desempeñan de forma adecuada.

DS3 – Gestión del rendimiento y la capacidad: planes de capacidad, monitorización del rendimiento, disponibilidad de recursos.

Situación actual BCN:

No hay en la BCN un proceso formal de planificación de la capacidad (“capacity planning” es el proceso para determinar la capacidad que tiene una compañía para afrontar el crecimiento en la demanda de sus productos; habitualmente se simula la carga esperada de las aplicaciones, y se dimensiona la plataforma requerida). No obstante ello, se hace una planificación anual de la infraestructura.

La BCN monitorea el desempeño de la infraestructura y aplicaciones, y cuando se llega a umbrales, se gatillan alarmas via correo. La utilización del software de monitoreo permite realizar mantenciones preventivas (por ej: limpieza/borrado para evitar llenado de disco o asignación de espacio adicional para Base de Datos)

El Departamento de Sistemas tiene planificado a contratar monitoreo externo para ver tiempos de descarga de páginas (se evalúa la herramienta xxxxxxx.xxx). 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.

DS4 – Asegurar la continuidad del servicio: plan de continuidad, recursos críticos, recuperación de servicios, copias de seguridad.

Situación actual BCN:

Existe un proceso formal para asegurar la continuidad de servicio para Ley Chile; forma parte de la certificación ISO de ese proceso.

Sin embargo, no existe un proceso de este tipo para las otras aplicaciones.

La BCN tienen procedimientos de respaldos, se han hecho simulaciones de restauración y han funcionado.

Comunicaciones: cuando se cae GTD (proveedor del enlace entre Santiago y Valparaíso), los usuarios de la BCN pueden entrar a los sistemas a través de Internet. Si se cae Claro (proveedor de Internet), los usuarios de la BCN mantienen la conexión entre ellos, no así los usuarios que acceden desde fuera, p.e., los Parlamentarios.

Frente a un corte de energía, la UPS da un margen de 10 minutos para hacer una bajada ordenada de los servidores.

Recomendaciones:

Recomendamos identificar los procesos/sistemas críticos y definir para cada uno de ellos un plan de continuidad del servicio.Métricas:

• Número de horas perdidas por usuario por mes, debidas a interrupciones no planeadas

• Número de procesos críticos de negocio que dependen de TI, que no están cubiertos por un plan de continuidad

Fundamentación:

La necesidad de brindar continuidad en los servicios de TI requiere desarrollar, mantener y probar planes de continuidad de TI, almacenar respaldos fuera de las instalaciones y entrenar de forma periódica sobre los planes de continuidad. Un proceso efectivo de continuidad de servicios, minimiza la probabilidad y el impacto de interrupciones mayores en los servicios de TI, sobre funciones y procesos claves del negocio.

DS5 – Garantizar la seguridad de los sistemas: gestión de identidades, gestión de usuarios, monitorización y test de seguridad, protecciones de seguridad, prevención y corrección de software malicioso, seguridad de la red, intercambio de datos sensibles.

Situación actual BCN:

La política de seguridad se implementa en el entramado de firewalls, antispam, antivirus, y sistemas de detección de intrusos que conforman la plataforma tecnológica. La BCN no ha tenido incidentes de seguridad relevantes, en cambio se han detectado intentos de intrusión. Las políticas de claves son débiles. Sólo se monitorea que las claves no sean el nombre de las personas. Ante 3 intentos fallidos se bloquean las cuentas.

Este año implementará Active Directory con single sign-on, es decir, los usuarios serán validados contra un Directorio, y sólo tendrán que ingresar una única password para acceder a todos los sistemas a los que tienen derecho de acceder.

La sala de máquinas tiene estándares bajos de seguridad.

Recomendaciones:

Creemos que la administración de la seguridad y las medidas que está tomando la BCN son adecuadas, sin embargo, es importante formalizar este proceso.

Es también importante realizar regularmente un monitoreo de la seguridad (tipo hacking ético) e implementar las recomendaciones que de allí surjan.

Fundamentación:

La política de seguridad de la BCN apunta a proteger la alteración/modificación de la información, así como a garantizar la continuidad del servicio, no así la confidencialidad, ya que la BCN considera que toda su información es pública.

No obstante ello, la gravedad de que información de las bases de datos pueda ser alterada, tanto por las consecuencias que ello pudiese tener en el proceso legislativo, como también por el daño de imagen que pudiese sufrir la propia biblioteca, obligan a extremar la implementación de las medidas de seguridad que derivan de la política.

DS6 – Identificar y asignar costos

Situación actual BCN:

En Sistemas, no hay un proceso de asignación de costos a productos/servicios. Actualmente, es muy difícil saber cuánto cuesta construir y luego operar los diferentes productos o servicios informáticos.

El Departamento de Sistemas lleva presupuestos por proyectos, pero no se prorratean los costos indirectos.

Recomendaciones:

Nuestra recomendación es implementar un proceso que permita llevar una contabilidad por centros de costo y por proyecto. Posiblemente, la adquisición de un ERP facilite esta medida.

Fundamentación:

Una forma de saber qué tan eficiente es la BCN en la gestión de sus recursos informáticos es a través del benchmarking de costos. Si los costos internos son superiores a la de los proveedores externos, hay que revisar lo que se está haciendo. Si son inferiores, se puede tener algún nivel de tranquilidad, a menos que el servicio sea mal evaluado por los clientes. La asignación de costos permite también crear conciencia en los clientes internos, de que pedir recursos informáticos tiene costo para la BCN.

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

Situación actual BCN:

No existe un proceso de evaluación de las competencias digitales de los trabajadores de la BCN. El Departamento de Sistemas no participa del diseño de los “planes de

capacitación” que realiza RRHH. La formación es de acuerdo a la demanda, pero no hay planes construidos basados en un análisis de brechas. A menudo, la detección de las brechas las realiza la gente de soporte. Tampoco se mide el impacto de la capacitación.

Recomendaciones:

Se sugiere establecer un estándar mínimo de competencias digitales para todo el personal que labora en la BCN y realizar un diagnóstico y análisis de brechas. Para cerrar las brechas, se recomienda elaborar/adquirir un curso de alfabetización digital, que incorpore también la difusión de las principales herramientas tecnológicas de la Biblioteca y de los derechos y deberes de los usuarios informáticos. Este curso de inducción/nivelación podría ser full e-learning y formar parte del proceso de inducción a la BCN. Debe permitir una evaluación de los aprendizajes.

Además, deberían proveerse capacitaciones específicas orientadas a quienes generan contenido visible desde Internet y que generan URL tanto de páginas como de documentos, audios, videos e imágenes, para asegurar el cumplimiento de estándares y políticas de publicación.

Métricas:

Número de llamadas de soporte debido a problemas de entrenamiento Porcentaje de satisfacción de los Interesados con el entrenamiento recibido Lapso de tiempo entre la identificación de la necesidad de entrenamiento y la impartición del mismo

Fundamentación:

Dada la importancia de las TI en la BCN, se requiere que cualquier persona que trabaje en ella tenga un piso de destrezas en el uso de la tecnología, algo así como una “licencia de manejar” computadores.

Un programa efectivo de entrenamiento incrementa el uso efectivo de la tecnología al disminuir los errores, incrementando la productividad y el cumplimiento de los controles clave tales como las medidas de seguridad de los usuarios.

DS8 – Gestión de incidentes y Help Desk: registro y escalado de incidencias, análisis de tendencias.

Situación actual BCN:

Este proceso existe, está estructurado; aún cuando no tuvimos evidencia de que estuviese documentado. Se está empezando a medir y a estructurar la información que se obtiene en este proceso.

Se gestionan los incidentes, sin embargo, la clasificación de éstos es insuficiente para hacer una gestión que vaya más allá de la casuística.

Hay escalamiento en la atención de los incidentes, pero las personas que desempeñan la función de segundo nivel y a las que se les derivan los casos que no pueden ser resueltos en el primer nivel, no son usuarios del “workflow”, por lo tanto no tienen alarmas, ni pueden registrar lo que hacen. Son los analistas de la mesa de ayuda los responsables de cerrar, y para eso deben “perseguir” al segundo nivel.

La mesa de ayuda tiene 3 canales de acceso: a través de un sistema, un llamado telefónico o correo. No todos los llamados derivan en un ticket.

Al término de la atención, las personas evalúan el servicio.

Herramienta: Kbox es el sistema de atención/workflow de la mesa de ayuda.

Recomendaciones:

Recomendamos documentar el proceso, y definir una buena taxonomía/clasificación de incidentes, para luego poder hacer gestión de problemas y resolver estructuralmente lo que la mesa de ayuda resuelve caso a caso. Métricas:

Satisfacción del usuario con el soporte de primera línea

Porcentaje de incidentes resueltos dentro de un lapso de tiempo aceptable / acordado. Índice de abandono de llamadas

Fundamentación:

Responder de manera oportuna y efectiva a las consultas y problemas de los usuarios de TI, requiere de una mesa de servicio bien diseñada y bien ejecutada, y de un proceso de administración de incidentes. Este proceso incluye la creación de una función xx xxxx 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.

DS9 – Gestión de configuraciones: definición de configuraciones base, análisis de integridad de configuraciones.

Situación actual BCN:

A nivel de estaciones de trabajo, se utiliza un sistema (Kbox) para llevar un registro de las configuraciones; se actualiza remotamente. Kbox detecta la configuración, los programas que están corriendo, licencias etc. Desde el punto de vista de carga/restitución de la configuración, se hace con disco imagen y es el que se instala.

Respecto de los servidores, el área de operaciones lleva un registro de las configuraciones en una planilla (tanto a nivel de hardware como de los servidores virtualizados)

Recomendaciones:

El proceso nos parece adecuado, se podría tal vez sacar más provecho a la herramienta. Recomendamos documentar el proceso. Métricas:

El número de problemas de cumplimiento del negocio debido a inadecuada configuración de los activos.

El número de desviaciones identificadas entre el repositorio de configuración y la configuración actual de los activos.

Porcentaje de licencias compradas y no registradas en el repositorio

Fundamentación:

Garantizar la integridad de las configuraciones de hardware y software requiere establecer y mantener un repositorio de configuraciones completo y preciso. Este proceso incluye la recolección de información de la configuración inicial, el establecimiento de normas, la verificación y auditoría de la información de la configuración y la actualización del repositorio de configuración conforme se necesite. Una efectiva administración de la configuración facilita una mayor disponibilidad, minimiza los problemas de producción y resuelve los problemas más rápido.

DS10 – Gestión de problemas: identificación y clasificación, seguimiento, integración con la gestión de incidentes y configuraciones.

Situación actual BCN:

No existe un proceso formal de gestión de problemas.

Recomendaciones:

Recomendamos implementar este proceso. Una efectiva administración de problemas requiere la identificación y clasificación de problemas, el análisis de las causas desde su raíz, y la resolución de éstas. El proceso de administración de problemas también incluye la identificación de recomendaciones para la mejora, el mantenimiento de registros de problemas y la revisión del estatus de las acciones correctivas. Métricas:

Número de problemas recurrentes con impacto en el negocio

Porcentaje de problemas resueltos dentro del período de tiempo solicitado

Frecuencia de los reportes o actualizaciones sobre un problema en curso, con base en la severidad del problema

Fundamentación:

Un efectivo proceso de administración de problemas mejora los niveles de servicio, reduce costos y mejora la conveniencia y satisfacción del usuario.

En particular, una buena gestión de problemas debe traducirse en una:

Disminución del número de incidentes y una más rápida resolución de los mismos. Mayor eficacia en la resolución de problemas.

Gestión proactiva, que permita identificar problemas potenciales antes de que éstos se manifiesten o provoquen una seria degradación de la calidad del servicio.

DS11 – Gestión de los datos: acuerdos para la retención y almacenaje de los datos, copias de seguridad, pruebas de recuperación.

Situación actual BCN:

Las validaciones a la entrada de datos para asegurar la calidad del registro, no son responsabilidad de Sistemas, sino que de las áreas de contenidos. Sistemas sólo participa en la construcción de las reglas de validación embebidas en el código de la aplicación.

Los servidores comparten una unidad de almacenamiento (storage) Respaldo de datos:

1. Almacenamiento de cintas en Valparaíso: El almacenamiento de cintas las cuales contiene respaldo de datos de servidores, bases de datos, máquinas virtuales y archivos de usuarios, se realiza en mueble metálico con llave ubicado en sala de servidores 5º Piso.

2. Almacenamiento de cintas en Santiago: El almacenamiento de cintas las cuales contiene copia de respaldo de datos de servidores, bases de datos y máquinas virtuales, se realiza en mueble ubicado en ofician de soporte (Huérfanos)

3. Consistencia de respaldos: Al finalizar cada respaldo de datos de servidores, bases de datos, máquinas virtuales y archivos de usuarios, se realiza chequeo de cinta bajo modalidad revisión/lectura de header de cada archivo de la cinta, es decir, si el header del archivo puede ser leído por el software de respaldo éste asume que la data es segura, en caso contrario, la información del error queda almacenada en el log de la actividad de respaldo. Al finalizar chequeo de la cinta de respaldo, el servidor donde se está ejecutando el respaldo de los datos, envía correo electrónico con resultado de respaldo de datos y su verificación.

4. Rotulación de cintas: Las cintas que contienen respaldos y que son almacenadas tanto en Valparaíso como en Santiago, se anota el contenido del respaldo en la hoja que se encuentra en la caja de la cinta. Además cada cinta posee un código xx xxxxx.

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.

DS12 – Gestión del entorno físico: acceso físico, medidas de seguridad, medidas de protección medioambientales.

Situación actual BCN:

La seguridad del datacenter es muy débil. La sala es compartida con el Senado. Se entra con una tarjeta de identificación. La cámara filmadora no está operativa. Es cierto que el edificio del Congreso tiene medidas de seguridad superiores a las de la mayoría de los edificios, pero eso no es suficiente.

Se mide la temperatura y humedad de la sala, y hay alarmas que gatillan correos. Se analiza el consumo eléctrico.

Recomendaciones:

Evaluar alternativas tales como traslado a un datacenter TIER 3, aunque esto tenga costos adicionales. De lo contrario, cambiarse a una sala distinta a la actual y reforzar las medidas de seguridad. Los activos TI de la BCN son demasiado importantes como para estar expuestos a este nivel de riesgo.

Fundamentación:

El objetivo es proporcionar un ambiente físico conveniente que proteja al equipo y al personal de TI contra peligros naturales (fuego, polvo, calor excesivos) o fallas humanas lo cual se hace posible con la instalación de controles físicos y ambientales adecuados que sean revisados regularmente para su funcionamiento apropiado definiendo procedimientos que provean control de acceso del personal a las instalaciones y contemplen su seguridad física.

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 xx xxxxx).

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.

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 Organization12 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 xxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxxxxxxxxx_Xxxxxxxxxx_Xxxxxxxxxxxxxx_Xxxxxxx

12 xxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxxxxxxxxx_Xxxxxxxxxx_Xxxxxxxxxxxxxx_Xxxxxxx

13 xxxx://xx.xxxxxxxxx.xxx/xxxx/XX_00000

14 xxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxxxxxx_Xxxxxxxxxx_Xxxxxxxxx

15 xxxx://xx.xxxxxxxxx.xxx/xxxx/Xxx_Xxxx_Xxxxxx_Xxxxxxxx_Xxxxxxx_Xxxxxxxxxxx_Xxxxxx

16 xxxx://xxx.xxxxx.xxx/

17 xxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxxxxxx-xxxxx_xxxxxxx

5.4. Supervisión y Evaluación

El último dominio se centra en la supervisión de los sistemas con el objetivo de:

Garantizar la alineación con la estrategia del negocio

Verificar las desviaciones en base a los acuerdos de niveles de servicio Validar el cumplimiento regulatorio

Esta supervisión implica paralelamente la verificación de los controles por parte de auditores (internos o externos), ofreciendo una visión objetiva de la situación y con independencia del responsable del proceso.

El estándar Cobit define los siguientes 4 procesos:

ME1 – Monitorización y evaluación del rendimiento

Situación actual BCN:

No existe un convenio de desempeño entre el Departamento de Sistemas y la BCN. Existen metas, que se asemejan a una lista de actividades esperadas pero están lejos de ser un instrumento de gestión que permita evaluar el desempeño de la actividad.

El área de gestión de la BCN hace una evaluación de las metas y TI envía un informe con medios de verificación. Se calcula el porcentaje de cumplimiento.

Se monitorean los signos vitales de los servidores y algunos parámetros de las aplicaciones, con fines operacionales (p.e., detectar caídas), pero no se utilizan para medir el rendimiento.

Recomendaciones:

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

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

Situación actual BCN:

Este proceso no ocurre actualmente en la BCN.

Recomendaciones:

Establecer un programa de control interno efectivo para TI, lo que requiere definir e implementar los controles internos en relación a los principales procesos de gestión de los recursos informáticos. Este proceso incluye el monitoreo y el reporte de las excepciones de control, resultados de las auto-evaluaciones y revisiones por parte de terceros.

Medición:

• Número de brechas importantes del control interno

• Número de iniciativas para la mejora del control

• Número y cubrimiento de auto evaluaciones de control

Fundamentación:

El objetivo es asegurar el logro de las metas de control interno establecidos para los procesos de TI. Para ello se debe monitorear la efectividad de los controles internos a través de actividades administrativas y de supervisión, comparaciones, reconciliaciones y otras acciones rutinarias, evaluar su efectividad y emitir reportes sobre ellos en forma regular. Estas actividades de monitoreo continuo deberán revisar la existencia de puntos vulnerables y problemas de seguridad. Un beneficio clave del monitoreo del control interno es proporcionar seguridad respecto a las operaciones eficientes y efectivas y el cumplimiento de las leyes y regulaciones aplicables.

ME3 – Asegurar el cumplimiento con requerimientos externos

Situación actual BCN:

Sistemas hace revisión de cumplimientos de SLAs comprometidos por parte de terceros, pero no existe un proceso formal que da cuenta de aquello.

Jurídica hace revisión de cumplimiento xx xxxxx (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.

ME4 – Proveer auditoría independiente

Situación actual BCN:

En la BCN recién se está instalando la función de auditoría. Hasta ahora no se había realizado una auditoría informática.

Recomendaciones:

Recomendamos implementar este proceso mediante auditorías independientes desarrolladas a intervalos regulares de tiempo; esto significa que los auditores no deberán estar relacionados con la sección o departamento que esté siendo auditado. Los auditores deben ser técnicamente competentes en el tema, de modo de asegurar tareas efectivas y eficientes de auditoría.

Métricas:

• La frecuencia de los reportes de TI hacia el consejo directivo (incluyendo el nivel de madurez)

• Frecuencia de revisiones independientes del cumplimiento de TI

Fundamentación:

El objetivo de este proceso es incrementar los niveles de confianza y beneficiarse de recomendaciones basadas en mejores prácticas.

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 xxxxxxxx.xxx.xx, permitiendo una búsqueda de texto completo

4. Migrar la plataforma de Intranet a Plone 4.2 para mejorar las tareas de edición de contenidos y tiempos de respuesta

5. Disponer de Active Directory en alta disponibilidad, para single sign on. y de unificación de: dominio windows, CGP, SSO, SSP, Kbox, Barracuda, para facilitar la entrada a todos los servicios con una sola contraseña.

II. Metas comprometidas de otras áreas que requieren HH de Servicios Digitales

Meta N°

Equipo

Detalle

Coordinación vía meta

2.- Disponer de una herramienta informática para gestionar eficientemente, las funciones de contabilidad

de la BCN

DAF

Contraparte Técnica

3. Disponer de una herramienta informática para gestionar eficientemente las

funciones de presupuesto y tesorería.

DAF

Contraparte Técnica

4.- Disponer de una herramienta informática para gestionar eficientemente las funciones de

Adquisiciones, Existencias y Activo Fijo

DAF

Contraparte Técnica

4. Disponer de 300 nuevos objetos digitales en el Portal de HPL para relevar el aporte histórico del

Congreso Nacional y

HP/AP

Ajustes programación Portal

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 xx xxxxxxx	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

Producción

Arquitectura de la Información (Entrada para S. D. / Maqueta de Interacción Hombre/Máquina)

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, xxxx://xxx.xxxxxx.xxx/xx

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 xxx xxxxx. de TI. Los trabajadores de la BCN dan por hecho que el depto TI va a cumplir con lo comprometido en los proyectos. A menudo los logros TI no son muy comprendidos ya que no todo el personal de la BCN es alfabetizado tecnológicamente, sólo son usuarios básicos de TI.

La encuesta a usuarios refleja algo diferente, los usuarios señalan mayoritariamente manejarse en un nivel avanzado con las principales herramientas.

P07 – Gestión de los recursos humanos de las TI De acuerdo.

La experiencia nos ha indicado que no es factible dar incentivos al personal TI. En la práctica el único incentivo real es un ascenso (subir de jerarquía), pero esta posibilidad que es casi nula para los funcionarios, es inexistente para los que tienen cargos superiores.

Estamos de acuerdo con las evaluaciones, pero hay que concordarlas, ya que al igual que las Metas TI, la evaluación de desempeño del personal debería extenderse a toda la BCN y establecer claramente cómo funcionará con el actual sistema de listas de desempeño. En tal proceso de definición tanto la Asociación de Funcionarios como la Asociación de Empleados tendrán opiniones al respecto.

Misma respuesta que P01

P08 – Gestión de la calidad De acuerdo.

Creemos que es un buen ejercicio que procesos BCN puedan ser sometidos a certificación.

No se menciona el uso de la herramienta WAPT.

Creemos que algunos procesos debiesen ser certificados (los más críticos) y en otros es suficiente con la adopción de buenas prácticas. Incorporaremos el uso de esa herramienta al informe.

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

Además consideramos que es relevante contar con apoyo legal en su confección. De acuerdo.

P10 – Gestión de proyectos De acuerdo.

Es un buena práctica apegarse a estándares, pero creemos que éstos deben ser flexibles (por ejemplo, en ley chile se usó algo de prince2), ya que hay proyectos o desarrollos pequeños para los cuales no tiene gran sentido el seguir un conjunto de etapas que tomen tiempo. El día a día en desarrollo es intenso, por los requerimientos y expectativas de los usuarios.

Asimismo creemos que el resto de la organización debe poder acompañar estos procesos más rigurosos y administrados. No es sólo TI.

Es precisamente lo que hemos planteado: adaptar las buenas prácticas de modelos como PMBOK o Prince a la realidad de la BCN.

P11 – Definición de política de seguridad De acuerdo.

Falta reforzar no sólo la difusión, sino también la educación en este sentido. Respecto de la siguiente oración: "la BCN considera que toda su información es pública", hay que considerar que en la BCN se redactan muchos documentos de carácter confidencial.

La frase sobre la información pública no es cosecha de los consultores, fue extraída de alguna entrevista, pero haremos la corrección.

AI1 – Identificación de soluciones: análisis funcional y técnico, análisis del riesgo, estudio de la viabilidad.

De acuerdo.

Pero respecto a este punto, hay que hacer notar que influyen otras unidades y/o bien órdenes superiores que deben acatarse.

Se cree difícil establecer una política clara para determinar cuándo un desarrollo es interno o externo, ya que el tema va más allá de la envergadura, también influyen, la carga de trabajo xxx xxxxx. 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.

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 xx Xxxxx (xxxx://xxxxxxx.xxx.xx).

Incorporamos la observación al informe.

AI7 – Instalación y acreditación de soluciones y cambios: Formación, pruebas técnicas y de usuario, conversiones de datos, test de aceptación por el cliente, traspaso a producción.

De acuerdo.

En general los traspasos a producción correspondientes a sistemas medianos o grandes quedan soportados por la persona o grupo que tuvo ingerencia en su desarrollo. No se ve tan factible que esto pase a operaciones, debido a la carencia de más personal calificado. Las aplicaciones quedan soportadas por las personas más idóneas. El traspaso es factible sólo a nivel básico, que es la situación actual.

Nuestra sugerencia forma parte de un rediseño del área, que incluye revisar el área de operaciones. No es necesariamente malo que la persona que tuvo injerencia en el desarrollo de una aplicación, mantenga vinculación con ésta en un nivel de soporte de segundo nivel. El problema se suscita cuando las responsabilidades se diluyen. Nuestra propuesta es que exista un único responsable de operar las aplicaciones, y un traspaso formal a ese responsable desde desarrollo.

DS1 – Definición y gestión de los niveles de servicio (SLA) con usuarios/clientes De acuerdo.

En este punto, TI siempre trabaja en los diversos desarrollos o servicios sobre acuerdos con los clientes, pero aquí también está el rol del grupo de Arquitectura. Creemos que falta formalizar más estos acuerdos.

DS2 – Gestión de servicios de terceros: gestión de las relaciones con proveedores, valoración del riesgo (confidencialidad, Non-disclosure agreement - NDA), monitorización del servicio.

De acuerdo.

DS3 – Gestión del rendimiento y la capacidad: planes de capacidad, monitorización del rendimiento, disponibilidad de recursos.

De acuerdo.

Un capacity planning nos ayudará a tener ciertas ideas para ver que umbrales de aumento de demanda podemos afrontar. Ahora bien, la planificación de infraestructura queda sujeta a las asignaciones de presupuesto y a la aprobación por parte de la dirección de la BCN.

DS4 – Asegurar la continuidad del servicio: plan de continuidad, recursos críticos, recuperación de servicios, copias de seguridad.

De acuerdo.

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.

Document Metadata

Table of Contents

ACTA DE RECEPCION Y APROBACION INFORME TECNICO

Document Metadata