Archivos Mensuales: septiembre 2012

El uso de Open Source como fuente de reducción de la inversión de TI.

Revisando el tema de costos de TI, uno llega a pensar en Open Source como una opción al incremento de costos. Bueno, lo es. Este movimiento, que comenzó ya hace muchos años, resulta que ha madurado muchísimo, ha soportado estándares en muchas áreas del desarrollo de la computación y lo mejor de todo ha creado productos que se convierten en excelentes soluciones a un costo muy bajo para resolver problemas que de otra forma requerirían de una inversión considerable. Tomemos como ejemplo, la computación de escritorio. Anoche, mientras preparaba una solución GIS, con software open Source, por supuesto, me encontré que la aplicación utilizaba datos en el formato dbf. Eso tradicionalmente no ha sido un problema para Excel. Pero en la versión de 2010, esta funcionalidad ha sido removida del Excel. Por supuesto, si uno es un Power User y tiene la versión profesional de Microsoft Office, puede lograr su objetivo de crear datos en formato dbf a  través de crear una tabla de Access importando el archivo de Excel y luego importarlo en formato dbase. Punto resuelto. Pero si no tengo esta versión y sobre todo, si los datos van a ser manipulados por personal que no necesita una versión profesional de Microsoft Office, la opción de utilizar Apache Open Office resuelve este problema a un costo cercano a cero. Es así porque siempre hay costos adicionales a los de la adquisición del software cuando implementamos un producto. La curva de aprendizaje del usuario, el soporte, la donación que aportamos por utilizar este software tan útil sin el problema de pagar una factura para instalarlo. En serio, cada vez es más la gente que realiza aportaciones a estas fundaciones como un medio de apoyar y de retribuir el buen trabajo que desarrollan, ayudando a crear un mercado más competitivo y con más opciones. Si lo vemos desde el punto de vista empresarial y tenemos que proporcionar un software de oficina a un costo promedio de $200 por usuario, si tengo 50 usuarios, la factura total a pagar asciende a $10,000.00. Eso hace difícil la decisión entre el usar  Open Source o no. Adicionalmente, Open Source es más seguro que la opción utilizada por muchos de utilizar copias pirateadas, que incluso pueden llegar a dañar los “activos de información” contenidos en las máquinas en las que se instalan. Esto representaría un costo que bien puede medirse más que en valor económico, en el impacto de perder y rehacer información valiosa. Este pequeño ejercicio nos deja un análisis económico básico. Lo sorprendente es que en muchas más áreas, el Open Source ha creado productos de software que proporcionan un nivel satisfactorio de desempeño, que bien vale la pena evaluar las opciones disponibles antes de realizar una implementación de software. Con esto, la Gerencia de TI podrá proveer servicios mientras realiza ahorros evaluados en miles de dólares, lo cual no debe de ser despreciable para ninguna organización.

Inversiones en Tecnologías de la Información.

En más de 20 años de vida profesional, apoyando a las operaciones de organizaciones con el soporte de las Tecnologías de la Información, solo recuerdo a un Presidente de Junta Directiva que me dijo al momento de crear un presupuesto de Inversión de TI: “No importa el costo, quiero que tengamos lo mejor”. Esta expresión, debo confesar, me tomo por sorpresa. Más bien, la costumbre en el medio es cuestionar todas las inversiones en Tecnologías, preguntándose inicialmente si son inversiones necesarias, si pueden ser postergadas, si se puede rebajar alguna especificación que impacte en costo, en fin, una serie de interrogantes que tienen por objetivo reducir el monto total a invertir. A esto yo le llamo una visión totalmente financiera de las Tecnologías de la Información. En muchas organizaciones se calcula la inversión como un monto fijo o recurrente cada periodo, algo que le da tranquilidad y control al Gerente Financiero, pero que no siempre es lo mejor para la organización.

