Universidad de La SerenaCentro de Informática y Computación

Informe del Proyecto de Renovación Global de Tecnologías de Información y Comunicaciones para la Universidad de La Serena,

Proyecto Phoenix.ULS

Autor: René Felipe Viancos Soto (rviancos@gmail.com)

Resumen. El presente informe trata del Plan de Renovación Global de Tecnologías de Información y Comunicaciones para la Universidad de La Serena (Proyecto Phoenix.ULS), con miras a establecer el sustento de las naturales y crecientes necesidades de mejora tecnológica en la institución dada la observación de carencia de sistemas informáticos de apoyo a la gestión institucional por parte de la CNA1, estableciendo las acciones, lineamientos y métricas necesarias para afianzar de forma sustentable las proyecciones y crecimiento futuro de la institución en materia tecnológica ligada a su gestión. Se presenta el problema tecnológico/organizacional actual, un detalle de las tecnologías y arquitectura de hardware y software utilizadas para resolverlo, además de las metodologías empleadas de gestión del cambio con una mirada analítica aplicada a las organizaciones humanas en este contexto tecnológico, definiendo claramente el contexto teórico y práctico con el que el Proyecto Phoenix.ULS fue abordado, con una visión cuantitativa de la realidad previa, con objeto de disminuir los riesgos existentes (cambio organizacional, obsolescencia tecnológica, resistencia al cambio) y los riesgos que surgirían durante su realización e implantación de los productos y arquitectura de hardware y software utilizados, presentando las mejoras validadas por auditorías externas.

Palabras clave: Renovación Tecnológica, Gestión de Cambio Organizacional, Analiticidad, Ingeniería de Software, Bases de Datos, Redes, Seguridad de la Información. 1 Introducción

1.1 Organización de Informe.

El presente informe se ha estructurado en 5 macro partes:

La primera corresponde a la definición del marco actual en que se desarrolla el proyecto, donde se presenta la situación institucional que llevó a su realización, así como la presentación del estado tecnológico de la institución avalada por auditorías externas y dictámenes de Acreditación. El marco teórico en este trabajo dada su extensión y cantidad de áreas que abarca puede ser consultado en los anexos, donde se encuentran algunos de los conceptos más importantes que permitan clarificar tópicos de este trabajo (Titulo 1).

La segunda parte presenta la hipótesis de este documento, el objetivo General y los objetivos específicos a lograr. (Títulos 2 y 3)

La tercera parte se esboza con el mayor detalle posible el desarrollo central del proyecto Phoenix.ULS y los aspectos más importantes abordados dentro de él, presentando la metodología con la cual se enfrentó, utilizando teoría de sistemas aplicada a las organizaciones humanas y gestión del cambio tecnológico institucional, como ejes estratégicos en el desarrollo del proyecto

(Título 4)

1 Comisión Nacional de Acreditación. http://www.cnachile.cl - visita realizada en junio de 2014

1

La cuarta parte muestra como se lograron establecer remediales frente a las auditorias que realizaron auditores externos a la institución, mediante el desarrollo del proyecto Phoenix.ULS (Título 5).

La sexta parte corresponde a las conclusiones más relevantes logrados en base a los objetivos planteados al inicio del trabajo, así como las referencias del documento (Títulos 6 y 7)

1.2 Situación Actual (Pre Proyecto Phenix.ULS)

La Universidad de La Serena (ULS) es una Universidad del Estado de Chile, perteneciente al Consejo de Rectores y al Consorcio de Universidades Estatales. Cuenta con seis campus con presencia en tres ciudades de la Región de Coquimbo: La Serena, Coquimbo y Ovalle. Posee actualmente una cantidad aproximada de 8.000 estudiantes de pregrado y unos 200 de post-grado.2

Dentro del primer proceso de Acreditación de entidades de educación superior en Chile realizada por la Comisión Nacional de Acreditación de Pregrado (Ex CNAP, hoy CNA), la ULS aceptó someterse voluntariamente al proceso de acreditación institucional en el año 2005; como resultado del proceso, obtuvo 2 años de acreditación. Por parte de la CNA se obtuvo un informe de las fortalezas y debilidades detectadas en las áreas en las cuales se acreditó en dicha oportunidad (gestión institucional y docencia de pregrado).

La CNA fue muy clara al señalar una importante debilidad, plasmada en una observación presente en el acuerdo N° 63 de Acreditación Institucional, detectada por la comisión de pares evaluadores que visitó la ULS, específicamente en el área “Gestión Institucional”, donde se señala:

“La institución carece de sistemas informáticos de apoyo a la gestión en sus distintos niveles, que permitan un uso eficiente de los datos institucionales. La ausencia de indicadores se debe a la inexistencia de sistemas que permitan usar de manera eficiente, integrada y transversal los datos internos, y a la concentración excesiva de la función de planificación. Se tiende a la auto referencia, la concentración de funciones y al análisis descriptivo y general de la información institucional, lo que limita las posibilidades de crecimiento e innovación.” 3

Es por esta observación que la actual administración de la Universidad de La Serena tomó la decisión estratégica de efectuar una renovación total de toda su infraestructura tecnológica, de sistemas de información y de su red de datos, dada su actual obsolescencia, con objeto de dar sustento el crecimiento que se requiere para el futuro, con miras a tener un apoyo tecnológico organizacional adecuado parar aumentar los períodos de acreditación institucional, y tener información en línea para la toma de decisiones.

Esta carencia de sistemas informáticos de apoyo a la gestión de la institución se debe principalmente a la obsolescencia tecnológica del hardware y software que sostenían los sistemas de información universitarios

2 Sitio Web Universidad de La Serena: http://www.userena.cl - visita realizada en mayo de 20143 web CNA: http://www.cnachile.cl/res/inst/RES-INST-00053-01.pdf , Acuerdo N° 63 de acreditación institucional de la ULS, suscrito con la CNAP (hoy CNA), - Visita realizada en Noviembre de 2013.

2

Figura 1. Organigrama - Universidad de La Serena. Fuente: Sitio Web de la Universidad de La Serena –

http://www.userena.cl

(Docentes, Financieros y Administrativos) con servidores que al inicio del proyecto tenían entre 15 y 18 años de obsolescencia técnica y ya no se tenía servicio técnico en la zona ni forma de conseguir repuestos en corto plazo pese a tener mantención pagada, con lo que cualquier falla de hardware significaría la inutilidad de los sistemas informáticos, llevando a una paralización de las actividades de la universidad por un tiempo indefinido, significando un costo muy alto sólo por mantener sistemas legados.

Adicionalmente la red de datos estaba con equipamiento en similar condición de obsolescencia y con el 70% del cableado estructurado con más de 10 años de instalación y sin evidencia de certificaciones, sin administración de la red y caídas recurrentes de sus servicios, además de las cuantiosas vulneraciones a la seguridad de los sistemas, cuyo único resguardo ante accesos no autorizadas a los servidores y bases de datos era la realización de respaldos de la BBDD cada 1 o 2 días, y cada 2 horas en procesos con alta concurrencia de usuarios (matriculas, inscripción de asignaturas, poblamiento de actas de notas, etc.)

Hasta el año 2008, los sistemas de información de la Universidad de La Serena estaban basados en su totalidad por antiguos sistemas basados en terminales de texto por medio del protocolo telnet y sus aplicaciones estaban desarrolladas en el lenguaje de información Informix 4GL, y por terminales AS/400 de IBM con aplicaciones desarrolladas en lenguaje COBOL.

Figura 2. Plataformas informáticas previas de desarrollo propio al proyecto Phoenix.ULS. Fuente: elaboración propia

Estas aplicaciones sólo intercambiaban información por procesos diarios, manuales y por lotes, mediante archivos de texto plano. los sistemas desarrollados en lenguaje 4GL, se ejecutaban en el mismo servidor donde estaba la base de datos Informix (versión 5.2) lo que sumado al acceso a la misma máquina, por medio del protocolo telnet (datos de usuario viajan en texto plano por la red) hacen que este sistema sea sumamente vulnerable, y en alta concurrencia tenía un histórico de problemas de rendimiento, sobre todo en procesos de acceso masivo como la toma de asignaturas para más de 8 mil alumnos, sin mediar ningún parcelamiento en el acceso a las interfaces y aplicaciones en el proceso, es decir, los 8 mil alumnos pueden acceder sin restricción a los sistemas web para realizar la reserva de los cupos de las asignaturas.

Además, los sistemas informáticos que eran utilizados en la universidad, eran sistemas totalmente atomizados y que se encontraban programados en diferentes lenguajes, como COBOL o Informix 4GL y algunos desarrollos en ASP, y en diferentes plataformas (System/36 o AIX o Windows NT 4 Server), básicamente sin comunicación entre sí, con una ausencia total de sistemas que entregaran una alta

3

Figura 3. Visión general de los sistemas informáticos, previos al proyecto Phoenix.ULS donde se muestra la

atomización existente entre las diferentes arquitecturas y bases de datos de cada

sistema. Fuente: elaboración propia

disponibilidad de servicio. Esta atomicidad convertía a la arquitectura de software montada en un recurso poco confiable y prácticamente intolerante a fallas, aunque se realizan tareas específicas de forma eficiente, era cada vez menos escalable y mantenible en el tiempo, además de otros problemas que surgían de procesos realizados de forma manual, que tenían como resultado datos duplicados, redundantes e incluso en algunos sistemas datos desactualizados.

Lo expuesto dejaba en evidencia ante auditorías de calidad y procesos, auditorías de estados financieros, y auditorías informáticas, que la confiabilidad de los datos y la información emanada de los sistemas informáticos de la ULS era baja. Es por esta razón que se realizó una Auditoría completa que abarcase todas las mencionadas, para tener una realidad cuantitativa y cualitativa de los problemas a resolver y así poder realizar un levantamiento de las necesidades de mejora y una ingeniería de detalles ajustada a la realidad.

Los informes de auditoría entregan una matriz de riesgo, donde están presentes los puntos evaluados y visualmente exponen una primera mirada a los problemas que puedan estar afectando el control interno, la seguridad de la información y consecuentemente, su confiabilidad. Actualmente el Centro de Informática posee tres dictámenes de estas auditorías externas, y en esta introducción comenzaremos presentando la primera matriz del primer dictamen, previo al proyecto Phoenix.ULS, el cual sirvió como diagnóstico y apoyo a la gestión de obtención de recursos financieros para abordar la necesaria renovación tecnológica, como se aprecia en la figura 4.

Cabe señalar que las instituciones estatales están obligadas por ley a someterse anualmente a una auditoria de estados financieros realizada por auditores independientes, como parte de los métodos de control establecidos por la Contraloría General de la República; y acorde a los nuevos tiempos, estas auditores, con objeto de determinar la confiabilidad de la información recopilada en dicho proceso, efectúan adicionalmente una completa auditoria informática, de la cual se emite un conjunto de observaciones que deben en lo posible ser resueltas para el periodo siguiente en que la institución volverá a ser auditada. Esta auditoría informática verifica acuciosamente los niveles de seguridad y problemas de control interno que coloquen en riesgo el acceso no autorizado a los sistemas y datos de la institución (seguridad de la información y confiabilidad de los datos).

Figura 4. Matriz de severidad riesgo en la seguridad de la información previa al proyecto Phoenix.ULS. Fuente: Dirección de Finanzas de la ULS.

Frente a este escenario se tomó la decisión de efectuar un reemplazo de los sistemas de información y administración universitaria, desarrollando de forma autónoma la plataforma de gestión de la docencia, y adquiriendo la plataforma de gestión financiera y administrativa que utiliza la Contraloría General de la

4

República con su código fuente, tal como se mencionó anteriormente. Todo lo anterior abordados con un enfoque que cuide el aspecto técnico así como la gestión del cambio tecnológico, de forma paralela. Lo anterior conllevaría la renovación completa del datacenter institucional (servidores, enlaces, etc.) y la red de datos institucional a nivel de equipos de comunicaciones, cableado estructurado, enlaces inter campus y la administración de la red; todo con un diseño físico y lógico que privilegie la seguridad de la información, para lo cual se realizarían evaluaciones tecnológicas de rigor, así como la contratación de consultorías especializadas en temas relacionados a la gestión de cambio y seguridad de la información, y sus detalles de implementación se pondrán en evidencia en el presente trabajo.

