Semana 8 de Junio de 2008
Arquitectura de Sistemas
El desafío de hoy
Entrevista por Ricardo Seguel P.
El entrevistado de esta quincena es Mario Saffirio, Ingeniero Civil Electricista con más de 30 años de experiencia en tecnologías de información, se ha dedicado en los últimos 8 años a la dirección y ejecución de proyectos de implementación de sistemas ERP. Actualmente es Enterprise Architect en Embotelladora Andina S.A., Chile.
Mario Saffirio
Enterprise Architect at Embotelladora Andina S.A.
Los sistemas de información son escenciales para las operaciones de la empresa moderna. El diseño de la arquitectura de sistemas es una fase crítica que debe ir alineada con la estrategia de la organización para el soporte adecuado de los procesos de negocios. Esta quincena Mario Saffirio comparte con nosotros su punto de vista y basta experiencia en el área.
¿Cuál es tu visión acerca de la evolución de los sistemas de información en la industria chilena?¿ha sido muy rápida, vamos bien encaminados o nos falta algo?
Si uno se atiene a la publicidad de los sistemas de información que se comercializan en Chile, vemos que la gran mayoría se autodenomina ERP. Sin entrar en mayores análisis técnicos, esto muestra una evolución hacia los procesos de negocios y hacia la integración funcional.
Por otra parte, los sistemas ERP nacionales y los desarrollos propios de las empresas han perdido terreno en relación a los provistos por empresas extranjeras. En mi opinión esto se debe que los sistemas deben incluir mayor funcionalidad y calidad, además que los proveedores de sistemas de clase mundial garantizan mejores niveles de soporte.
En cuanto a si vamos rápido en la evolución, me parece que no y, mi explicación es que el desarrollo de nuestro mercado interno no implica mayores exigencias a las empresas. En otras palabras mientras el negocio sea bueno o no exista una crisis, las presiones por innovar son débiles.
¿Cuáles son las consideraciones más importantes al diseñar la Arquitectura de Sistemas de una organización?
Considerando la definición de la TOGAF, que la Arquitectura de Sistemas es: “La estructura de los componentes, de sus interrelaciones y de los principios y directrices que gobiernan su diseño y evolución en el tiempo”.
Es, en primer lugar muy importante, determinar si efectivamente se necesita invertir dinero en la Arquitectura de Sistemas, y siendo pragmático, la necesidad resulta del grado de desintegración de los sistemas en uso y si se quieren usar modelos de Procesos de Negocios formalizados (BPM).
Luego, si se decidió establecer una Arquitectura de Sistemas, considerar al menos una que tenga: Modelo de Performance (corporativo), Modelo de Negocios, Modelo de Sistemas de Información, Modelo de Datos y Modelo de Infraestructura.
Por otra parte, tengo la impresión que la Arquitectura de Sistema es útil a organizaciones grandes, que normalmente tienen sistemas informáticos complejos (legacy y múltiples proveedores) y área de Informática con muchos profesionales y consultoras que poner de acuerdo.
¿Cuáles son los desafíos al llevar a cabo un proyecto de implantación de nuevas tecnologías de información como parte de la Arquitectura de Sistemas en una organización?
Creo que la Arquitectura de Sistemas es un elemento de apoyo y, que hoy el gran desafío de las empresas es introducir BPM. Los aspectos claves de este proyecto son tener en cuenta que las empresas tienen en funcionamiento los proceso de negocios (de otro modo no estarían vivas) y, que por tanto no se puede interrumpir o poner en riesgo de interrumpir la operación diaria, y por otra parte la estructura organizacional tiene una inercia al cambio grande motivada por el asunto del poder.
Del primer punto surge como primer desafío establecer un mecanismo que nos permita determinar cuales son los procesos necesarios de mejorar, más bien que parte de ellos, y aquí el análisis de gap es muy valioso. Es conveniente recordar que la necesidad de mejoramiento la gatilla la estandarización (mismo proceso para toda la organización), la aparición de nuevas funciones en el software (reemplazo de desarrollos propios por funciones estándar o uso de las nuevas funciones) y, la calidad de los procesos en operación (parcialmente implementados, engorrosos, manuales, poco confiables, etc.)
La introducción de BPM crea la figura del Dueño de Procesos de Negocios, que literalmente corta la organización, ya que en un proceso normalmente participa gente de varias unidades o gerencias. Es decir, la estructura organizacional debe evolucionar a un modelo matricial, y esto es un problema político, no informático, y que a mi juicio es el principal escollo a sortear para llegar a un uso efectivo de BPM.
¿Cuál es tu visión acerca de IT Governance y BPM, podríamos considerarlos complementarios?
Me parece que son efectivamente complementarios. Simplificando, asumamos que Gobernabilidad (estoy pensando en Gobernabilidad de la empresa, no solo de IT) es algo que hace que un sistema se ocupe de acuerdo a una determinada manera, entonces con Gobernabilidad nos estamos refiriendo a como se usan los sistemas. Por otro lado si consideramos que, nuevamente simplificando, dividimos el Ciclo de Vida de un Sistema en Etapa de Implementación y Etapa de Operación, vemos que los proyectos se refieren normalmente a la Implementación y esta termina con el Go Live, lo que ocurra después no es de incumbencia o de interés de los ejecutores del proyecto.
Por otra parte, todos tenemos la experiencia, directa o escuchada, de proyectos de implementación terminados y pagados satisfactoriamente que, o no se usan, o su uso esta totalmente degradado respecto a la idea original. Aquí es donde la Gobernabilidad surge como una aliada, porque apunta al uso, es decir a la Etapa de Operación y, durante esta los responsables de Gobernabilidad tienen que hacer auditorias para asegurar que los sistemas/procesos se utilicen de acuerdo a lo normativa pertinente.
Aquí surge la necesidad de explorar que se entiende por “Sistema Bueno” y como podría medirse.
En el post titulado "Mapa de Negocios" de tu blog, mencionas los niveles de madurez del Dr. Michael Hammer ¿podrías comentarnos algo de eso? Según tu opinión ¿cuál seria el nivel de madurez de la industria chilena en términos generales?
Hammer me parece interesante porque primero tuvo que ver con la re-ingeniería, que era borrón y cuenta nueva, y últimamente desarrolló un modelo de madurez que plantea dos dimensiones de madurez: los procesos y la organizacional –enterprise.
Para los procesos considera como habilitadores de la madurez: a) El diseño (propósito, contexto, documentación); b) Usuarios (conocimientos, habilidades, comportamiento frente al cambio); c) Dueño (Individualizado, pro-activo, con autoridad); d) Infraestructura (sistemas de información y recursos humanos) y, e) Métricas (definidas y en uso).
A nivel organizacional considera: a) Liderazgo (awareness, alineamiento, comportamiento, estilo); b) Cultura (Equipo de trabajo, foco en el cliente, responsabilidad, actitud frente al cambio); c) Conocimiento (personas, metodologías) y, d) Gobernabilidad (modelos de procesos, accountability, integración).
Mezclando las categorías de madurez de Hammer y la escala de madurez de la COBIT generé para la empresa en que trabajo, Embotelladora Andina S.A., una escala de madurez orientada a medir el uso de la tecnología SAP, la estandarización de procesos (grado de parecido entre las implementaciones de las distintas filiales) y Gobernabilidad (procedimientos, normas internas y SOX). De esto espero comentarles próximamente en mi blog.
Ahora, en relación a la madurez de la industria chilena mi opinión es que somos seguidores y conservadores, principalmente porque nuestra economía es pequeña y poco orientada al riesgo. De modo que al comparar el uso informático en Chile versus al de USA, vamos por detrás, en particular la introducción de tecnologías, productos o nuevas prácticas tienen una adopción lenta. Quiero señalar que esto no es necesariamente una desventaja, me parece que la ventaja se obtiene cuando los sistemas informáticos realmente contribuyen y aportan al negocio.
Santiago 8 de Junio de 2008.