Las inversiones de TI deben de ser administradas por el Gerente de TI de una manera dinámica, construyendo el caso de negocio para cada una, de manera que cuando llegue el momento de buscar aprobación para el presupuesto, esta acción sea natural, nada forzada y de ser posible hasta esperada por la Alta Gerencia para obtener los beneficios esperados. Procesos de gestión de TI bien implementados logran que la Gerencia de TI tenga a la mano la información necesaria para preparar un buen caso de negocio. Se trata de tomar los reportes de incidentes, clasificarlos e identificar los que tienen tendencia a incrementar. Hay que recordar que un incidente interrumpe las operaciones y tiene un costo, que tiene que ser medido. Si la tendencia de los incidentes es a incrementar, eso nos da un modelo de predictibilidad de costo esperado por “no invertir”. Otro ejemplo se puede hallar en el proceso de investigación y desarrollo. Cuando el responsable de evaluar como se pueden mejorar las operaciones da un vistazo a lo que hace la competencia y estima que nos están ganando debido a sus inversiones en Tecnologías de la Información, es imperativo calcular en base a escenarios qué ganará la competencia con esta ventaja. Esto se mide en “ventas pérdidas”, “clientes perdidos”, “ventas no realizadas” y conceptos similares, que tendrán un entendimiento claro a partir de las comparaciones realizadas con datos de nuestros competidores.  Esos datos son los que hay que mostrar a la Alta Dirección para lograr decisiones de inversión.

Con esto aprendemos que la decisión financiera de las inversiones siempre tiene que realizarse. Lo único nuevo es que los datos con los que se analizará deben de salir del departamento de TI, en lugar de salir de cálculos netamente financieros. De esta forma se logra tomar decisiones más informadas, que ayudan a la organización en el logro de objetivos.

Auditando Políticas de TI

En otra ocasión hablamos de la importancia de la creación de las políticas de TI como una herramienta para crear un equipo de dirección que incluya a la Alta Dirección en la toma de decisiones de la gestión de TI. Las políticas, en ese sentido sirven para establecer el marco regulatorio de toda la actividad de TI, soportadas por la Alta Dirección y ejecutadas a través de las operaciones del departamento de TI. Si la ejecución funcionará perfectamente, definitivamente no existiría lugar para la Auditoría de Sistemas. Sin embargo, la función de Auditoría de Sistemas resulta útil para activar la mejora continua de las políticas de TI.

En primer lugar, la revisión de los resultados de la aplicación de políticas puede determinar que hay áreas que no han sido normadas adecuadamente, creando situaciones de riesgo para la información. Es decir, aun cuando se cumplan las políticas existentes, la Auditoría de Sistemas sirve para evaluar si ese cumplimiento es suficiente para mitigar los riesgos existentes. Por ejemplo, si existe una política de asignación de laptops a puesto claves y no existe una política de resguardo de la información que viaja en esas laptops, la verificación de la seguridad de la información que realice una auditoría de sistemas, determinará como hallazgo el peligro que existe de perder información almacenada en las laptops, creando la recomendación de evaluar las opciones para garantizar que la información almacenada en las laptops no se pierda o llegue a manos equivocadas. Es conveniente plantear un segundo escenario sobre este mismo caso. Si existe ya una política de seguridad de la información de los dispositivos móviles y el departamento de TI la ha implementado a través de tecnología que cifra la información y crea los respaldos tan pronto la máquina se conecta a la organización, la Auditoría de Sistemas procederá a verificar el cumplimiento de la política y su mecanismo de implementación a través de la revisión de que todas las máquinas o una muestra de ellas, dependiendo del tamaño de la organización, efectivamente tengan los agentes instalados y no existan excepciones a la ejecución de respaldos. En un caso ideal, todos los equipos estarían protegidos y no habría mayor hallazgo que reportar, pero si se detecta un número mayor a lo que se puede considerar una excepción, que normalmente no pueden ser más de una o dos, la Auditoría de Sistemas procedería a investigar la causa de estas excepciones, para lograr determinar el hallazgo real y crear una recomendación para eliminarlo. Lo importante del ejemplo es que aunque la definición de Políticas de TI es el inicio de un ambiente controlado de operaciones de TI, en la práctica es necesario siempre tener un nivel adicional de validación de que se están implementando las políticas de acuerdo a la intención original y que cumplen con el objetivo para el que se crearon. Si enumeramos las excepciones y omisiones creadas por los departamentos de TI, se encontrará una justificación importante para que una organización cuente con servicios de Auditoría de Sistemas.