2 Hipótesis

La renovación global de tecnologías de información de la Universidad de La Serena presenta como primera hipótesis que la renovación global de TI en la ULS permitirá de forma satisfactoria y exitosa introducir nuevas tecnologías para administrar y gestionar el quehacer académico, estudiantil, administrativo y financiero, convirtiendo su actual debilidad4 en el área TI en una gran fortaleza, con bajo impacto organizacional, lo que permitirá mejorar la gestión universitaria de forma transversal. También se plantea una segunda hipótesis complementaria en el ámbito TIC y Cambio Organizacional que postula que la provisión de nuevos sistemas informáticos basados en interfaces web facilitará la gestión del cambio organizacional. Ambas hipótesis acompañadas del reemplazo total de sistemas informáticos y de comunicaciones, reducirán la incertidumbre del usuario ante la presencia de nuevas tecnologías y sistemas de información, promoviendo una nueva forma de trabajar, reduciendo los esfuerzos de mantenibilidad de las aplicaciones en cada cliente, con el consecuente aplanamiento de la curva de aprendizaje sobre la provisión de los nuevos sistemas.

3 Objetivos

3.1 Objetivo general

Reemplazo de toda la infraestructura tecnológica que soporta a los sistemas informáticos de la Universidad de La Serena dado su elevado nivel de obsolescencia, plataformas de administración docente y curricular, plataformas de administración financiero/contable, infraestructura de telecomunicaciones e infraestructura de seguridad de la información en general, considerando como factor clave de éxito la gestión del cambio organizacional para un proyecto TIC de esta envergadura, abordándolo sistémicamente para apoyar a las unidades encargadas de establecer métricas de mejora y gestión institucional de forma cuantitativa y cualitativa apoyados en la provisión tecnológica producidas por el proyecto Phoenix.ULS por medio de la utilización de tecnología web para reducir la incertidumbre y curva de aprendizaje de los nuevos usuarios.

3.2 Objetivos específicos

Los objetivos específicos de este proyecto son los siguientes:

● Analizar sistémicamente a la Universidad de La Serena empleando analiticidad desde el punto de vista de las organizaciones humanas, en un contexto tecnológico y de sistemas de información [5] aplicando rediseño y reingeniería a los procesos principales de la institución y documentando dichos procesos usando notación BPMN mediante una suite BPM.

● Desarrollar de forma inmediata un sistema de apoyo a la gestión institucional utilizando tecnologías web inicialmente y luego en tecnología Business Intelligence.

● Desarrollar una Plataforma Tecnológica Docente Integrada (PTDI) con una única base de datos institucional y centralizada [1], abarcando todos los aspectos del ámbito académico y de gestión curricular en conjunto con una plataforma de comunicación corporativa que reemplace al actual servidor de correo electrónico institucional, junto a la adecuación de la plataforma Moodle dada la necesidad de proveer herramientas para el cuerpo académico de la universidad que sincronicen la

4 web CNA: http://www.cnachile.cl/res/inst/RES-INST-00053-01.pdf - Visita realizada en Noviembre de 2013

5

oferta académica de PTDI y la ejecución de las asignaturas, automatizando la gestión curricular institucional.

● Adquirir y adecuar el sistema financiero contable que utiliza la Controlaría General de La República para la administración de los recursos financieros de la institución.

● Instalar y Aplicar recomendaciones de normas ISO 9001, ISO 20.000 e ITIL a los procesos tecnológicos institucionales, mediante el desarrollo de una plataforma de soporte basada en CRM que centralice todos los requerimientos tecnológicos de la comunidad universitaria.

● Diseñar y renovar la red de datos de la ULS con un core Ethernet de 10 Gbps, ya que la renovación de sistemas de información universitarios debe ir acompañada de una renovación completa de la red de datos de la Universidad para mejorar la calidad de los servicios entregados a través de su red, y que esta sea 100% administrada para disminuir los riesgos asociados a la seguridad de la información.

● Resolver los problemas evidenciados en la primera acreditación institucional referentes a la carencia de sistemas informáticos de apoyo a la gestión institucional

4 Desarrollo

Tal como se menciona en párrafos anteriores, el proyecto Phoenix.ULS se trata de una apuesta estratégica traducida en renovar la totalidad de los sistemas de información actuales junto a toda la infraestructura de red y equipos de comunicaciones y de seguridad asociados.

Se dio inicio realizando visitas a otras universidades e instituciones estatales principalmente, para ver en terreno como satisfacían sus necesidades TI educativas y financieras, a modo de tener claridad sobre el estado del arte de forma empírica sobre las soluciones aplicadas en la gestión de instituciones de educación superior símiles, además de conocer los detalles tecnológicos y la arquitectura de software en que se sustentaban. Se encontró un amplio espectro de soluciones, algunas con suites completas de administración compradas a un proveedor externo (SAP, Banner, SUNGARD, etc.), desarrollos propios completos, y otras instituciones con suites híbridas de desarrollos propios integrados con desarrollos de terceros. También se encontraron situaciones de obsolescencia y atomización de sistemas, mayoritariamente en universidades estatales y minoritariamente en universidades privadas.

Toda la información obtenida se tabuló en una gran matriz y posteriormente realizo un análisis FODA con directrices estratégicas y clasificadas, agregando la información obtenida de levantamiento inicial de requerimientos a usuarios académicos, administrativos, directivos y estudiantes, sumado a una primera auditoría de estados financieros en conjunto a una auditoría informática (ya mencionada en la introducción) y de seguridad de la información, con miras a tener un espectro claro y fundado de la situación actual y las necesidades emergentes, así como de las posibles soluciones, para mitigar los principales riesgos asociados al cambio organizacional que se realizaría, y prever los riesgos que adicionalmente se asociarían al reemplazo tecnológico que necesariamente estaba por venir.

La metodología de forma general está pensada como un proceso de diseño (reingeniería) y rediseño de procesos de negocios en la ULS, que permitan, por medio de una desagregación estratégico-organizacional, elaborar una ingeniería de detalles que permita canalizar eficientemente los recursos institucionales (presupuesto) para llevar a ejecutar el proyecto Phoenix.ULS con éxito en todas sus vertientes junto a una mirada principalmente sistémica.

Esta apuesta estratégica, desde un punto de vista sistémico, estaba basado en la construcción de un Sistema de Información Estratégica (SIE) para la Gestión Estratégica (GE) de la ULS (junta directiva y rectoría), y un Sistema de Información Estratégica Tecnológica (SIET) para la GE y la Gestión Operativa (GO) de la misma Vicerrectoría Académica (VA) y Vicerrectoría de Asuntos Económicos y Administrativos (VREA).

4.1 Desagregación analítica de la Universidad de La Serena

Dentro de los conceptos que enmarcan el objetivo de este apartado, Hammer y Champy definen a la reingeniería de procesos como “la reconcepción fundamental y el rediseño radical de los procesos de

6

negocios para lograr mejoras dramáticas en medidas de desempeño tales como en costos, calidad, servicio y rapidez”.[1]En esta definición podemos identificar claramente dos conceptos fundamentales; en la llamada reconcepción fundamental se enuncia el “diseño” de procesos de negocios, donde la organización ha tomado la decisión, desde un punto de vista estratégico, de rehacer todos los procesos de negocios; y sobre el “rediseño”, se nos presenta la opción donde la organización ha tomado la decisión, desde un punto de vista operacional, de redefinir e incorporar las actividades que sean necesarias para llegar al resultado esperado, ya que se ha visualizado (estratégicamente) que existe un grado de satisfacción y confiabilidad de los procesos de negocios (medidos operacionalmente), y se tienen identificadas las perturbaciones, para incorporar las instancias que se hagan cargo de todos los inputs y outputs, desde el punto de vista del pensamiento de sistemas.

Como caso de estudio del presente trabajo, explicaremos el origen y los alcances de la apuesta estratégica de la rectoría de la Universidad de La Serena (ULS), sobre el fortalecimiento de los sistemas informáticos de apoyo a la gestión institucional, desde la mirada y pensamiento de sistemas aplicado a las organizaciones humanas y la aplicación de la analiticidad desde la rectoría para efectuar una de las apuestas estratégicas más importantes en su gestión.

Punto de vista organizacional y tecnológico.

Analizando las fortalezas y debilidades, y frente a la observación mencionada del acuerdo N° 63 de acreditación institucional referente a la ausencia de sistemas informáticos de apoyo a la gestión institucional, rectoría junto al nuevo equipo directivo esbozó, a través de unidades simples, los componentes fundamentales que se identifican en una “organización humana”. En ese esquema estratégico-operacional se evidenció la ausencia de un sistema informático que pudiese entregar métricas, por medio de indicadores de gestión, que permitieran precisamente, y valga la redundancia, hacer gestión y tener a la universidad gestionada sistémicamente, es así como empleando teoría de sistemas aplicada a las organizaciones humanas, podemos precisar que se carece de un sistema de información estratégico (SIE), utilizado por la Gestión Estratégica (GE) de la organización, y se carece de un Sistema de Información Estratégico Tecnológico (SIET) que interactúe con la GE y con la gestión operacional (GO), lo que reconfirma y demuestra lo señalado por la CNAP en la primera acreditación institucional, como se puede apreciar en la Figura 5.

Figura 5. Carencia de Sistema de Información Estratégico (SIE) y de un Sistema de Información Estratégica Tecnológico (SIET). Fuente: Apuntes del profesor Ricardo Acevedo, Políticas Y Estrategia en Sistemas de

Información, Departamento de Informática, Universidad Técnica Federico Santa María - 2009

En el análisis que se realizó de la Universidad al asumir los cargos de las nuevas autoridades y directivos, se evidenció claramente que se tenía un gran desafío, re-acreditar a la ULS, y que para ello sólo quedaba un año de acreditación institucional vigente para lograr el objetivo, por lo que prontamente se debía tener total claridad de los inputs y las instancias que se hicieran cargo de ellos, proyectando como meta un periodo de acreditación superior al ya obtenido y la incorporación de nuevas áreas susceptibles de ser acreditadas.

7

Dentro de las apuestas estratégicas establecidas para lograr la anhelada re-acreditación, surgió un Objetivo Global emanado de la Gestión Estratégica de la institución, en base a la observación de la CNAP (acuerdo N° 63) referida a la ausencia de sistemas informáticos de apoyo a la gestión: renovar todos los sistemas de información y de comunicaciones de la Universidad, ya que si bien existía una unidad que hacía gestión (la dirección de planificación), no existía en los sistemas informáticos actuales un módulo de gestión ni bases de datos elaboradas teniendo este punto como parte de su diseño, por lo que la visión de la CNAP respecto a este punto era clara, había excesiva centralización en la unidad que realizaba el análisis de la información institucional, por medio de procesos manuales (planillas en Excel principalmente), sumado a que los sistemas informáticos existentes estaban en total obsolescencia y totalmente atomizados.

Con todo este escenario y frente a la mencionada apuesta estratégica, se esbozó el diagrama sistémico-organizacional-estructural de la Universidad de La Serena desde el punto de vista de sistemas, mostrando sus componentes como estructura compleja, desagregando la GE en el subnivel de inteligencia y subnivel de dirección superior, y la GO desagregada en subnivel de gestión global y subnivel de procesos operacionales, aplicando analiticidad. El diagrama elaborado por la Universidad no fue tan desagregado como el que estamos presentando, pero la desagregación lograda hoy, nos permite tener varias conclusiones en mente, que serán entregadas al final de este trabajo, por lo que mostramos, para aumentar la inteligibilidad al lector, dos esquemas: el organigrama jerárquico de la ULS (ver Figura 1), y la desagregación analítica de la ULS (ver Figura 6).