Los Procesos de Gestión de TI y la Gestión del Personal.

Personalmente opino que el éxito de los Gerentes de TI radica en la selección adecuada y oportuna de los procesos de gestión de TI que debe de implementar. Aunque la realidad de nuestras empresas salvadoreñas y de la región centroamericana lleva muchas veces a asumir las Gerencias de TI con una gran cantidad de “puntos pendientes” que tienen que ser superados, la selección de procesos obliga a los Gerentes de TI a ganar la capacidad de superar la demanda de cosas urgentes que la organización le requiere, a través de la identificación de procesos que deben de ser creados o mejorados para resolver definitivamente los problemas de TI.

Si hablamos de comunes denominadores en la Gestión de TI en la empresa salvadoreña, uno es que no ha existido mayor organización a través de un enfoque de procesos en la praxis de la industria. Esto tiene que deberse a la forma en la que la Educación Universitaria ha llegado a los profesionales de TI. Los profesionales de TI aprenden a desarrollar software, a realizar análisis de sistemas, a administrar redes y una gran variedad de temas que rondan el área técnica de TI. El verdadero problema es que no importa cuantos sistemas e infraestructura tecnológica tenga una empresa, ni el nivel de inversión realizado, si no implementamos procesos de gestión de TI, la función de TI se desarrollará de una forma muy lenta, con ciclos que obliguen a rehacer cosas, con muestras claras de no ser eficientes ni eficaces. Esto nos plantea dos problemas: por un lado, la formación de profesionales de TI ha sido deficiente en cuanto a enseñar a gestionar la TI; por otro, los modelos de Gestión de TI evolucionan rápido, igual que la tecnología, obligando a una renovación constante de conocimientos por parte de los profesionales de TI que tienen bajo su responsabilidad gerenciar el soporte de las Tecnologías de la Información en una organización.

Similar a la discusión presentada sobre la aplicación de estándares, existen marcos de referencia (frameworks) que les proporcionan un horizonte de planeación a los Gerentes de TI. Si tomamos el ejemplo de COBIT, en su versión 5, proporciona un listado de 32 procesos de Gestión de TI, que pueden implementarse para realizar una gestión óptima de la función de TI. Si le hemos seguido la pista al desarrollo de COBIT, sabremos que en la versión 4.1 eran 34 procesos. La disminución se debe a que COBIT 5, en su versión 5, ya toma en cuenta el Gobierno de TI, que no es responsabilidad exclusiva de los Gerentes de TI, sino que obliga a la Alta Dirección a ser una parte activa de la función de TI, incorporando 5 procesos adicionales de Gobierno de TI. Pero si hablamos a nivel de Gerencia, existen 32 procesos de los cuales se tiene que priorizar su implementación con el fin de mejorar la gestión de TI de una manera programada. Los procesos están organizados a través de dominios, de alguna forma llevan un orden lógico de desarrollo a través de fases de planeación, implementación, ejecución y evaluación de la función de TI.

El verdadero arte de la implementación de los procesos de TI es el hacerlo en el 90% de los casos, con el personal existente. Debido a las limitaciones de conocimiento expresadas anteriormente, los profesionales de TI de todos los niveles, tienden a visualizar como difícil la implementación de procesos de trabajo más estructurados, que los obliguen a llevar controles que son comunes en otras áreas. Esto lleva a la excusa de que se necesita un responsable de los procesos de gestión de TI, cuando esta responsabilidad es del Gerente de TI, que tiene que modificar los manuales de puestos de todos los miembros del departamento de TI para acomodar las funciones a los procesos que se implementen. Esto puede llevar a temas de carga de trabajo y la percepción de que se están otorgando más funciones al personal. Sin embargo, cuando el departamento de TI no realiza su trabajo a satisfacción de la organización todo el personal puede tener consecuencias, por lo cual, un proceso de implementación de procesos de gestión de TI debe de promocionarse como la forma de trabajo más organizada y el camino a seguir para mejorar el ambiente laboral del personal de TI, haciéndolo más profesional, asimilando y poniendo en práctica conocimientos que han surgido en los últimos años sobre la Gestión de TI. La implementación de procesos es en definitiva una forma de crecimiento profesional para el personal de TI. Es importante conocer que en las organizaciones que han implementado frameworks como COBIT, el personal de TI pasa a tener un mejor desempeño, logrando una mejor imagen, menores niveles de stress laboral y hasta el logro de bonos.

Aplicación de Estándares de TI

Es común, más de lo que la gente quiere admitir, que profesionales de TI tengan problemas a la hora de buscar una ruta práctica para implementar estándares. Una raíz de este problema se basa en la incomprensión completa del término, confusión con otros términos como políticas y procedimientos y la decisión o el conocimiento de qué poner en cada tipo de documento. En esta ocasión nos enfocaremos en los estándares. Para poner un punto de referencia válido de comparación, se anexa el significado de la palabra “estándar”, de acuerdo a la Real Academia Española. Mi experiencia como Ingeniero Industrial, me dejo saber hace mucho tiempo que los estándares en buen español son “normas” que se deben cumplir en orden a seguir un acuerdo común logrado sobre una forma de resolver un problema a través del trabajo de organizaciones que se dedican a la identificación, construcción, discusión y divulgación de estos acuerdos o normas. Esta es una labor importante para todas las áreas del conocimiento, no solo para las tecnologías de la información. Los estándares son los que permiten que al construir o hacer productos, estos tengan una referencia común que permita garantizar que tienen las características requeridas y que podrán operar con otros productos. Por ejemplo, la gasolina tiene que cumplir con un estándar de producción para garantizar que puede operar con cualquier marca de vehículo. Este es un ejemplo de interoperabilidad, que permite visualizar fácilmente la importancia de un estándar y como funciona, dado que sin importar quién fabricó la gasolina, el seguimiento del estándar de fabricación y de las características del producto final, las gasolinas de diferentes productores cumplen su función con un nivel de variabilidad muy pequeño. Esto es, hay un margen de tolerancia, aún en la industria, para la aplicación de estándares.

Definición de la palabra Estandar, de la Real Academia de la Lengua Española

Definición de “estandar”. Fuente: Sitio web de la Real Academia de la Lengua Española.

Cuando se aplican estándares a servicios o productos intangibles, como el software, el tono ha sido el buscar la unificación de diferentes teorías de conocimiento, a efectos de cerrar una discusión que sería muy extensa, dado que cada fabricante puede proporcionar su versión de “la mejor práctica a seguir”, haciendo imposible para los tomadores de decisiones tener una garantía mínima de que en la organización se está siguiendo una práctica adecuada. Los estándares en el área de las Tecnologías de la Información proporcionan los requisitos mínimos que se deben de cumplir para garantizar que se realiza una determinada función o se presta un servicio con una variabilidad muy pequeña respecto de las mejores prácticas. Esto garantiza a la Alta Dirección, que la función de TI se desempeña de una manera aceptable, conforme al conocimiento actual.

Existen estándares para todas las áreas de las Tecnologías de la Información, tanto en hardware, como en software, como en los procesos de gestión. En nuestro medio, deberíamos de estar conscientes de los estándares relacionados con la gestión de TI, para que al momento de resolver un problema, la solución siga un patrón común, que consiste en aprender qué dice el estándar que hay que considerar, evaluar su adopción completa o parcial, de acuerdo a las condiciones específicas de la organización, su tamaño, objetivos, apetito de riesgo, etc. Definir los elementos del estándar que se implementarán y proceder a su aplicación. Esto último es necesario porque en los temas de gestión de TI no todas las organizaciones necesitan aplicar un estándar completo para resolver un problema. Hay que entender que la definición de un estándar de TI, visto desde un entorno nacional, y a veces mundial, debe de considerar elementos que son necesarios en grandes corporaciones. La práctica sana es acotar el estándar aplicado en una organización para enfocar los esfuerzos en esas partes del estándar que garantizan la obtención de los beneficios esperados. Esto permite resolver el problema con el mínimo de esfuerzo y dejar un camino establecido para la mejora continua, a partir de la implementación de más partes del estándar.