El objetivo global mencionado se tradujo en una apuesta estratégica plasmada en un proyecto prioritario de la actual administración de la universidad: el “Proyecto Phoenix de renovación global de tecnologías de información y comunicaciones”, el cual desde el punto de vista de sistemas y organización, resolvería la ausencia o no aplicación de un SIE y un SIET, y tendría un carácter transversal a toda la comunidad universitaria, desde la mirada estratégica, ya que aplicaría las tic para resolver los problemas de información y atomización de los actuales sistemas informáticos, aplicando diseño y rediseño en una primera etapa, de los procesos de negocios de 3 unidades clave (estratégicas), a saber: la dirección de docencia, la dirección de finanzas, y el centro de informática y computación. Esta última unidad tiene dependencia directa de rectoría, lo que tiene carácter estratégico dado la naturaleza de la misión de este centro.

4.2 Reingeniería y rediseño de Procesos de Negocio en la ULS.

Dentro del análisis (sistémico) realizado por rectoría, se identificaron 3 unidades reguladoras de procesos operacionales críticas desde un punto de vista estratégico en la primera etapa del proyecto Phoenix ULS, donde se debía intervenir para diseñar o rediseñar sus procesos de negocios; dichas unidades son: la Dirección de Finanzas (DF), la Dirección de Docencia (DD) y el Centro de Informática y Computación (CIC).

8

Figura 6. Desagregación analítica de la

Universidad de La Serena. Fuente:

Elaboración propia.

Dirección de Finanzas (DF).

En este contexto, la Dirección de Finanzas de la ULS tomó la decisión de aplicar reingeniería de procesos de negocios [7] por tres motivos principales: las observaciones sobre el “control interno” que arrojó la última auditorías de estados financieros realizada por auditores independientes, la incorporación desde el 1 de enero de 2008 de las universidades estatales a Chilecompra por mandato expreso de la Contraloría General de la República y el acuerdo número 63 de Acreditación Institucional5. Frente a este escenario, favorable desde el punto de vista del cambio organizacional, se evaluaron las alternativas de reemplazo de los sistemas informático-financieros, considerándolos como parte de la infraestructura crítica de la organización, asumiendo que los datos y la información de dicho sistema sería un insumo crítico para el Sistema de Información Estratégico (SIE) [5] institucional y un insumo de apoyo para el Sistema de Información Estratégico Tecnológico (SIET) [5], con dos caminos a seguir desde el punto de vista tecnológico/estratégico:

1) desarrollar una aplicación a la medida desde cero, o 2) adquirir una aplicación existente con su código fuente y adaptarla según necesidad específicas.

Luego de la evaluación por parte del equipo directivo involucrado, la opción elegida fue la segunda: adquirir un sistema existente, optando por la misma aplicación financiera que se utiliza en la Contraloría General de la República, llamado IconSystems 10g, ya que el impacto de incorporación debiese ser bajo al tratarse de un sistema utilizado por un organismo que regula a los organismos estatales, cuya estructura presupuestaria (y contable) y los procesos asociados es similar en un 90% a la estructura de la ULS, basada en programas (o proyectos) presupuestarios, susceptibles de percibir ingresos (presupuestados o auto-financiados) y de realizar egresos, con respaldos contables (a groso modo, contabilidad presupuestaria), sin perjuicio de que la forma de trabajar del personal de la Dirección de Finanzas cambiaría radicalmente al tener incorporada en la aplicación

el concepto de “control interno” en cada uno de sus subsistemas, haciéndolos más seguros y fiables antes las auditorías de estados financieros a las que se someten anualmente los organismos estatales.

Junto con la implantación de este sistema informático financiero, y su adecuación a necesidades específicas (a nivel de reportes de gestión principalmente y algunas funcionalidades específicas), se elaboró un nuevo documento regulatorio formal de manejo del presupuesto de la universidad, llamado Compendio Presupuestario, lo que equivale a un manual procedimental para todas las actividades que requieren manejo de recursos financieros y documentos contables. Este manual se elaboró basándose en normas ISO 9001-2000,

5 web CNA: http://www.cnachile.cl/res/inst/RES-INST-00053-01.pdf , Acuerdo N° 63 de acreditación institucional de la ULS, suscrito con la CNAP (hoy CNA), - Visita realizada en Noviembre de 2013.

9

Figura 7. Plataforma Tecnológica Financiera Integrada(PTFI), módulo de recaudación. Fuente: Elaboración propia.

para tener garantía de que lo realizado tuviese sustento respecto mejores prácticas en la gestión de calidad al interior de la Dirección de Finanzas, para lo cual se contrató un especialista en sistemas de gestión, diseñando nuevos procedimientos normalizados apoyados en la notación BPMN, asignando responsabilidades, y creando perfiles y cargos acordes a las nuevas actividades, pasando desde un esquema funcional a un esquema basado en procesos, utilizando un modelador BPM.

Dirección de Docencia

En esta unidad se aplicó un rediseño de los procesos de negocio, basándose en su misión: “…la dirección de docencia tiene como misión fundamental planificar, coordinar y controlar todos los aspectos relacionados con la administración del currículum de las carreras que imparte la Universidad de La Serena”6.

En esta unidad reguladora docente, si bien existen procedimientos administrativos que regulan sus procesos, estos estaban apoyados en sistemas informáticos atomizados o procesos manuales y muy burocráticos, que solo intercambian información por medio de archivos batch o firmas/autorizaciones de múltiples actores, sin ningún cruce ni relaciones implícitas, por lo que al incorporar nuevas tecnologías, basadas en entorno web y bases de datos relacionales se optó por desarrollar una solución de software para la gestión docente denominada Plataforma Tecnológica Docente Integrada (PTDI), desde donde surgieron nuevas necesidades

durante su desarrollo e implantación, y producto del cambio del comportamiento de los usuarios en su forma de trabajar después de las primeras entregas, surgieron nuevas actividades y labores de desarrollo que hicieron mejorar la calidad de la respuesta esperada de esta unidad académica frente a la comunidad universitaria.Para trabajar e identificar los procesos operacionales que tenían relación con otras unidades, se contrató personal adicional para soportar la generación de la documentación asociada a sus procedimientos, todo basado en norma ISO 9001.

6 web CNA: http://www.cnachile.cl/wp-content/uploads/2010/07/acuerdo_ai_n63_uls.pdf, acuerdo N° 63 de acreditación institucional de la ULS, suscrito con la CNAP (hoy CNA), visita realizada en diciembre de 2010

10

Figura 8. Plataforma Tecnológica Docente Integrada (PTDI), módulo de estadísticas

(Desarrollo de Software Autónomo). Fuente: elaboración propia

Centro de Informática y Computación (CIC)

Esta unidad como tal, es la gestora y responsable del Proyecto Phoenix.ULS, y depende directamente de rectoría (lo cual es estratégico). Dicho proyecto es el resultado de la comunicación por parte de rectoría del Objetivo Global de re-acreditar a la Universidad, y la apuesta estratégica orientada a resolver la debilidad señalada en el acuerdo de acreditación N° 63 de la CNAP, y convertirla en una gran fortaleza. Esta apuesta estratégica, desde un punto de vista sistémico, estaba basado en la construcción de un SIE para la GE de la Universidad, Junta Directiva y Rectoría, y un SIET para la GE y GO de la misma, Vicerrectoría Académica (VA) y Vicerrectoría de Asuntos Económicos y Administrativos (VREA).

Adicionalmente, al igual que en las demás unidades, se incorporó el mismo sistema de gestión de calidad basado en normas ISO 9001, pero además, los procedimientos e instructivos técnicos fueron elaborados y operativizados bajo norma ISO 20.000 (mesa de soporte / mini call center, equipo de soporte en 3 niveles, plataforma de trouble ticket), y todo el personal del CIC asistió en dedicación exclusiva a cursos de preparación en ITIL7, ISO 20.000 y recientemente en Cobit8.

Cabe mencionar que el Centro de informática y Computación es responsable por decreto del desarrollo y mantenimiento de los sistemas informáticos de la ULS, y por ende responsable en gran medida de la observación emanada de la CNAP respecto a la ausencia de Sistemas de Información para la gestión, por lo que el proyecto Phoenix.ULS tiene como objetivo transversal, realizar una renovación de imagen frente a la comunidad universitaria en general, principalmente sobre su quehacer y su gestión, y para lograrlo, se requeriría si o si la renovación en paralelo de la infraestructura de la red de datos de la ULS, también en obsolescencia y colapsada en términos de tráfico (deseado y no deseado), con muchos dominios de colisión y con un performance en degradación constante, con consecuencias tales como reiteradas caídas en el acceso de los servicios desde y hacia internet, así como saturación y caída recurrente de los servidores de aplicaciones y BB.DD. de la intranet, sobre todo en alta concurrencia (más de 5000 usuarios) desde internet en períodos pic, y mediana concurrencia (2000 estaciones de trabajo en la LAN y WAN Universitaria).

Para soportar lo anterior, se creó una nueva área en el CIC, el “Área de Desarrollo e Ingeniería de Software”, y se contrataron 6 ingenieros en computación egresados de la ULS, por tener en su currículum la especialidad de Ingeniería de Software, completando la nueva reestructuración del CIC con el establecimiento del siguiente organigrama.

7 ITIL: Conjunto de buenas prácticas para la administración de servicios TI. http://www.itil-officialsite.com/ , visita en Agosto de 20148 Cobit: Framework para el Gobierno de las TI. http://www.isaca.org/cobit/pages/default.aspx , visita realizada en Agosto de 2014

11

Figura 9. Nuevo organigrama del CIC de la ULS. Fuente: Elaboración propia.

Plataforma de Soporte y Help Desk institucional

Adicionalmente, y como fuente primaria para establecer métricas de mejora en este trabajo, se implementó una plataforma de soporte tecnológico, conocidas comúnmente como trouble ticket plattforms, el cual es el medio oficial y central para que la comunidad universitaria plantee sus problemas y/o necesidades tecnológicas.

Gracias a la implantación de esta plataforma CRM/CRQ9 de gestión tipo Help Desk, es posible llevar un análisis cuantitativo y estadísticas de cada área del CIC, monitoreando a sus responsables, los tiempos de respuesta, y muchas herramientas de gestión efectiva de las necesidades tecnológicas de la comunidad universitaria. A continuación se muestra la evolución de los requerimientos de soporte desde la puesta en producción de esta aplicación.

4.3 Arquitectura de Software implementada

El escenario presentado, si bien parece desfavorable desde un punto de vista tecnológico, desde el punto de vista del cambio organizacional presenta una gran ventaja: todos los usuarios, académicos, administrativos y estudiantes pedían una renovación tecnológica total. Es así como por medio de la dirección del centro de informática, rectoría canaliza los recursos necesarios para renovar toda la infraestructura tecnológica de la Universidad de La Serena, sistemas informáticos y de comunicaciones, pero con una gran prerrogativa: el 100% de los sistemas (desarrollados y/o comprados) debe poder ser utilizado (y administrado) vía web. Este punto es donde la innovación y el apoyo y decisión de las autoridades superiores de la Universidad de La Serena aparecen como eje clave para el éxito del proyecto.

9 CRQ: Client Resource Queue

12

Figura 10. Plataforma de soporte del Centro de Informática y Computación de la ULS. Fuente: Elaboración propia.

Tal como se mencionó anteriormente en este documento, se buscaron en el mercado (público y privado), las distintas alternativas de software para la gestión universitaria que existían, ya implementadas en otras universidades, planteándose:

● Adquirir la plataforma de otra casa de estudios superiores y adaptarla con asesoría de esa misma institución

● Adquirir la plataforma a una firma de software comercial (SAP, Banner, SUNGARD)● Desarrollar la plataforma con recursos propios

Después de un exhaustivo análisis de pre-ingeniería, realizando una evaluación de éxito de la integración de estas soluciones en las distintas universidades, se tomaron las siguientes decisiones de implementación para la arquitectura de software del proyecto:

Virtualización de los servidores de misión crítica utilizando Citrix XenServer (y balanceados con el clúster de balanceadores de servidores y enlaces) y virtualización de estaciones de trabajo utilizando Citrix XenDesktop 5.5 (acceso a sistemas operativos de usuario mediante Thin Clients por hardware y/o software).