Como conclusión, un Gerente de TI debería de acostumbrarse a decir ante la Alta Dirección cosas como “Se ha realizado un Plan de Seguridad, basado en la norma ISO/IEC 27001”. Este tipo de declaraciones le proporciona mayor validez a su trabajo y seguramente mejores resultados.

¡Terremoto en Costa Rica! Ayer se probaron los Planes de Contingencia Tecnológica.

No cabe duda que los fenómenos naturales que causan desastres suceden tarde o temprano. Me parece que esa parte de la realidad es conocida y en las organizaciones se espera que suceda lo más tarde posible, lo suficiente como para estar preparados para afrontar la contingencia. Por supuesto, ante un desastre natural del tipo que aconteció ayer en Costa Rica, lo primero es salvaguardar las vidas humanas, la seguridad de la integridad física de las personas. Pero posteriormente al evento, en momentos en los que aún se está sufriendo la experiencia de pasar por el evento, hay que asegurar que los activos de la organización serán protegidos. Leía la noticia sobre como algunas agencias bancarias cerraban “por precaución” y me preguntaba si esa era una medida ya calculada, “paso uno del plan de contingencia tecnológica en caso de terremoto”. Otras noticias decían que las comunicaciones habían tenido problemas en la primera hora posterior al evento. Esto es un impacto en las comunicaciones, que bien podría haber dejado partes de la red de datos de una organización sin acceso. “Paso número 2”, definir el estado de funcionalidad después del evento catastrófico. La verdad es que en esos momentos las decisiones tienen que ser bien medidas. El Gerente del Proceso de Contingencia o el Líder de Contingencia tiene primero que buscar la información y si la obtiene, tomar la mejor decisión a partir de lo que sabe. Si no la obtiene, aún tendrá que tomar la decisión de qué hacer, pero con un margen de error más grande.

Cuando se diseñan los Planes de Contingencia, siempre es bien difícil hacer entender al personal de una organización que hay que pensar en los escenarios de un evento que obligue a la activación del Plan de Contingencia. Por ejemplo, después de un terremoto, podría ser que se cuenten con los empleados claves. En ese escenario, ellos realizarán las actividades claves de recuperación ejecutando los roles que normalmente desempeñan. Escenario 2, no está disponible un empleado clave por las mismas causas del evento. Este escenario obliga a pensar de antemano en la persona, o personas en una cadena de sucesión, que retomarían sus funciones. Este escenario obliga a crear también relaciones de comunicación entre los funcionarios claves y sus sucesores en caso de contingencia. Obliga a establecer capacitaciones para los sucesores. Obliga a revisar que la documentación de los procesos este clara y actualizada, así como obliga a la lectura por parte de los sucesores, quienes podrían incluso hacer observaciones que mejoren la documentación existente. Esos escenarios y muchos más, son los que se tiene que pensar de antemano cuando se está creando un Plan de Contingencia Tecnológica. Escenarios con sus consecuencias en términos de personas involucradas, conocimiento identificado como crítico, capacitaciones y mejor documentación.

Quizá el principal problema del personal en las organizaciones es la falta de imaginación. Siempre la usamos para imaginar lo mejor, por lo que imaginar que sucede algo malo, de carácter catastrófico, nos hace dudar de cuales serían los escenarios de un evento catastrófico. La recomendación es: ¿Tiene su organización un Plan de Contingencia para afrontar estos escenarios? Si la respuesta es no, tienen trabajo y ojalá el tiempo para hacerlo sea menor que lo que falta para el siguiente evento catastrófico.

La planificación de la Auditoría de Sistemas.

Un paso importante en el proceso de Auditoría de Sistemas es la definición de un Plan de Auditoría. Esta es una actividad que debería de hacerse a finales de año, a partir de la experiencia de las auditorías del año actual, a partir de los objetivos de la organización para el nuevo año y a partir de los proyectos planificados para el próximo año y ojalá, a partir de la situación de riesgos evaluados en el momento de realizar la planificación. En un universo de riesgos que siempre es más grande que las horas disponibles para realizar auditorías, siempre tienen que existir criterios para decidir que es lo que se audita y que no. El caso ideal, pero muy infrecuente de ver en nuestras empresas salvadoreñas, es cuando se ha realizado un ejercicio total de análisis de riesgo, el cual se actualiza con las revisiones de auditoría realizadas y de esta forma permite establecer a través de un sistema de calificación cuales áreas presentan más riesgos y entonces, no hay nada más que discutir, se audita lo que tiene mayores riesgos.

Otras empresas adoptan un patrón cíclico. Tienen el inventario de procesos desarrollados en la organización y a partir de este listado, se van eligiendo los temas que se revisarán. Es un enfoque que puede guiarse por el “olfato de riesgo” que tenga el auditor, que no siempre es acertado, pero en fin, es otra manera de actuar.

Si se quiere hacer crecer el nivel del control interno en las operaciones de TI, lo más conveniente es no sólo ver hacia adentro de la organización, sino también ver hacia afuera. La pregunta es ¿Qué establece un marco de referencia como COBIT que debe de realizar la gestión de TI?¿Cuales de estos procesos tendrían una importancia alta para la organización?¿Cuales serían los procesos que aportarían valor a la gestión de TI? A partir de estas respuestas, se puede desarrollar un plan que va a forzar a crecer a las organizaciones en su ambiente de control interno de TI, al considerar los riesgos documentados por los marcos de referencia en la organización, al considerar las prácticas de gestión recomendadas versus las practicas adoptadas o no ejecutadas por la función de TI. Sin duda alguna, este enfoque proporcionará un buen resultado de las auditorías de TI. Si se decide realizar este enfoque, es conveniente que el auditor coordine con la gestión de TI el enfoque de la auditoría. De esta manera se puede lograr un crecimiento simbiótico de la gestión de TI en la organización. No se trata de esconder el criterio de evaluación, se trata de que todos entiendan lo mismo al hablar de un proceso y que exista consenso en la necesidad para la organización. Es conveniente recordar aquí que existen muchos marcos de referencia que la Gestión de TI puede seguir. Incluso la elección del marco de referencia debe de ser guiado por el tipo y nivel de riesgos a mitigar y las necesidades de la organización. Por ejemplo, es inexplicable encontrar organizaciones que tienen que cumplir con marcos regulatorios y ni el responsable de TI implementa la regulación, ni el departamento de auditoría ha realizado una revisión del cumplimiento. Definitivamente, las decisiones tomadas al momento de hacer un Plan de Auditoría impactan en los niveles de cumplimiento de la organización. Siempre hay que pensar que aunque la situación de cumplimiento de normas y regulaciones en una organización no sea el óptimo hoy, esa condición tiene que mejorar en el futuro a partir del trabajo realizado, ya sea en la gestión o en la auditoría de TI.

Creo que dejaré esta entrada hasta aquí. Tengo que hacer un Plan de Auditoría.

La Arquitectura Empresarial: los procesos de negocio.

En el año 2007, durante un viaje a Japón para entrenarme para ser un CIO, de acuerdo al estándar de ese país, conocí acerca de la Arquitectura Empresarial. Este concepto, expone la introducción de Tecnologías de la Información a las empresas a través de un enfoque metódico, que pasa por definir, a través de modelos, los procesos de negocios, la información de la organización, los sistemas, el diseño tecnológico y hasta las operaciones. Habiendo estudiado Ingeniería Industrial, tenia amplia experiencia en términos como la Reingeniería de Procesos, los círculos de calidad y la documentación de procesos de negocio. Por esa razón, asimilé el concepto de Arquitectura Empresarial con un alto grado de facilidad, como algo muy familiar. Adicionalmente, también me permitió visualizar muy fácilmente, la diferencia entre las culturas empresariales japonesas y la salvadoreña.