Reemplazo de sistemas operativos para las aplicaciones de misión crítica (sistemas académicos y sistemas financieros/administrativos y respectivas BB.DD.) desde IBM AIX 4.3 a Redhat Linux Enterprise 5.1

Reemplazo del motor de base de datos Informix 5.2 a Oracle 10g r2 de 64 bits para Linux y reingeniería de los modelos de datos existentes.

Desarrollo propio de los sistemas informáticos académicos (PTDI), basados en arquitectura web, utilizando Apache como servidor y PHP como lenguaje, acompañado de tecnologías web 2.0 (AJAX) en el lado del cliente y servidor, contratando ya en este momento 7 ingenieros en computación de la Universidad de La Serena, agregando un encargado responsable de la ingeniería de requerimientos y sus metodologías10.

Adquisición con su código fuente del ERP utilizado por la Contraloría General de la República para la administración de los recursos financiero/administrativos, el cual está basado en arquitectura Oracle Forms11, el que a su vez está montado sobre Oracle Application Server versión Enterprise12, un servidor de aplicaciones java propietario de Oracle.

La comunicación entre ambos sistemas (académico y financiero/administrativo) se normó estableciendo como eje central de intercambio y actualización de información la utilización de procedimientos almacenados, dejando fuera de protocolo cualquier consulta directa sobre las tablas de cada sistema.

Lo anterior se puede apreciar en el bosquejo de la arquitectura preliminar para el proyecto Phoenix, presente en la Figura 11, la cual contendría conceptualmente servidores de aplicaciones en base a alguna arquitectura por definir, y una sola base de datos central.

10 http://www.alumnos.inf.utfsm.cl/~rrossel/Papers/re.pdf11 http://www.oracle.com/technetwork/developer-tools/forms/overview/index.html12 http://www.oracle.com/us/products/middleware/application-server/enterprise-edition/index.html

13

Figura 11. Arquitectura preliminar para el proyecto Phoenix.ULS. Fuente: Elaboración propia.

4.4 Ingeniería de Software y evolución de los métodos de desarrollo ágil en la ULS [8]

Desde el punto de vista de la Ingeniería de Software, (visión estratégica), uno de los objetivos principales es establecer una macro metodología (Framework) que nos permita guiar el ciclo de vida de los productos desarrollados dentro del CIC, estableciendo indicadores que permitan decidir la forma de abordar el desarrollo de las aplicaciones de acuerdo a métricas que serán establecidas en el presente trabajo, por ejemplo, dependiendo del número de horas/hombre y la disponibilidad de aquel recurso, conformando y midiendo indicador de riesgo, se podrá decidir la metodología de desarrollo (XP13, SCRUM14, etc.) o justificar la necesidad de inyectar recursos para mitigar el riesgo de retraso en la entrega del producto terminado.

Por otro lado, se debe establecer una Arquitectura de software (visión operativa) que siente las bases para lograr el desarrollo del Framework, estableciendo una guía formal para el desarrollo de las nuevas aplicaciones y migración de las existentes, con el objetivo de optimizar el rendimiento en ambiente productivo, sin tener que hacer mejoras en la infraestructura actual con la que cuenta el CIC, sin sobredimensionar recursos de computo, con un impacto directo en la mejora del rendimiento del producto de software final, aprovechando las potencialidades que brindan los lenguajes de programación como JavaScript y PHP para el desarrollo de aplicaciones Web utilizando AJAX.

Previo al inicio del proyecto Phoenix.ULS, en el CIC se desarrollaban aplicaciones en lenguajes como 4GL y Cobol, cubriendo necesidades inmediatas de información de las diferentes unidades de la universidad. El personal del CIC abordaba este tipo de requerimientos siguiendo una metodología de desarrollo estructurada, con ciclos en cascada. Si bien los requerimientos para esa época eran bastante sencillos y permitían utilizar este tipo de metodologías, el crecimiento de la Universidad, y por lo tanto de las necesidades de contar con nuevas y modernas herramientas de gestión, hacían imposible seguir trabajando de esta forma.

En cuanto al desarrollo de los nuevos sistemas académicos y administrativos, se puede decir que se pasó por 3 diferentes etapas, en cada una de las cuales se adoptaron diferentes formas de enfrentar el desarrollo y sobre todo los requerimientos y exigencias del proyecto.

Primera etapa: toma de requerimientos.

Momento en el cual todas las unidades que hasta ahora no habían obtenido una total satisfacción en cuanto a sus necesidades de información volcaron sus miradas en este nuevo proyecto, lo que resulto en una gran cantidad de requerimientos, aunque la mayoría vagamente definidos o enfocados. En esta etapa también se debía demostrar que el proyecto Phoenix.ULS estaba avanzando y dando frutos casi inmediatos, por lo cual se debía mostrar avances en el corto plazo.

Con un nuevo equipo humano de desarrollo de software y objetivos definidos al corto plazo, se comienza a incorporar nuevas metodologías de trabajo en lo que respecta al desarrollo de software. En primera instancia los requerimientos de información crecieron de forma abrupta al conocerse que este nuevo proyecto realizaría la renovación de los sistemas informáticos institucionales, por lo que las diferentes unidades plantearon sus necesidades todas con alta prioridad, pero que constantemente sufrían cambios. En resumen, los requerimientos planteados eran:

13 http://www.ia.uned.es/ia/asignaturas/adms/guiadidadms/node68.html14 http://www.proyectosagiles.org/que-es-scrum

14

● De suma urgencia.● Críticos.● Medianamente claros o definidos.● De constante cambio.● Con un ámbito que solo uno o dos usuarios manejaban en un

100% en cada unidad.

Ante este escenario de trabajo, se optó por utilizar algunas mejores prácticas de metodologías ágiles, especialmente XP, sabiendo que la característica principal de este tipo de metodologías es que son más “adaptables” que “predictivas”15. Entre las características que se consideraron para ser aplicadas dentro del equipo de desarrollo en esta primera etapa fueron16:

● Integración del “cliente”, lo que fue un paso importante en el desarrollo de las aplicaciones, ya que permitía obtener retroalimentación directa del desarrollo realizado.

● Mínima documentación, considerando como indispensables ciertos documentos básicos como los requerimientos, flujos, etc.

● Desarrollo iterativo e incremental, definiendo pequeñas entregas funcionales a las que luego se le incorporarían nuevas funcionalidades según como los requerimientos se presentaran.

● Programación en parejas, donde un desarrollador codificaba y su compañero servía de apoyo y efectuando rotaciones.

● Refactorización del código, revisando y corrigiendo cualquier defecto antes de incorporar nuevas funcionalidades.

● Propiedad colectiva del código, lo que proporcionaba cierto respaldo ya que siendo un equipo nuevo, estabasiempre latente la posibilidad de que algún integrante dejara al equipo.

Utilizando estas prácticas, se llegó a una primera entrega, con la cual se llevó a cabo el proceso de matrícula de alumnos con ingreso vía PSU el año 2008, mostrando herramientas y funcionalidades que con los anteriores sistemas no era posible proporcionar, como la entrega de estadísticas en línea, ejecutivos de matrícula “multi-carrera”, emisión de certificados de alumno regular en el momento de matricularse, etc.Segunda etapa: posterior a las primeras entregas y avances.

Una vez que se pudo mostrar un primer avance de cómo las nuevas plataformas apoyarían a los procesos institucionales, las diferentes unidades vieron que efectivamente podrían utilizar estos avances como una herramienta de apoyo a sus actividades cotidianas, por lo que ahora los requerimientos fueron más enfocados y específicos, aunque siempre se mantenía la característica de cambios en último momento. Si bien los avances ya se habían mostrado, ahora las autoridades querían más resultados positivos y la entrega final del proyecto, lo que mantenía el sentido de urgencia en cuanto a finalizar el desarrollo.

En esta etapa las entregas estaban bien definidas en cuanto a su alcance y se necesitaba dividir el trabajo de forma diferente, incluyendo cierta etapa de planificación e informando del estado

15 http://www.programacionextrema.org/articulos/newmethodology.es.html16 http://es.wikipedia.org/wiki/programaci%c3%b3n_extrema

15

Figura 12. Ciclo de vida de los productos de software. Fuente: Elaboración Propia

Figura 13. Pérdida de recursos durante el ciclo de vida de los

productos de software.

de avance de cada “submódulo” que se desarrollaba. Bajo estas características, se hacía necesario incorporar características de gestión del desarrollo involucrando al “cliente” dentro del proceso.

Bajo este nuevo escenario, se decidió adoptar prácticas de SCRUM17 para gestionar el proyecto. Se incorporaron:

● Reuniones diarias para saber el estado de los desarrollos dentro del equipo completo y cada sub-módulo (Daily Scrum).

● Reuniones con el “cliente” donde él mismo participaba en la definición de las prioridades y funcionalidades que se incorporarían en cada entregable (stakeholder).

● Reuniones de planificación cada 15 días (planificación del sprint).● Reuniones de revisión del avance (revisión del sprint)

Con la incorporación de estas características de Scrum, se llevó a cabo el desarrollo del total del proyecto de renovación de sistemas informáticos de la Universidad de La Serena, el cual comenzó su marcha blanca en producción el año 2009, incorporando entre los procesos que cubría: matrícula de alumnos ingreso vía PSU, ingreso de la oferta académica semestral y anual, inscripción de asignaturas (para una cantidad de aproximadamente 8.000 alumnos), ingreso de actas de notas, entrega de certificados, reportes, estadísticas, realización de encuestas en línea [11], etc.

Tercera etapa: posterior a la entrega formal de las plataformas institucionales.

Cuando las plataformas estuvieron ya implantadas en un 100% en base a los requerimientos iniciales, lo que significaba la entrega formal del proyecto, se comienza con la etapa de mantención e integración de nuevas funcionalidades no consideradas en los requerimientos iniciales. Cada uno de estos nuevos desarrollos se lleva a cabo como un sub-proyecto individual, para los cuales se seleccionan diferentes metodologías dependiendo de las características de cada uno.

Primero se evalúa la complejidad de cada sub-proyecto, dividiéndolo en etapas y basándose en la cantidad de h/h requeridas para dar cumplimiento a lo solicitado, con lo cual podríamos resumir las metodologías utilizadas de la siguiente forma:

Para desarrollo de baja complejidad, se encarga el desarrollo a un solo miembro del equipo, que generalmente utiliza un ciclo de vida iterativo18. Por ejemplo para la creación de nuevos reportes o estadísticas en línea.

Para desarrollo de mediana complejidad, se utilizan prácticas de XP como la programación en parejas y revisiones continuas del producto en conjunto con el “cliente”. Por ejemplo en el caso de solicitar la modificación de algún módulo de la plataforma o la generación de una funcionalidad completamente nueva de un módulo en particular.

Para desarrollos de alta complejidad, se utilizan prácticas de XP en conjunto con prácticas de Scrum para la administración y designación de equipos, ya que es necesario dividir el desarrollo en Sprints. Por ejemplo si se solicita un módulo completamente nuevo no considerado en los requerimientos iniciales y donde se requiere especialmente de la participación del “cliente” en la selección de las funcionalidades de cada entrega.Por último, es necesario mencionar, que previo al inicio de la 2da etapa, ya se había logrado implantar prácticas de trabajo dentro del equipo que facilitaron la continuidad del proyecto de desarrollo, como por ejemplo el definir un “estándar de codificación” y un “estándar de diseño de bases de datos” y una serie de instructivos técnicos para la “gestión de la configuración del software”19.

Desarrollo ágil y la utilización del lenguaje PHP como herramientas de desarrollo.

17 http://www.proyectosagiles.org/que-es-scrum18 http://www.javiergarzas.com/2010/01/veterano-ciclo-de-vida-iterativo-incremental.html19 http://www.ia.uned.es/ia/asignaturas/adms/guiadidadms/node68.html

16

En cuanto a la experiencia que se obtuvo del desarrollo de las plataformas académicas y administrativas del proyecto Phoenix.ULS, el uso del lenguaje PHP20 como base para la codificación fue una buena elección, ya que es un lenguaje de fácil manejo, con el cual se puede generar código rápidamente, de forma ordenada y clara, facilitando la comprensión por parte de otros desarrolladores, punto muy importante a la hora de utilizar trabajo en parejas, rotaciones o revisiones, como lo que se hace al utilizar prácticas de XP.