En primer lugar, la arquitectura empresarial obliga a tener claro los procesos de negocio. A optimizar la forma en la que se consiguen los objetivos de la organización. La discusión de los procesos, no se hace a través de ideas expuestas por uno y otro personaje en una sala de reuniones, sino a partir de un diagrama que muestra objetivamente la situación actual de la forma de hacer negocios. A partir de esta dinámica, la modificación de procesos consiste en la generación de gráficos que muestran exactamente como se realizará el proceso y las ventajas en términos de dinero, tiempo o beneficios de otra clase que tiene el modelo propuesto. De esta manera, el Ingeniero Japonés no discute, expone las mejoras, cuestiona la necesidad de una tarea, de una actividad, de un proceso, plantea escenarios de trabajo alternativos, respaldando sus ideas con diseños. Esto considerado a un nivel empresarial, muestra un modelo de negocios integral, con el que funcionará la empresa. Gracias a esta base inicial para usar tecnología en la organización, en Japón uno se encuentra con sistemas que han funcionado por más de 20 años sin cambios. Resolviendo el problema para el que fueron diseñados y sin requerir mayores inversiones en su mantenimiento. Por supuesto, es mucho más fácil diseñar sistemas optimizados y robustos en Japón, que en un país como El Salvador. Por varios motivos. Japón obliga a la utilización de la arquitectura empresarial en la integración de tecnologías a la empresa, en El Salvador no. En Japón la Arquitectura Empresarial es conocida por los profesionales que tendrán algún rol dentro del proceso de sistematización de la organización, en El Salvador no. En Japón, las horas de discusión de los procesos de negocio son vistas como necesarias, en El Salvador no.

 Los empresarios salvadoreños, así como los de otros países de Latinoamérica, deben de exigir a los profesionales que laboran para ellos el aprendizaje y la puesta en práctica de estas metodologías de trabajo, como es la Arquitectura Empresarial, con el objetivo de lograr una integración de la tecnología a las organizaciones que sea eficiente, optimizada, con la integración de los procesos de negocio como primer elemento del proceso de sistematización. Ideal sería, que el gobierno creara las instancias correspondientes para definir o elegir el estándar de referencia en la integración de tecnologías. Menciono “elegir” porque en muchos países desarrollados, se han creado estándares locales de Arquitectura Empresarial, razón por la cual en El Salvador no deberíamos de reinventar la rueda, pero si seguir todos el mismo estándar.

La Construcción de Políticas de TI

Como todo marco regulatorio, el conjunto de normas que rigen las operaciones de TI deben de ser dirigidas por políticas. La construcción de las políticas debe de considerarse como el paso número uno de la generación de un marco regulatorio más grande. ¿Qué debemos evitar? La gerencia de TI debe de implementar normas que apoyen la gestión del negocio, que tengan el mismo sentido de dirección y organización que tiene la empresa, por lo que lo primero que hay que evitar, es el impulso de políticas que se distancien de los planes organizacionales. La principal razón por la cual las políticas deben de ser aprobadas al más alto nivel organizacional es el garantizar que su enfoque ha sido presentado a la alta dirección, que se han discutido las implicaciones y que se han elegido los lineamientos que tienen todo el apoyo de la alta dirección. Esto es especialmente importante en los grandes corporativos, que se expanden en diferentes empresas y muchas veces obligan a la coordinación de diferentes departamentos de informática, algunos de ellos operando sobre diferentes condiciones por el giro al que se dedican, las regulaciones externas aplicables y la situación competitiva. En el ambiente de una empresa más pequeña, siempre tiene importancia la aprobación de la alta dirección, especialmente porque en estas empresas puede suceder que las relaciones de confianza entre los diferentes usuarios con la alta dirección, lleve a los usuarios a solicitar autorizaciones a la alta dirección para no cumplir con las regulaciones de TI, bajo cualquier pretexto, sea válido o no. En estos casos, la definición de políticas y el proceso de discusión que tiene que llevar a un entendimiento de la alta dirección del objetivo de cada política, de los riesgos que se están previendo, de la motivación para incrementar la seguridad de la información o la eficiencia de las operaciones. Se puede decir que la definición de políticas debe de ser visto como el primer punto de integración de las operaciones de TI con el negocio, a un nivel pre-operativo, que establece lineamientos para realizar tareas más específicas, que serán posteriormente detalladas por normas específicas, la adopción de estándares y la definición de procedimientos de trabajo.