La existencia de herramientas como phpunit21, para el desarrollo de pruebas unitarias y el constante desarrollo de nuevas librerías como complemento, permiten que se pueda también generar procedimientos estructurados e instructivos técnicos de baja complejidad, para la codificación y pruebas unitarias, actualmente una práctica habitual en el CIC [9].

Para las metodologías ágiles, los cambios en los requerimientos incluso horas antes de finalizar un entregable es algo natural y abordable, por lo que el uso de estas técnicas se adaptó sin muchos contratiempos a los requerimientos del equipo de desarrollo del CIC. Esto complementado con las facilidades ya mencionadas que proporciona PHP como lenguaje interpretado en su codificación, son parte de uno de los aspectos que ayudaron a que el proyecto Phoenix.ULS de renovación tecnológica, en el ámbito de la renovación de sus sistemas de información, tuviera el éxito observado en su implantación y masificación en el uso de sus productos de software.

4.5 Gestión de procesos educacionales apoyados en TI utilizando BPM

El proyecto de BPM para el centro de informática y computación (CIC) de la Universidad de La Serena, pretende introducir el desarrollo de BPM dentro de la implementación de procesos, para lo cual se propone comenzar con una “migración” de los procesos llevados a código fuente ya desarrollados, con lo que se proyecta sentar las bases del desarrollo de nuevos procesos que se incluyan en el futuro.

Actividades de la propuesta BPM.

Las actividades principales que se desarrollaron con este sub-proyecto son: Introducir el concepto de BPM al interior del equipo de desarrollo del CIC. Desarrollar un prototipo de aplicación BPM para el CIC, basado en algún proceso ya existente e

implementado en las plataformas computacionales.

Para esto, las tareas que se observan son las siguientes:1. Identificar los procesos que actualmente se encuentran implementados dentro de la PTDI, como

potenciales prototipos para el proyecto.2. Seleccionar dos procesos representativos para desarrollar el prototipo.3. Seleccionar la herramienta que posea las características necesarias para poder desarrollar los

prototipos, considerando la posibilidad de reutilizar código de los actuales procesos implementados en la PTDI como factor de mayor peso.

4. Realizar el diagrama en BPMN de los procesos seleccionados.5. Identificar funcionalidades que será necesario llevar a Web Services como parte de la

implementación del prototipo.6. Implementar el prototipo de BPM con los procesos seleccionados.

Como pasos siguientes, una vez implementada la propuesta con sus prototipos, se desea hacer extensible este tipo de desarrollo al resto de los procesos que sean susceptibles de informatizarse, como una herramienta que realmente otorga un mayor valor agregado a las aplicaciones hasta ahora desarrolladas para optimizar la productividad en el trabajo de los desarrolladores, siempre y cuando los resultados muestren que el uso de procesos en esta forma es factible de llevar a cabo como proyecto. Si esto es así, o sea, si la evaluación de este sub-proyecto es positiva, se pretende llegar a generar un estándar de programación, de estructura similar a los actuales estándares existentes en el CIC utilizados para el desarrollo de las aplicaciones, y comenzar una capacitación interna para los integrantes del equipo de desarrollo que se verán involucrados en este trabajo.

20 http://www.php.net/21 http://phpunit.sourceforge.net/

17

Esquema general del sub proyecto BPM22

Actualmente existen servidores virtuales separados para cada plataforma (Docente y Financiera), cada cual desarrollada en uno de dos lenguajes de programación diferentes. Por una parte la Plataforma Docente está desarrollada completamente en PHP y JavaScript, y se encuentra alojada en una máquina con Linux; por otro lado, la plataforma financiera está desarrollada completamente en Oracle Forms y se encuentra alojada en una maquina con Windows. Si bien estas dos plataformas de cierta manera interactúan y se integran, no comparten funciones a nivel de su código fuente, ya que la interacción mayormente se basa en la ejecución de procedimientos almacenados en la base de datos entre ambas.

Ya que la implementación de procesos con BPM consumirá webservices, a este nivel podría haber integración con futuras plataformas, como la plataforma móvil en desarrollo, también se pretende lograr integración con las plataformas ya existentes a nivel de la base de datos, y reutilización de código fuente (funciones de validación en java script o código PHP).

Figura 14. Esquema general de la solución propuesta para el sub proyecto BPM para la Universidad de La Serena. Fuente: Tesina de Magister en TI de Marcelo Zepeda Dubó, Promoción 2009

4.6 Renovación de la Red de Datos Institucional.

La segmentación de redes como elementos de seguridad, ha permitido bloquear el acceso de los usuarios a los recursos de información que no son públicos, como archivos, servicios, bases de datos y otros equipos en la red. Así mismo, esta subdivisión permite asignar determinados recursos y calidad de servicio a redes para fines específicos, ya sea video conferencias, acceso a transacciones para equipos que den servicio a una determinada oficina, o configuración de puertos especialmente solicitados para una dirección IP específica y que el equipo este fuera del recinto del CIC.

22 El proyecto BPM institucional [6] ha dado origen a una tesis del MTI.

18

4.7 Implementación de Monitoreo y administración de servicios en la red

Se ha implementado el monitoreo de protocolos y servicios con potencial riesgo de transferencia e infección por virus y saturación de servicios de red, actualizando listas negras de sitios web, identificando comportamientos en las transacciones según protocolo, con políticas de completa prohibición de acceso (p2p, servicios proxy externos, etc.) y acceso parcial o restringido en su ancho de banda usando catalogación de tráfico (traffic shaping), la cual permite controlar el tráfico en las redes de la universidad para optimizar y garantizar rendimiento, baja latencia en los servicios y asegurar un ancho de banda a los usuarios, clasificando los tipos de conexiones, priorizando o retrasando paquetes, todo ello para asegurar una calidad de servicio y no sobrepasar las capacidades reales y producir bajas en los servicios. Esto ha reducido enormemente las caídas de servicio de internet y acceso a las plataformas y servicio montados sobre la infraestructura de red de la universidad, por medio de la adquisición de un software especializado para apoyar esta tarea.

Las políticas de red, permiten identificar qué tipo de archivos se están transmitiendo en la red de la universidad y aplicar filtros en base a un antivirus. Estas políticas también permiten identificar comportamiento fuera de lo común, en el caso de que un equipo se encuentre infectado y actúe como computador zombi y tenga más transacciones en la red de lo que haría un computador normal.

19

Figura 15. Diagrama lógico de la nueva arquitectura e

infraestructura del proyecto Phoenix.ULS. Fuente: Plan

de Recuperación antes desastres del Centro de

Informática y Computación de la ULS

Figura 16. Diseño de servidores (virtuales y físicos) de la nueva arquitectura de los sistemas de

información del proyecto Phoenix.ULS. Fuente: Plan de Recuperación ante

desastres de la ULS.

Figura 17. Tecnologías empleadas en la arquitectura del proyecto Phoenix.ULS. Fuente: Elaboración propia.

Encriptación

Uso de encriptación en equipos de usuarios claves y equipos de todos los integrantes del centro de informática, en caso de acceso no autorizado o sustracción de los mismos, el material en desarrollo o versiones de prueba de las plataformas no estarán expuestas.

Para los servicios web implementados en las instalaciones de la universidad, se utiliza SSL (secure socket layer, capa de conexión segura), para establecer una conexión segura, encriptando la información que se transmite entre el cliente y el servidor.

Dado que una de las ventajas de los servicios montados en interfaces web es el acceso desde cualquier parte del mundo, desde un computador con internet, esto se convierte en una debilidad para los servicios que no deben ser de acceso público o son de nivel estratégico para la administración de la universidad. Para ello se han habilitado accesos usando la tecnología VPN para determinados servicios, tanto para su ejecución como para su administración.

Seguridad de la información en la ULS

El CIC, ha definido como una prioridad la seguridad de la información, implementando políticas y procedimientos formales a ejecutar en el quehacer diario del Centro, metodologías de desarrollo, configuración y administración de recursos, todo ello, para garantizar la integridad, la privacidad y la perpetuidad de la información. Los cortafuegos se han considerado como la herramienta definitiva para el resguardo y protección de la información, pero estas están supeditadas al control y diseño de reglas de acceso, un diseño inteligente de administración de recursos de red y definición de políticas internas para la definición de qué tipos de sitios, servicios y protocolos los usuarios pueden consumir. Junto a esto, instaurar procedimientos y formación para lograr un comportamiento ad-hoc en los usuarios ha sido importante dentro del CIC, lo cual ha permitido reducir la incertidumbre dentro del equipo interno para poder enfrentar los cambios con mayor rapidez. Estos procedimientos y comportamientos se reflejan en el autocontrol de fuentes de software que sean malignas a la estabilidad de los equipos de desarrollo, el no crear redes wi-fi ad-hoc así impedir accesos no autorizados a las redes internas, uso de contraseñas seguras dado un formato de cantidad y variedad de caracteres, y usar encriptación de disco en cada equipo disponible en el CIC. De la misma forma controlar el acceso a personal no autorizado a las salas de desarrollo y datacenter, minimizan en gran medida los riesgos asociados a la vulnerabilidad de la información por terceras personas

4.8 Virtualización de recursos tecnológicos institucionales

Una definición aceptada de virtualización, es la creación de una versión virtual de algo, ya sea hardware, una plataforma, sistema operativo, un dispositivo o recursos de red. Esta misma definición engloba la siguiente descripción:

“La virtualización puede ser visto como parte de una tendencia general en la organización, que incluye computación autonómica, un escenario en el que el entorno ti se podrá administrar a sí misma, como una actividad de percepción, y a una utilidad de la computación, en la que se la capacidad de procesamiento sea vista como una herramienta que los cliente puedan pagar solo cuando sea necesario. El objetivo habitual de la virtualización consiste en centralizar tareas administrativas, mientras se mejora la escalabilidad y la carga de trabajo”, traducción libre del autor [3].La virtualización de recursos dentro de la infraestructura de la ULS se utiliza como estrategia para asegurar la escalabilidad, mantenibilidad y asegurar calidad de servicio, ya que la decisión de adquisición de hardware no estará supeditada a alguna tecnología o proveedor específico, y en adición podrá ser construida bajo la disponibilidad de recursos, espacio y definición de requerimientos durante la vida del proyecto. Esta estrategia se puede subdividir en 3 ejes principales, virtualización de recursos de cómputo, virtualización de recursos de red y virtualización de recursos de seguridad.

4.9 Nueva Base de datos Institucional

20

El análisis preliminar de tecnología disponible en la ULS, mostraba que los motores de bases de datos que se encontraban en la actualidad estaban solo en relación directa con un sistema de información específico atomizado, desvinculado con respecto a los otros sistemas dentro de la universidad, en varios motores de bases de datos, Microsoft SQLServer, IBM, Dbase, Informix y en algunos casos datos tabulados en texto plano, lo que provocó la duplicación de la información, lentitud en cotejar y adquirir datos actualizados para los procesos de gestión de la ULS y una gran carga laboral asociada a procesos de re trabajo.

La base de datos corporativa es el cimiento informativo del sistema organizacional23. En base a esta premisa y lo anteriormente expuesto es que se generó la construcción de un nuevo modelos de datos institucional único para todos los sistemas independiente del lenguaje o capa de presentación que se utilice en su desarrollo, unificando los sistemas de información institucionales a través de una única base de datos, optando por privilegiar opciones de código abierto, y al contar con desarrolladores con alta experiencia previa, Postgresql fue la elección preliminar para el diseño y desarrollo.

Como estrategia de desarrollo, se diseñó el API de las plataformas para que no dependiera de las instrucciones y funciones propias de las librerías de conexión y consultas a determinado motor de base de datos, sino que se flexibilizó parametrizando el tipo de motor, las acciones comunes a ejecutar con un set de datos, y el nombre de las tablas y campos se declararon como variables. Esto permitió que, pasada la etapa de diseño y desarrollo preliminar, se pudiera integrar en versión de producción bajo el motor de bases de datos Oracle 10g sin cambios drásticos en su código, reduciendo los tiempos de implementación.

La elección de un motor de bases de datos de clase mundial como Oracle fue empujada por la adquisición de la plataforma de gestión financiera IconSystem 10g, la cual está sustentada en el servidor de aplicaciones Oracle Application Server utilizando Oracle Forms, y sobre este motor de base de datos relacional. El motor de bases de datos Oracle es bien conocido por su escalabilidad, fiabilidad, y características de alto rendimiento para aplicaciones críticas. Es la base de datos líder del mercado y está disponible para muchas plataformas de sistema operativo. Dentro de estas características se encuentra la escalabilidad y alta disponibilidad, desarrollando los sistemas académicos conectados a IconSystems 10g utilizando el lenguaje de programación PHP [2]. Bajo esta metodología de trabajo, se recomienda por parte de Oracle implementar la distribución de Linux llamada Oracle Unbreakable Enterprise Linux, y así asegurar el rendimiento, condiciones ideales de flujos de trabajo, respaldo y garantía, bajo un ambiente de producción certificado por el proveedor, definición totalmente compatible con la política de utilizar software OpenSource en este proyecto.

.

5 Remediales frente a observaciones de auditoras externas de la CNA y auditores independientes

Remediales frente a observaciones de la CNA

Luego del dictamen de la CNAP en el primer proceso de acreditación institucional existían dos puntos con suma urgencia e importancia a resolver, uno, la ya mencionada observación sobre la carencia de sistemas informáticos de apoyo a la gestión institucional, y otro tema no menor, el servicio de correo electrónico de la ULS estaba en total colapso. Además de lo anterior, la obsolescencia de los sistemas operando en esa fecha era elevada con un compromiso de seguridad de la información muy alto, se accedía a todas las aplicaciones

23 web forexco: http://www.forexco.com, visita realizada en marzo de 2011

21

por medio de terminales de texto bajo el protocolo telnet, donde las credenciales de acceso viajaban por la red en texto plano, sin ningún tipo de cifrado.

Es en este contexto donde se desarrolló un sistema web para la entrega de estadísticas y gráficos generales que tuviesen relación directa con los indicadores de gestión que la universidad posee pero que no habían sido sistematizados. Esta labor fue muy compleja, requirió analizar las bases de datos y sus estructuras sobre diferentes plataformas y sistemas legados y establecer procedimientos normalizados para el volcado de datos en modalidad batch sobre una base de datos relacional que fue concebida bajo el concepto de datawarehousing. Todo esto frente a 11 meses faltantes para el nuevo proceso de re acreditación institucional y paralelo al desarrollo e implantación de los nuevos sistemas de administración universitaria del proyecto Phoenix.ULS. Es así como a seis meses de la re acreditación, nace el SAGI, Sistema de Apoyo a la Gestión Institucional, cuya primera versión cumplió eficazmente con soslayar la observación de la CNAP sobre su ausencia, y hoy se encuentra en desarrollo una nueva versión, más cercana a una suite de inteligencia de negocios, y montado sobre un datawarehouse alimentado directamente sobre los datos de la base de datos central.

Del mismo modo destaca la especial observancia a los sistemas informáticos de apoyo a la gestión, durante los procesos de acreditación del año 2006, 200x y 2012, señalando:

Acuerdo de acreditación Institucional N° 56 de 200824, Gestión Institucional:

Acuerdo de acreditación Institucional N° 204 de 201325, Gestión Institucional:

Remediales frente a auditorías independientes

Un segundo dictamen en pleno proceso de desarrollo e implantación de los sistemas y procesos del proyecto Phoenix.ULS, como se aprecia en la figura 18:

24 http://www.cnachile.cl/res/inst/RES-INST-00053-02.pdf, Visita realizada en Marzo de 201325http://www.cnachile.cl/res/inst/RES-INST-00053-03.pdf, Visita realizada en Marzo de 2013

22

Figura 18. Matriz de severidad de riesgo en la seguridad de la información durante la ejecución del proyecto Phoenix.ULS. Fuente: Dirección de Finanzas de la ULS.

Finalmente se cuenta con un tercer dictamen al pendiente de la realimentación por parte de la ULS, como muestra la figura 19, presentando fielmente las mejoras que el Proyecto Phoenix.ULS ha proporcionado a la institución en materia de procesos ligados a la gestión y al control interno:

Figura 19. Matriz de severidad riesgo en la seguridad de la información durante la fase final del proyecto Phoenix.ULS. Fuente: Dirección de Finanzas de la ULS.

Actualmente estamos en pleno proceso de una nueva auditoría al cierre de este mega proyecto, y por decisión de la empresa auditora independiente, este año no se realizará una auditoría informática junto a la auditoría de estados financieros, dados los resultados de la última matriz de riesgo ya que asumen confiabilidad de los datos e información en los sistemas informáticos institucionales provistos por el proyecto Phoenix.ULS.

23

Posteriormente, en los años 2011 y 2012 se evidencian patrones generales de comportamiento de requerimientos tecnológicos. Hay peaks de solicitudes al final del año académico (mes de Enero) muy pocas solicitudes y actividad durante el periodo de receso universitario en Febrero… otro peak al inicio de año académico, y una disminución de solicitudes y actividades de estas al término del primer semestre (junio julio agosto) y se incrementan estabilizándose progresivamente las solicitudes y actividades desde agosto a diciembre – enero del año entrante pero mismo año académico; éste patrón de comportamiento permite asignar proactivamente los recursos humanos y materiales en temas de tecnología con planificaciones mensuales que requieren poco ajuste en la actualidad, logrando mejoras en la calidad de los servicio entregados desde las diferentes áreas del Centro de Informática y Computación, con buenos tiempos de respuesta y transparencia total de las actividades, entre todos los involucrados.

6 Conclusiones

Se logró construir un sistema de información de apoyo a la gestión institucional, con datos considerados como confiables, superando así la observación de la CNA respecto de la carencia de este tipo de sistemas, logrando re-acreditar a la ULS por un periodo de 4 años desde el 2008 al 2012, el doble de la primera acreditación y re-acreditándola nuevamente, el Diciembre de 2012 a Diciembre 2016.

El análisis sistémico realizado a la institución, permitió una visión global y desagregada de la universidad para poder identificar las entidades fundamentales que permiten su funcionamiento y a su vez, identificar los procesos de negocio que requerían reingeniería y/o rediseño.

Se desarrolló una plataforma tecnológica administrativa y docente totalmente integrada, con una única base de datos central y basada en tecnología web. La plataforma docente, fue un desarrollo propio al 100% y la plataforma financiera, una adaptación del código fuente del ERP de la Contraloría General de la República, ambos con bajo impacto institucional ante el cambio tecnológico.

Se generó un proyecto de inteligencia de procesos (SOA/BPM) y un proyecto de inteligencia de negocios (BI) los cuales con la base tecnológica provista por el proyecto Phoenix.ULS permitirá mejorar los procesos de toma de decisión y seguimiento de los procesos de la institución.

Los principales procesos de negocios educacionales y administrativos de la institución se encuentran modelados utilizando BPMN 2.0, en proceso de validación y prontos a ser implementados en producción en un plan piloto, generando una tesis para el MTI, a cargo del Ing. Sr. Marcelo Zepeda Dubó, egresado del programa, profesional a cargo del autor del presente documento.

Está por liberarse el primer prototipo del dashboard de inteligencia de negocios (BI) para la ULS, la que reemplazará al actual Sistema de Apoyo a la Gestión Institucional (SAGI), por su versión 2.0 empleando herramientas de la suite de inteligencia de negocios Pentaho, la que ha sido adquirida por la institución para poder obtener soporte de sus desarrolladores, la cual está pronta a ser implementada en producción en un plan piloto, generando otra tesis para el MTI, a cargo del Ing. Sr. Mauricio Flores Galarce, egresado del programa, profesional a cargo del autor del presente documento.

Respecto a las metodologías de desarrollo de software, actualmente están implementadas con éxito las metodologías agiles XP y SCRUM, para todos los procesos de desarrollo, planes de prueba y salida a producción, lo que ha generado otra tesis para el MTI por el Ing. Luis Rodríguez Pérez, profesional a cargo del autor del presente documento.

El sub-sistema de gestión y avance curricular automatizado a cargo del Depto. de Registro Académico, el cual es parte de la plataforma docente del proyecto Phoenix.ULS, fue exitosamente integrado a la plataforma Moodle en su versión 1.9, permitiendo la sincronización de la oferta

24

académica de cada semestre (asignaturas) y los listados de los alumnos de cada curso, con los cursos que genera Moodle permitiendo al académico centrarse netamente en la generación de contenidos de su asignatura.

Respecto de la gestión tecnológica transversal de la universidad, la aplicación de las normas ISO 9001, ISO 20000 e ITIL, ha permitido un manejo transparente y con total seguimiento de cada requerimiento tecnológico de la comunidad universitaria, mediante el desarrollo de una plataforma de gestión de mesa de ayuda (Help Desk) la cual es una particularización de un CRM dedicado a la gestión de problemas tecnológicos denominada CRQ (Client Resouce Queue).

Se ha renovado a la fecha un 83% de todo el equipamiento de la red de datos de la institución, reemplazando los equipos con un core de 1GB, a un core de 10GB y reemplazando los nodos de distribución y las redes de borde, por switches de alto rendimiento 100% administrables, eliminando prácticamente todos los dominios de colisión existentes en la red institucional, previo al proyecto Phoenix.ULS.

Se obtuvieron los recursos necesarios provisto por la alta administración de la Universidad, con la venia de la Junta Directiva de la institución, para adquirir cortafuegos y balanceadores de carga con estándares de seguridad de las instituciones financieras nacionales e internacionales, aumentando la seguridad de la información institucional, mejorando el uptime de los servicios con una arquitectura de servidores de aplicaciones virtualizados, por consiguiente se logró una mayor confiabilidad de los datos, de la información y de los procesos de la ULS, lo que ha sido demostrado en los procesos de auditoría de empresas independientes encargadas de auditar por ley los estados financieros, los procesos educacionales relacionados con estos y las correspondientes auditorias informáticas.

La gestión del cambio es una metodología ampliamente difundida en las organizaciones que enfrentan modificaciones radicales para estar a tono con los desafíos que les presenta el mercado. Tomando en cuenta, luego del análisis preliminar, la serie de modificaciones en los procesos de gestión, reglamentación, documentación que deben rediseñarse, reestructurarse o incorporarse a las existentes generan un ambiente de tensión y rechazo por parte de los usuarios ejecutantes. Ese mismo escenario está asociado cuando se ven involucradas las tecnologías de la información, ya que al ser incorporadas en organizaciones como la Universidad de La Serena, donde su presencia ha sido mínima, y pasan a tener una importancia preponderante, hay que establecer una plan formativo e inductivo para minimizar el impacto por el rechazo que pueda generar, reducir la incertidumbre los usuarios y preparar material informativo y de referencia que ayude a que la curva de aprendizaje sea menor.

Se resolvió la observación de la CNA en la primera acreditación institucional que hacía referencia a la ausencia de sistemas de apoyo a la gestión institucional.

Como resultado y conclusión final se demuestra el cumplimiento de las hipótesis del presente trabajo comprobando que la incorporación de tecnologías web facilitó una penetración (con impacto y riesgo controlado) de las nuevas tecnologías de apoyo a la gestión de la Universidad de La Serena, permitiendo cumplir a cabalidad el objetivo general y objetivos específicos del presente trabajo (y del proyecto Phoenix.ULS de Renovación Global de Tecnologías de Información de la ULS)

7 Referencias

[1] Institute of Industrial Engineers, IEEE, "Más allá de la reingeniería", página 4, CECSA, México (1995)

[2] Oracle Corporation, PHP scalability and high availability, an Oracle white paper, USA (2011)[3] Jones, C., Holloway A., The underground PHP and Oracle manual, release 1.5, Oracle

Corporation (2008)[4] Electronic product environmental assessment tool", EPA (2009)[5] Acevedo, H.R., Cambios organizacional: Estrategia y Estructura, Departamento de Informática,

Universidad Técnica Federico Santa María, Chile (2009)

25

[6] Zepeda M., Proyecto BPM para el Centro de Informática y Computación de la ULS, Departamento de Informática, Universidad Técnica Federico Santa María, Chile (2013)

[7] Robson, M., A practical guide to business process re-engineering, Gower Publishing Limited, Hampshire, England (1996)

[8] Scrum and XP from the Trenches (Enterprise Software Development), Henrik Kniberg., Editor: Lulu.com (5 de octubre de 2007) Colección: Enterprise Software Development, ISBN-10: 1430322640

[9] Refactoring: Improving the Design of Existing Code (Object Technology Series), Martin Fowler. Editor: Addison Wesley (16 de marzo de 2008), Colección: Object Technology Series, Idioma: Inglés, ISBN-10: 0201485672

[10] User Stories Applied: For Agile Software Development, Mike Cohn Editor: Addison Wesley; Edición: 1 (1 de marzo de 2004), Colección: Addison Wesley Signature Series, Idioma: Inglés, ISBN-10: 0321205685

[11] Extreme Programming Explained: Embrace Change, Kent Beck and Cinthia Andres, Editor: Addison Wesley; Edición: 2nd ed. (1 de diciembre de 2004), Colección: Xp, Idioma: Inglés, ISBN-10: 0321278658

[12] Software Engineering: A Practitioner's Approach, Roger S. Pressman, Publisher: McGraw-Hill Science/Engineering/Math; 7 edition (January 20, 2009), Language: English, ISBN-10: 0073375977

26

ANEXO A: Marco teórico

El presente trabajo se enfoca principalmente en las siguientes materias: arquitectura de conectividad y redes, ingeniería de software, política y estrategia en sistemas de información, análisis y diseño de sistemas, gestión de proyectos informáticos y cambio, tecnología web y aplicaciones, gestión de procesos de negocio, arquitectura de software, calidad de software, administración de sistemas, web engineering, sistemas integrados de gestión, seguridad informática, gestión de grandes bases de datos e inteligencia de negocios (BI).

A.1 Teoría de sistemas aplicada a las organizaciones humanas

La teoría de sistemas surgió debido a la necesidad de abordar científicamente la comprensión de los sistemas que conforman la realidad, generalmente complejos y únicos, resultantes de una situación particular, en lugar de sistemas abstractos como los que estudia la física.

Esta teoría, puede aplicarse al estudio de las organizaciones, lo cual permite identificar y comprender con mayor claridad y profundidad los problemas organizacionales, sus causas y consecuencias, viendo a la organización como un ente integrado, formado por partes que se interrelacionan entre sí, a través de una estructura y que se desenvuelve en un entorno. Así podemos detectar los procesos que requieran cambios, ya sean a nivel humano, de recursos y procesos, los cuales son necesarios para un crecimiento y desarrollo sostenibles en términos viables en un tiempo determinado.

Así lo expone el Dr. H. Ricardo Acevedo en la publicación “Cambio Organizacional: Estrategia y Estructura”, donde establece que “Toda organización se encuentra inserta en un dominio en el cual una de sus principales características es el encontrarse en continuo cambio.” Junto con indicar que la economía no se está basando en una economía industrial, esta ha empezado a tornarse en una economía digital. [5]

Estos cambios están reflejados en un cambio de paradigma, donde uno de los aspectos más relevantes que puntualizó el Dr. Acevedo, es que el comercio y los mercados se han vuelto electrónicos, casi en su totalidad. Una organización, ya sea empresa privada o una institución gubernamental, si no lleva sus procesos gestión y producción a la par con la era digital, puede desaparecer.

Figura 1. Acoplamiento Estructural entre Organización y Entorno. Fuente: Apuntes del profesor Ricardo Acevedo, Políticas Y Estrategia en Sistemas de Información, Departamento de Informática, Universidad

Técnica Federico Santa María - 2009

Además del cambio en la manera de hacer negocios y en donde la economía tiene puestas sus bases, las nuevas metodologías de gestión que actualmente se implementan en las empresas, se privilegia el trabajo colaborativo y las interconexiones de inteligencia humana, las cuales se abren paso sobre las estructuras jerárquicas monolíticas que imperaban en nuestro país, hasta hace no hace mucho. En relación a esto, el Dr. Tomás Guendelman, en la presentación “Desafíos del Futuro” (ULS, 20 de marzo de 2013), expone que el perfil de profesional que se necesita para llevar adelante estas tareas, debe tener una gran base científica y tecnológica, una base de aplicaciones y metodología para la solución de sistemas, y una porción menor de capacidades empresariales.

27

En el cambio de paradigma antes expuesto, se empieza a identificar que la innovación es más importante que la producción en masa, donde la inversión está orientada en nuevos conceptos y en su forma de crearlos, que a la adquisición de maquinaria. El poder de las ideas y el conocimiento es uno de los factores claves en este cambio.

Figura 2. Dimensión orgánico-estructural de las organizaciones. Fuente: Apuntes del profesor Ricardo Acevedo, Políticas Y Estrategia en Sistemas de Información, Departamento de Informática, Universidad Técnica

Federico Santa María - 2009

Bajo este mismo análisis, se ve claramente que las redes tecnológicas se convirtieron en la infraestructura de la economía digital y está sustentada en el conocimiento. Se identifican dos nuevas exigencias, una referida al aprendizaje, donde ya no es parte de algunas etapas de la vida, sino que comprende y pasa a ser parte de la actividad cotidiana de las personas, dado que lo aprendido queda rápidamente obsoleto. La segunda, se entiende que las redes tecnológicas pasan a ser un factor estratégico. Esto se ve reforzado al ver que las economías dominantes y las emergentes, hacen grandes inversiones para disponer de sofisticadas y eficaces plataformas tecnológicas, todo esto para que las economías digitales sean posibles.

En la digitalización de las economías, se ve notablemente amplificado el cambio, el cual se hace constante, y siendo este el escenario donde las organizaciones deben operar para su supervivencia, lo cual pasa inevitablemente por el necesario equilibrio entre organización y entorno, “en el sentido sistémico del acoplamiento estructural.” [5]

Para hacer frente a este nuevo escenario de constante cambio, las organizaciones deben tener las instancias orgánicas y estructurales necesarias, donde en algunas organizaciones se efectúa de manera formal o implícita en su quehacer, pero no es una constante en el amplio espectro organizacional en el país.

Se identifica como la instancia inicial a la Gestión Estratégica, la que establece el Objetivo Global, todo esto en un contexto de la ejecución de un proyecto estratégico.

Como señala el Dr. Acevedo “Las organizaciones, en su configuración deben disponer de la instancia orgánica-estructural para hacer frente a dicha dinámica de cambios. De hecho así acontece efectivamente en todas las organizaciones, ya sea de manera formal o implícita, con más o menos rigurocidad. Aquella instancia, en una primera aproximación, bien se puede hacer corresponder con la “Gestión estratégica”. En esta perspectiva, la “Gestión estratégica” es la instancia que establece, por cierto en el contexto de un proyecto estratégico, el “Objetivo Global”, con el cual todo el operar transformacional de la organización,

28

envuelto en la dinámica de un dominio de gestión susceptible de denominar “Gestión operacional”, quedará comprometido. En aquel dominio cada uno de los procesos que forman parte de dicho operar transformacional, que en el lenguaje de la gestión de empresas se puede identificar con “Procesos de negocios”, asume el compromiso de lograr, en coherencia, una parte del aquel objetivo en principio postulado precisamente de manera global. Cabe aquí señalar que la tarea que debe llevar a cabo cada ”Proceso de negocios”, se corresponde con su “Misión”. [5]

5.2 Redes de datos corporativas

Una red de datos es la interconexión de varios dispositivos a través de un medio de transmisión, para compartir recursos. El funcionamiento de las redes de datos se puede explicar mediante el modelo de referencia de sistemas abiertos interconectados (OSI), donde se explican sus funciones mediante 7 capas (Figura 4), las cuales son:

1. Capa Física. Se encarga de transmitir los bits por el medio empleado.2. Capa de Enlace. Establece una conexión lógica entre nodos

adyacentes y organiza los bits en tramas.3. Capa de Red. Enruta los paquetes desde el origen hasta el destino a

través de redes heterogéneas.4. Capa de Transporte. Establece y libera conexiones host-a-host.5. Capa de Sesión. Permite establecer múltiples conexiones entre hosts

mediante sesiones.6. Capa de Presentación. Permite el “entendimiento” entre hosts que

puedan tener diferentes formas de representar los datos.7. Capa de Aplicación. Esta capa es la que posibilita la interacción del usuario con la red.

La información viaja por la red atravesando cada una de las capas del modelo OSI, desde la capa Aplicación hasta la capa Física en el host-origen, hasta alcanzar el host-destino, donde se realiza el proceso inverso. Si la información es muy extensa se fragmenta y en cada capa se añaden bits de control y seguimiento.

Las redes se suelen clasificar según el medio de transmisión que emplean y la cobertura que abarcan.

Según el medio de transmisión existen redes cableadas e inalámbricas. Las primeras utilizan un medio físico guiado y las segundas, el espacio abierto.

Según la cobertura existen diversos tipos de redes, entre las cuales se pueden identificar claramente las redes de área local (LAN) y las redes de área extendida (WAN). Las LAN suelen encontrarse dentro de una o más edificaciones cercanas mientras que las WAN llegan a la cobertura mundial.

Las redes LAN han evolucionado desde Ethernet, que utilizaba un medio compartido para la transmisión de la información, hasta las tecnologías conmutadas, como la 802.3u. Los estándares IEEE actuales para redes LAN permiten velocidades desde los 10 Mbps hasta los 10 Gbps, sobre fibra óptica o cobre. Las técnicas de transmisión en redes WAN han evolucionado desde la conmutación de circuitos, hasta la conmutación de paquetes. En la primera se establece un canal dedicado de extremo a extremo. En la segunda, la información se fragmenta en paquetes para ser transmitidos por un canal compartido.Las tecnologías basadas en conmutación de paquetes más utilizadas son:

Frame Relay. Opera en las capas Física y Enlace. Los paquetes de la capa red se fragmentan para formar tramas que viajan a través de un canal compartido. Se establecen conexiones lógicas denominadas circuitos virtuales (VC) que utilizan identificadores de conexión de capa enlace.

29

Figura 3.Modelo ISO/OSI.

Fuente: Elaboracion Propia

Asynchronous Transfer Mode (ATM). Se caracteriza por fragmentar la información de capa red en tramas de longitud fija denominadas celdas. La longitud de cada celda es de 53 bytes. Además de los circuitos virtuales, introduce los conceptos de canal virtual (canal para la transmisión) y camino virtual (conjunto de canales virtuales).

MultiProtocol Label Switching (MPLS). Utiliza un protocolo sencillo que se ubica entre las copas Enlace y Red, diseñado para el óptimo manejo de voz, video y datos. Considera características de calidad de servicio (QoS) e ingeniería de tráfico. Entre los dispositivos para interconectar redes podemos encontrar los siguientes:

Hub. Trabaja en la capa Física del modelo OSI, si dos hosts conectados a él intentan transmitir simultáneamente, se producirá una colisión (dominio de colisión).

Bridge. Permite básicamente la conexión de dos segmentos de red de igual o distinta tecnología LAN, retransmite una trama en base a las direcciones MAC (Medium Access Control) de destino.

Switch. Permite a dos o más hosts conectados a él transmitir simultáneamente según las direcciones MAC, dividiendo a la red en varios dominios de colisión.

Router. Trabaja principalmente en la capa Red y su función es enrutar paquetes entre redes de diferente tecnología a través de la mejor ruta posible.

Gateway. Es un dispositivo que se ubica típicamente en el borde de una red para conectarla con otra diferente. Realiza principalmente la traducción de protocolos. Las redes actuales usan en su mayoría la arquitectura TCP/IP. Sus funciones son comparables con las del modelo OSI y se distribuyen en 4 capas (Figura 5).

Figura 4. Funciones Modelo ISO/OSI comparado con Arquitectura TCP/IP. Fuente: Elaboración propia.

30

El protocolo IP (Internet Protocol) es la base de la conmutación de paquetes y es quien se encarga de la entrega de los paquetes en esta arquitectura. No es orientado a conexión, tolerante a fallos y enrutable a través de redes diferentes. Se conoce como el protocolo del mejor esfuerzo. Actualmente existen dos versiones, la 4 (IPv4) y la 6 (IPv6), de las cuales la 4 es la más extendida. La entrega de paquetes se hace mediante direcciones IP, que son direcciones numéricas de 32 bits, en el caso de IPv4.

En la capa transporte se tienen dos opciones: el protocolo TCP (Transmission Control Protocol) y el protocolo UDP (User Datagram Protocol). TCP es orientado a conexión, es decir, existe un establecimiento, uso y liberación de la conexión. Su transmisión es confiable gracias a la confirmación de la transmisión. UDP por otro lado, no es orientado a conexión y no es confiable.

A nivel de capa Aplicación se hace uso del modelo cliente-servidor. Este modelo consiste en que el cliente realiza una petición al servidor, y este le responde adecuadamente. Un host puede establecer varias sesiones y en cada una de ellas establecer un rol diferente, sea de cliente o de servidor. Bajo este modelo trabajan diferentes aplicaciones como las de correo electrónico, transferencia de archivos, navegación web, webservices, etc.

31

ANEXO B: Resumen de las plataformas del proyecto Phoenix.ULS.

Los sistemas que conforman la actual plataforma tecnológica de la universidad son los siguientes:

● SAGI, sistema de apoyo a la gestión institucional26. sistema web, que en su primera fase, buscaba establecer los remediales del informe de acreditación antes mencionado (presente en el acuerdo N° 63 de la CNA), referente a la ausencia de sistemas informáticos para la gestión y entrega de información institucional en línea. esta plataforma se desarrolla apoyado por la dirección de docencia, la dirección general de asuntos estudiantiles, encargados de acreditación por facultad y la dirección general de acreditación de la Universidad de La Serena.

● Plataforma de correo institucional, basado en tecnologías Google Apps27. una de las primeras grandes innovaciones para la Universidad de La Serena, fue contar con el correo institucional basado en tecnologías de Google mail, suscribiendo el servicio como beta testers por gestiones de la dirección del centro de informática, desde el 2 de noviembre de 2006, siendo la primera institución en américa latina en suscribirse al programa, teniendo gratuidad en la edición de Google Apps for Education por siempre, además del uso de las variadas herramientas de Google Apps que lo complementan, como: agenda, documentos (con la que se realiza este paper), presentaciones, planillas de cálculos, todo esto con posibilidad de ser utilizadas como herramientas colaborativas de trabajo.

En el sistema de correo electrónico legado que estaba en colapso, sólo existían 400 cuentas de correo con una cuota de almacenamiento en el buzón de mensajes de tan solo 50 megabytes, restringido sólo a académicos y a algunos administrativos. Con la migración de los usuarios a Google Apps actualmente se tienen 5000 cuentas de correo activas con una cuota de almacenamiento den el buzón de mensajes de casi 8 gigabytes, sin restricción y con cuentas perennes para académicos y estudiantes de la ULS.

● Sistemas administrativos y académicos. la Plataforma Tecnológica Docente Integrada (PTDI)28, abarca aspectos del ámbito administrativo y académico, registrando desde el ingreso de un alumno a la Universidad de La Serena, hasta su titulación, pasando por áreas como: matrícula de alumnos vía PSU, inscripción de asignaturas, registro de notas, solicitudes de los alumnos, administración de la oferta de asignaturas semestre a semestre por parte de departamentos y escuelas, consulta de estadísticas e indicadores por parte de directivos, etc. el desarrollo de esta aplicación web se enmarca dentro de la propuesta de renovación tecnológica de la Universidad de La Serena, y es un desarrollo propio del centro de informática, basado 100% en tecnologías web.

● Sistema financiero (disponible solo desde la red interna de la Universidad de La Serena o vía VPN). Corresponde al ERP que utiliza la contraloría general de la república para la administración de los recursos financiero/administrativos, basado en arquitectura Oracle forms, que se adquiere dada la necesidad de renovar, aumentar la seguridad y resolver las observaciones de las auditorías de estados financieros presente es los antiguos sistemas financieros de la universidad.

● Plataforma Moodle.ULS29. La necesidad de herramientas por parte del cuerpo académico de la universidad, que les permitieran tener una mayor llegada a sus alumnos, y complementar la enseñanza presencial con recursos web y dada la experiencia que ya algunos docentes tenían de este tipo de herramientas, llevó a la decisión de adaptar la plataforma de e-learning "Moodle" para el uso institucional. para esto, se realizó la coordinación de la estructura de Moodle para automatizar la

26 web: http://sagi.cic.userena.cl/, sistema de apoyo a la gestión institucional de la Universidad de La Serena.27 web: http://webmail.userena.cl, correo web de la Universidad de La Serena.28 web: https://phoenix.cic.userena.cl, plataforma tecnológica administrativa y docente integrada de la Universidad de La Serena.29 web: http://moodle.cic.userena.cl, plataforma de apoyo a la labor docente, Moodle.ULS de la Universidad de La Serena.

32

creación de cursos, asignación de profesores e inscripción de los alumnos en cada curso, tomando la información que se genera semestre a semestre dentro de la plataforma docente de la universidad.

● Plataforma de soporte institucional30. Dado el creciente aumento de los usuarios de las distintas plataformas en funcionamiento y el necesario seguimiento de cada requerimiento tecnológico, además de la creciente demanda de asistencia hacia el CIC desde las distintas unidades de la ULS, hizo necesaria la implementación de una plataforma central donde se pudiera realizar el la solicitud, registro y seguimiento de las distintas necesidades tecnológicas y técnicas de los usuarios de la institución. la plataforma de soporte, es una plataforma CRQ 100% web, donde cada usuario con cuenta de correo en Google Apps ULS (de la Universidad de La Serena) puede realizar solicitudes ya sea de asistencia técnica, modificaciones, nuevos requerimientos, problemas con correo, con PC's, con sistemas operativos, acceso a internet y un largo etc., y consultar el estado de estas solicitudes en línea. este sistema permite una gestión eficiente por parte de los encargados de cada área del centro de informática, basado en las mejores prácticas de las normas ISO 20.000 para gestión de áreas tecnológicas.

30 web: http://soporte.cic.userena.cl, plataforma de soporte del centro de informática y computación de la Universidad de La Serena.

33

ANEXO C: Descripción de los recursos tecnológicos virtualizados en el Proyecto Phoenix.ULS

C.1 Virtualización de recursos de cómputo

La virtualización de estos recursos es una tecnología probada que permite ejecutar múltiples máquinas virtuales en una única maquina física. Cada máquina virtual está completamente aislada de las otras máquinas virtuales y se desvincula de la máquina anfitriona, a través de una capa de abstracción llamada hypervisor. Esto permite que cada máquina virtual ejecute diferentes sistemas operativos y aplicaciones. Esta desvinculación hacia el hardware permite poder implementar los servicios requeridos para ejecutar la plataforma administrativas, en cualquier servidor, sin importar el formato de caja del equipo, tipo de procesador utilizado, arquitectura asociada, proveedor o hardware adicional disponible.

La virtualización ha permitido la consolidación de servicios, en pocas máquina física, produciendo con ellos, menores costos asociados en consumo de energía eléctrica, control de temperatura, espacio en los datacenter, para ello se utiliza el término Green Computing[9.6], acuñado por la EPA (Environmental Protection Agency, agencia de protección ambiental) que se refiere al uso eficiente de recursos computacionales minimizando el impacto ambiental, maximizando su viabilidad económica y adicionalmente poder ser presentado como responsabilidad social de la universidad. Las empresas desarrolladoras de estas tecnologías usan este término para fomentar las bondades de la virtualización, la cual minimiza las emisiones de co2 y la reduce la huella de carbono en instalaciones bajo esta configuración.

Además, ha permitido incrementar la flexibilidad tecnológica, proveyendo de nuevos servicios en cuestión de minutos. Asegurando que los requerimientos de las aplicaciones y niveles de performance sean alcanzados.

Ha minimizado el periodo de caída de servicios, reduciendo el impacto de las fallas, protegiendo la infraestructura contra desastres. La misma desvinculación al hardware descrita anteriormente, permite que un servicio pueda volver a levantarse sin depender de la configuración física de tecnología o recursos disponibles en un tiempo mínimo.

C.2 Virtualización de recursos de red

La metodología de virtualización de recursos de red (VLAN), es básicamente crear redes lógicamente independientes dentro de una misma red física. Estas pueden coexistir en un router físico o en una única red física. Han sido útiles para reducir tamaño del dominio de difusión y ayudan enormemente a la administración de la red, separando segmentos lógicos de una red de área local en campus, edificios, pisos y oficinas, los cuales no necesariamente debe intercambiar datos.

Esta configuración de red permite organizar los segmentos, agruparlos y permitir el acceso de equipos como si estuviesen conectados en un mismo router, aunque estos estén conectados físicamente en diferentes segmentos de la red. Adicionalmente se ha incrementado los niveles de seguridad, facilitada por la fácil y rápida identificación de segmentos y equipos comprometidos y bloquear independiente cada uno de ellos.

C3. Virtualización de recursos de seguridad

Al hablar de recursos de seguridad, la configuración de balanceadores de carga, firewalls, catalogación de tráfico y reglas de acceso esta soportado por hardware de nivel industrial, al nivel de instituciones bancarias y servicios virtualizados dentro de estas máquinas.

Los recursos de los balanceadores de carga están orientados a garantizar la calidad de servicios, distribuyendo la carga de solicitudes entre todos los equipos que estén brindando el mismo servicio y detectando los equipos virtuales que no se encuentran disponibles, para delegar esas actividades a otro equipo disponible.

Los servicios de firewall poseen las reglas de acceso y bloqueo de puertos, servicios y protocolos a través de la red física de la institución, posee la capacidad de aplicar reglas especiales y/o específicas por cada sub red o VLAN.

34

35

ANEXO D: Glosario

AJAX Asynchronous JavaScript And XMLAPI Application Programming InterfaceBB.DD. Base de DatosBI Business Intelligence, Inteligencia de NegociosBPM Business Process Management BPMN Business Process Management NotationCIC ó CICULS Centro de Informática y Computación de la ULSCNA Comisión Nacional de Acreditación (Ex CNAP)CNAP Comisión Nacional de Acreditación de PregradoCOBIT Control Objectives for Information and Related Technology FrameworkCRM Client Resource ManagementCRQ Client Resource QueueDD Dirección de DocenciaDF Dirección de FinanzasEPA Environmental Protection Agency, agencia de protección ambientalERP Enterprise Resource PlanningForms Interpreter o PHP/FI Lenguaje de Programación para aplicaciones Web

GE Gestión EstratégicaGO Gestión OperativaIEEE Institute of Electrical and Electronics EngineersIP Internet ProtocolISO International Organization for StandardizationITIL Information Technology Infrastructure LibraryMTI Magíster en Tecnologías de la Información del Departamento de Informática de

la Universidad Técnica Federico Santa MaríaOSI Modelo de referencia de sistemas abiertos interconectados de la ISO

PHPAcrónimo recursivo que significa PHP Hypertext Preprocessor y en sus inicios significaba Personal Home Page

PSU Prueba de Selección Universitaria de ChilePTDI Plataforma Tecnológica Docente IntegradaPTFI Plataforma Tecnológica Financiera IntegradaSAGI Sistema de Apoyo a la Gestión InstitucionalSIE Sistema de Información EstratégicoSIET Sistema de Información Estratégico Técnico/TecnológicoSOA Service Oriented ArchitectureSQL Simple Query LanguageTCP Transfer Control ProtocolUDP User Datagram ProtocolULS Universidad de La SerenaVA Vicerrectoría AcadémicaVLAN Virtual Local Area Network

36

VPN Virtual Private NetworkVREA Vicerrectoría de Asuntos Económicos y AdministrativosWAN Wide Area Network XP eXtreme Programming

37