Podemos concluir entonces que la construcción de políticas de TI debe de estar en sintonía con las intenciones de la organización y el nivel de soporte de TI necesario para lograr los objetivos del negocio. Por lo tanto, no es sano sólo copiar las políticas de otra organización. La aprobación de políticas por la alta dirección debe de garantizar que se han discutido y entendido las consecuencias de una política determinada y que no se presentarán desviaciones significativas en su ejecución.

Los Resultados de la Gestión de TI

Es importante para la efectiva gestión de TI identificar cuales son los resultados que la empresa espera del departamento de informática. La definición de los resultados tiene que ser expresada en un lenguaje común para todos, la alta dirección, la dirección de TI, los técnicos de TI, los usuarios y hasta los clientes. Todos estos roles tienen que interactuar en las operaciones de TI, pero en muchas organizaciones presentan grandes barreras comunicacionales determinadas por las costumbres organizacionales, los conocimientos individuales y hasta la cultura de liderazgo existente en la organización.

Un factor preponderante en la definición de resultados es la alineación de los objetivos de TI con los objetivos de la organización. En muchos planes de trabajo anuales de TI, las metas aparecen en función de objetos de TI. Las metas son medidas a través de métricas como Sistemas terminados, servidores instalados, firewalls instalados, máquinas configuradas y similares. Aunque los objetos de TI son importantes para hacer funcionar el negocio, estas métricas no dicen mucho a personas fuera del departamento de TI, haciendo difícil percibir el verdadero aporte de la función de TI. Por ejemplo, si estamos hablando de una empresa que vende al detalle, con muchas sucursales, es importante que las metas de alto nivel de TI, las que van a ser visibles a todos, estén definidas en función del porcentaje de operaciones de venta que se han sistematizado, el número de vendedores que han sido entrenados en el uso de los sistemas de venta, los porcentajes de tiempo activo y similares. Es trabajo de quién dirige la función de TI el establecer metas de más bajo nivel, más operativas para los diferentes departamentos que tendrán responsabilidades para cumplir con las metas de alto nivel. Esto es incluso beneficioso para el funcionamiento de todos los componentes de TI. Cuando el personal técnico puede visualizar que su trabajo tiene un impacto directo en las metas organizacionales y que la alta dirección tiene total claridad de esa meta, el nivel de logro de objetivos tiende a ser de cien por ciento.

Este enfoque esta haciendo que en algunas empresas, especialmente aquellas con alto nivel de uso de tecnología en su producto o servicio final, el papel del CIO sea equiparable al del CEO, obligando al trabajo colaborativo entre estas dos funciones. La lógica de esto también esta en que en las organizaciones grandes se ha reconocido la necesidad de un área estratégica de apoyo de la función de TI, que piense en los resultados que son necesarios para apoyar efectivamente al negocio y que tenga los conocimientos técnicos para definir las metas de más bajo nivel que se alinean directamente con las de alto nivel. En un caso como el salvadoreño, en el que los modelos de gestión no siempre se actualizan, los directores o gerentes de TI tienen la labor doble de ejercer las funciones de un CIO, hablando con el negocio y definiendo conjuntamente con la alta dirección, las metas de alto nivel, para luego traducirlas a metas más específicas para cada componente de su gestión de TI.  Esto a veces pasa por aprender sobre las últimas tendencias del Gobierno de TI, para no tener que reinventar la rueda en el esfuerzo por realizar una mejor función de gestión de las Tecnologías de la Información.

A %d blogueros les gusta esto: