Gobierno Corporativo y Gobierno TI

En primer lugar, aquí esta el formulario generado como actividad asociada a esta sesión teórica en el que se realiza la comprobación del nivel de implantación y cumplimiento de la normativo ISO 38500 que posteriormente detallaremos. Para evaluarlo, como criterio escogeremos un sistema de puntuación simple, en el que cada sí supone 1 punto y cada no 0 puntos. Así, sobre 27 preguntas, se considera que una organización cumple la normativa a partir de los 20 puntos. Para un cumplimiento completo, se deberá obtener una puntuación de, al menos, 25 puntos. Continuamos describiendo lo trabajado en la clase del lunes 12 de noviembre sobre este tema:

En una organización el gobierno corporativo es aquel que la dirige y controla. Su buen funcionamiento se debe basar en la correcta distribución de responsabilidades entre Consejo de Administración y directivos. 

Definiremos el gobierno de las TI como "una responsabilidad del gobierno corporativo, ya que es una parte de él. Como tal debe mantener una vista de gobierno que alinee las TI con la estrategia de la organización y su propio gobierno funcional, para que las TI funcionen de manera eficiente y efectiva. Además, debe motivar el comportamiento deseable de las TI, así como incluir tanto procesos de gobierno como perspectivas de estructura, es decir, ir desde lo más abstracto a lo concreto. Así, las TI se emplearán para obtener el mayor valor del negocio mediante el desarrollo y control de responsabilidades efectivas, gestionando los riesgos asociados a las TI. Por último, no debe olvidarse de mantener una perspectiva no solo actual sino futura de estas."

Este gobierno de las TI es cada vez más importante ya que el gasto en TI no es controlado como se debiera y en muchas ocasiones no se consigue hacer un uso eficiente de las TI.

Es un hecho que las TI son cada vez más asequibles y de forma universal por lo que, en sí mismas, no se consideran un factor diferenciador, debiendo sacar el máximo provecho de ellas para poder obtener una ventaja. Por este motivo, en el futuro todos los departamentos de informática deberán tener implantadas buenas prácticas que definan, midan y analicen los procesos relacionados con las TI para su mejora continua.

Hay que tener presente la importante diferencia entre gobierno de las TI y gestión de las TI. Mientras el gobierno, como ya se mencionó, se encarga de la fijación de estrategias en TI que vayan de acuerdo a la estrategia de la organización, la gestión se centra en administrar estas TI día a día.

Para ejecutar este gobierno de las TI existen diversos marcos de referencia, siendo las metodologías más comunes ISO 38500, COBIT, ITIL y PMBOK.

Entrando un poquito en la norma ISO 38500, vemos que podemos resumir los propósitos de la norma en tres fundamentales:

• Generar un gobierno corporativo de las TI en el que se pueda confiar
• Informar y orientar a los directores de las TI en la organización
• Proporcionar una base para la evaluación objetiva del gobierno de las TI

En resumen, la norma proponer gobernar las TI mediante tres tareas: evaluar, dirigir y monitorizar. 

Por evaluar se entiende examinar y juzgar el uso actual y futuro de las TI, mientras que dirigir se basa en gestionar la preparación y ejecución de las políticas marcadas, asignando las responsabilidades oportunas. Por su parte, monitorizar sirve para vigilar el rendimiento de estas políticas, controlando que se ajusten a lo planificado.

Los principios que sigue la norma ISO y que van a ser trabajados con estas tres tareas son los siguientes:

• Responsabilidad: todo el mundo dentro de la organización comprende y acepta sus responsabilidades con respecto a las TI
• Estrategia: la estrategia de la organización debe tener en cuenta las capacidades de las TI así como las estrategias TI satisfacen las necesidades de la estrategia del negocio
• Adquisiciones: las compras relacionadas con TI (en definitiva los gastos en TI) deben hacerse por motivos válidos, con una justificación sólida de los mismos.
• Rendimiento: las TI dan soporte a la organización prestando servicios con los niveles y calidad acordados y necesarios para alcanzar los objetivos de la organización.
• Cumplimiento: las TI deben cumplir con la legislación y las normativas obligatorias.
• Factor humano: Las TI respetan la conducta humana, incluyendo las necesidades de todos los implicados en el proceso.

Al implementar un gobierno TI, deben seguirse unas cuantas pautas:

• Alineación estratégica
• Gestión de riesgos: control interno
• Gestión de recursos: asegurar una infraestructura adecuada para las TI, que permita reaccionar a los cambios del mercado, ser flexible. Debe tener en cuenta que el recurso más valioso son las personas.
• Medición del desempeño: establecer medidas de ejecución y seguimiento. Incluye auditorías.
• Ciclo de vida del gobierno TI
• Entorno del gobierno TI: condiciones y circunstancias por las que se ve afectado el gobierno TI.
• Partes interesadas (Stakeholders)

Los beneficios de la aplicación de la norma ISO 38500 son variados: incentiva a las empresas a usar estándares apropiados, provee un marco de principios básicos, es aplicable a todas las empresas y colabora con la consecución de las obligaciones legales en materia de TI.

Introducción al Tema 3 - Metodologías

Esta entrada corresponde a la primera sesión en la que se ha trabajado el Tema 3, que trata las diferentes metodologías de desarrollo de sistemas. En esta ocasión no pude asistir a la clase presencial así que lo aprendido ha sido de manera autodidacta siguiendo la documentación de la asignatura y con la colaboración de los compañeros.

Esta introducción a la metodología, como toda introducción, consiste inicialmente en centrar el contexto y definir el tema a estudiar. Así, definimos metodología como el conjunto de métodos seguidos en una investigación o exposición. Sin embargo, orientado a los sistemas de la información y al desarrollo de software, la metodología es el conjunto de herramientas y técnicas utilizadas para la creación del software.

Las metodologías tendrán como objetivos los siguientes:

• Determinar los requisitos
• Proporcionar un método de desarrollo
• Construir un sistema a tiempo y con costes razonables
• Que el sistema construido sea sencillo de mantener y esté bien documentado
• Que sea capaz de identificar rápidamente los cambios necesarios
• Que el sistema satisfaga a todas las partes implicadas en la creación de este

Además, toda metodología deberá seguir de forma genérica las fases de planificación, análisis, diseño, implantación y mantenimiento del sistema a construir. Así, a la hora de elegir una metodología se tendrán en cuenta las siguientes características deseables en estas:

• Existencia de reglas
• Cobertura de todo el ciclo de desarrollo
• Planificación y control
• Fácil formación sobre esta
• Determinación de las herramientas a emplear
• Soporte para el mantenimiento
• Soporte para la reutilización

Actualmente se distingue entre las metodologías tradicionales y las actuales también denominadas ágiles. La diferencia fundamental se centra en la reacción a los cambios. Mientras las tradicionales plantean unos objetivos y generan un desarrollo en base a ellos, las metodologías actuales son capaces de reaccionar a cambios de objetivos producidos incluso durante la fase de desarrollo.

Este cambio de tradicionales a las ágiles actuales se basa en la necesidad de adaptarse a los continuos cambios propuestos por los clientes de los S.I. Las metodologías ágiles son más capaces de adaptarse a entornos cambiantes y reaccionar a las continuas peticiones de los clientes.

Entre las metodologías tradicionales encontramos Merise, SSADM y Métrica v.3, siendo esta propia de la Administración Pública española.

Merise, desarrollada por le gobierno francés tiene en su ciclo de vida el estudio previo, estudio detallado (compuesto por análisis y diseño), realización y puesta en marcha y, por último, el mantenimiento.

SSADM (Structures Systems Analysis and Design Method) fue desarrollada por el gobierno británico y enfatiza en los usuarios, con el siguiente ciclo de vida: viabilidad, estudio del sistema actual, opciones de sistema del negocio, definición de requisitos, opciones técnicas, diseño lógico y, finalmente, diseño físico.

Métrica v.3, como ya se comentó, es la metodología oficial de desarrollo de la administración española. Su ciclo de vida se compone de: Planificación, Desarrollo (Estudio de viabilidad, análisis, diseño, construcción e implantación y aceptación) y mantenimiento.

Por otro lado encontramos las metodologías ágiles: XP (Programación externa), Crystal, Desarrollo adaptable, Scrum y Método de desarrollo de sistema dinámico (DSDM).

Scrum es una metodología indicada para proyectos que tengan muchos cambios de requisitos. Es muy simple y su ciclo de vida se divide en:

• Visión general del producto a desarrollar, especificando aspectos según prioridad
• Desarrollo en iteraciones (sprint) cada una de un mes de duración
• Finalizada la iteración, es revisada por todo el personal

Se desarrollan los cambios de forma incremental y continua.

Por su parte, DSDM propone cinco fases: estudio de viabilidad, estudio del negocio, modelado funcional, diseño y construcción e implementación, siendo las tres últimas iterativas con realimentación.

Sabiendo que las metodologías ágiles son más flexibles y permiten una mejor adaptación a los cambios, siendo una característica muy necesaria en la actualidad ya que los requisitos son modificados con asiduidad, también existen varias críticas a estas metodologías.

Entre estas críticas se destacan la falta de estructura y documentación, la alta necesidad de encuentros entre cliente y desarrollador con altos costes para el cliente, además de que puede generar negociaciones contractuales más complejos.

Resumen Tema 2 - Gestión por procesos (BPM y SOA)

Última sesión del Tema 2 dedicada a realizar actividades encaminadas a afianzar los conceptos estudiados a lo largo de las distintas sesiones del tema 2.

Entre otros, se han realizado un mapa de conceptos con los más importantes trabajados en este tema, su interpretación textual y todo ello se carga en el portafolio de la asignatura.

Ya en este tema 2, parece uno estar algo más hecho a trabajar con Mindomo y Pathbrite para elaborar mapas y el portafolio, respectivamente. Sin embargo también se va encontrando con defectos de los mismos que hay que sortear como se puede.

A continuación se valoran en escala 0-5 los items requeridos con respecto al Tema 2 de la asignatura:

Las actividades desarrolladas	4
Recursos facilitados	4
Desarrollo del tema	3
Actuación del tutor	4
Eficacia del aprendizaje en relación con el tiempo invertido	2
Facilidad del entorno	3
Valoración general	3

Haciendo una breve comparativa con el tema anterior, en esta ocasión valoro positivamente dentro del apartado de actividades desarrolladas el haber realizado un cuestionario que puede aportar una idea de aquellos conceptos clave que debemos comprender al 100%. Además, en cuanto a los recursos facilitados, mejora por la realización final y dividida del glosario, que permite no tener que "pelear" por los términos. 

De resto, las impresiones son similares, se invierte mucho tiempo en realizar todas y cada una de las actividades para aprender el temario que se expone cuando, en mi opinión, esto podría realizarse con una carga de trabajo algo inferior.

Gestión por procesos - BPM y SOA

En esta ocasión se continuó tratando sobre el BPM (en el marco de la gestión por procesos) pero centrado en el SOA (Service Oriented Architecture), es decir, en una arquitectura basada en servicios.

Así, descompondríamos los procesos en servicios, generalmente de carácter mínimo y genérico, para su aprovechamiento generando eficiencia en la organización.

Sabiendo esto, diremos que BPM y SOA son tecnologías complementarias, que usadas en conjunto pueden impulsar a la organización a mejorar sus resultados.

Como ya hemos dicho, SOA se basa en la descomposición en servicios, pero para ser aplicada los servicios deben seguir unos principios:

• Deben ser reutilizables: ser mínimos y pensados para su reutilización y su uso masivo por diversas tareas.
• Deben proporcionar un contrato formal (SLA)
• Deben tener bajo acoplamiento: son independientes los unos de los otros.
• Deben permitir la composición: serán mínimos para que, mediante composición de varios, se consigan servicios genéricos de mayor nivel.
• Deben ser autónomos: entorno de ejecución propio e independiente para su reutilización.
• No deben tener estado: no deben guardar ningún tipo de información (evita la inconsistencia).
• Deben poder ser descubiertos: de tal forma que se evite la creación de un servicio que ya existe.

Los servicios se localizarán en el portfolio de servicio (que muestra la información desde la perspectiva del negocio) y en el catálogo de servicios (parte del portfolio accesible por los clientes). Según ITIL, los servicios pueden ser:

• De negocio: soporte directo a los procesos de negocio y accesibles por los clientes externos.
• IT: soporte a los procesos internos del negocio y accesibles por los clientes internos.
• De infraestructura: más técnicos y de nivel más bajo. Accesibles por los servicios IT.
• De soporte

Dentro de los servicios, encontramos un tipo denominado "Servicios web". Debe quedar claro que los servicios web no son lo mismo que un SOA, ya que ambos términos suelen confundirse. SOA implica relación con procesos, con la estrategia de negocio e integra distintos tipos de servicios. Los servicios web, por su parte, son un tipo de servicio y forman parte de un SOA.

Estos servicios web pueden ser síncronos (se debe esperar la respuesta de la acción) o asíncronos (se invoca y la respuesta puede producirse de forma posterior).

A la hora de diseñar un BPM o SOA, se puede optar por dos alternativas:

• Enfoque Bottom-Up: trata de identificar primero los servicios y posteriormente escalar hasta la generación de procesos que utilizarán los servicios a priori detectados y diseñados.
• Enfoque Top-Down: al contrario que el anterior, identifica los procesos y, a partir de ellos, selecciona los servicios necesarios, tratando de generalizarlos para su uso por diversas tareas y procesos.

A priori, podría parecer que el enfoque Top-Down es más lógico y conveniente, pero existen casos en los que se puede aplicar el enfoque Bottom-Up, si bien es habitual que se hago un uso combinado de ambos.

Entre las similitudes de BPM y SOA:

• Desarrollan la gestión de servicios y procesos
• Tienen repositorios de servicios y procesos
• Tienen la supervisión y gestión de la funcionalidad de servicios y procesos
• Están basados en eventos

Y sus diferencias son:

• La simulación es propia del BPM
• SOA genera funciones más técnicas y de menor nivel que BPM
• SOA trata los servicios web mientras BPM se ocupa de los procesos de negocio
• BPM orientado a los usuarios de negocio que SOA

Como es de suponer, la aplicación de BPM y SOA proporciona múltiples ventajas en la organización, entre las que se destacan la agilidad, la flexibilidad, la escalabilidad, la facilidad de mantenimiento y la reducción de costes y tiempos.

Gestión por procesos - BPM (BPMN)

Profundizando en la gestión por procesos, hemos tratado todo el soporte que este conlleva. Al implantarse en organizaciones, éstas deberán cumplir algunos requisitos para ser capaces de asumir este sistema. Entre otros encontramos la agilidad. Principalmente debido a que las organizaciones se enfrentan a cambios en los modelos de negocio, la normativa, cambios en la competencia, etc.

Además, es importante hacer distinción entre la gestión por procesos y la gestión de procesos. Mientras la gestión por procesos es el sistema al que hemos ido haciendo referencia durante el tema 2, la gestión de procesos implica el control de la operativa de los procesos.

La actualidad en el mundo de las tecnologías de la información supone cambios continuos y, por ello, las organizaciones deben ser flexibles y adaptarse, eliminando las rigideces existentes.

Por ello, se debe generar una arquitectura TI acorde a esta gestión por procesos (BPM), que sea capaz de integrar las diferentes aplicaciones que la organización requiere. La arquitectura resultante debe ser accesible y manejable, debiendo proporcionar medios para medir y controlar el rendimiento del negocio.

¿Cómo tener éxito implantando BPM?

Los procesos de negocio deben estar perfectamente definidos, deben seleccionarse cuidadosamente los indicadores (KPI) y es fundamental el control constante de los procesos.

A la hora de implantar un BPM, se sugiere comenzar por un proceso que no esté funcionando al 100% y comenzar la implantación siguiendo las fases correspondientes, de tal forma que se puedan apreciar resultados pronto y con ello motivar al resto de la organización y aquellas estructuras reticentes de la eficiencia y mejora del BPM.

Componentes principales del BPM

• Modelador y documentador
• Motor
• Simulador
• Monitorización

Composición del sistema BPM

• BPM: es el proceso total 
• BPMN: es la parte que usa el consultor de negocio para representar el proceso
• BPEL: el código ejecutable del proceso
• BAM: la parte del BPM que permite la monitorización
• SOA: la arquitectura que permite implementar BPM con servicios. Su diseño es responsabilidad de los arquitectos informáticos.
• Web Services: permiten que los servicios se integren en un proceso de manera estándar. Responsabilidad de los desarrolladores.

Recursos del BPMS

• Básicos
• Modelador de procesos
• Automatización del Workflow
• Colaboración en tiempo real
• Gestión de reglas de negocio
• Interfaz de usuario personalizable
• Generador de informes instantáneo
• Avanzados
• Modelaje avanzado
• Simulador avanzado
• Análisis avanzado de procesos
• Indicador de status SLA (Service Level Agreement)
• Implementación en la nube
• Construcción de formularios

Gestión por procesos

El segundo tema de la asignatura trata sobre los procesos, lo que éstos suponen para la organización y la gestión por procesos (Business Process Management).

Así, podemos definir de forma simple los procesos como un "conjunto de recursos que operan en conjunto con un fin". Los procesos se componen de entradas (inputs), salidas o resultados (output), tienen un responsable, puntos de control y se componen de acciones. Además, hacen uso de recursos y referencias. Los procesos tendrán generalmente clientes (los que hacen uso del output del proceso) y proveedores (proporcionan el input).

Dentro de la organización, los procesos se sitúan entre las estrategias, generadas a partir de los objetivos y los procedimientos, siendo estos el conjunto de tareas necesarias para llevar a cabo un proceso.

Estos procesos los vamos a clasificar en:

• Los procesos estratégicos son trazados a nivel de alta dirección.
• Los procesos clave (u operativos) son los que tienen resultados para los clientes externos.
• Los procesos de apoyo dan soporte a toda la actividad.

Todo este tema de los procesos se puede englobar en lo que se denomina BPM (Business Process Management). Este sistema supone la eliminación de la jerarquía vertical (departamental) de las organizaciones para implantar una gestión por procesos, donde se habla de procesos y no de departamentos, con relaciones horizontales (incluso entre áreas) y no una jerarquía vertical. Esto supondría la eliminación de múltiples ineficiencias en la comunicación y además establecería un responsable único de cada proceso que sería conocedor en profundidad del mismo, lo que permitiría la localización y erradicación de forma rápida de cualquier error o problema que surja en el proceso.

Para implantar este sistema en una organización se requieren tres etapas, llamadas "olas":

• Primera ola: documentar los procesos y estandarizar
• Segunda ola: Empleo de ERP's y reingeniería para reimplementar el proceso
• Tercera ola: Implantación final del BPM

Modelo de madurez en gestión por procesos

Este modelo representa un ciclo de implantación del BPM en la organización de tal forma que controlemos en que etapa de la misma se encuentra la empresa. Encontramos las siguientes fases:

1. Reconocer ineficiencias operativas
2. Sensibilizada a gestión por procesos
3. Automatización y control intra-procesos
4. Automatización y control inter-procesos
5. Control de la valuación empresarial
6. Estructura ágil de negocios

La gestión por procesos proporciona múltiples beneficios. Por un lado los estratégicos ya que integra los elementos del proceso, proporciona flexibilidad a la empresa (reacción a cambios), simplifica (estandarizando), aumenta la productividad y permite dar imagen de organización íntegra. 

Por otro lado produce beneficios operacionales aumentando la capacidad de control sobre el procesos, uniendo empleados de diferentes departamentos y permitiendo detectar actividades que no aporten valor añadido.

El principal inconveniente de la implantación de este sistema es la confrontación que genera, ya que implica la eliminación de la jerarquía tradicional de la empresa (que muchas veces funciona por inercia) y esto conlleva una reducción del poder de algunos empleados e incluso demostrar que no son necesarios en la organización, por lo que se genera un claro conflicto de intereses.

En resumen, una organización podría beneficiarse enormemente de la gestión por procesos al implantar dicho sistema pero no es tan sencillo debido a la existencia de culturas tradicionales difíciles de erradicar por afectar de manera personal a muchos trabajadores.

Resumen Tema 1 - Trabajo de síntesis

La última sesión del Tema 1 se dedica a realizar una serie de actividades orientadas a sintetizar el tema, trabajar con sus conceptos y facilitar la interiorización de la materia.

En concreto, se trata de realizar un mapa de conceptos, utilizando la aplicación Mindomo, un resumen que "haga texto" conectado con estos conceptos, además de este propio post y la carga final de todos estos elementos en el portafolio.

Por tanto, lo aprendido en esta sesión es básicamente el manejo de las distintas herramientas a utilizar para generar los elementos antes mencionados: Mindomo y Pathbrite. Además, también la elaboración de un mapa de conceptos y la creación de un portafolio, algo que nunca antes había trabajado.

Con respecto al Tema 1 de la asignatura, tanto su resumen como sus conceptos se pueden encontrar en los enlaces antes mencionados así que pasaré a valorar en escala 0-5 los items requeridos:

Las actividades desarrolladas	3
Recursos facilitados	3
Desarrollo del tema	3
Actuación del tutor	4
Eficacia del aprendizaje en relación con el tiempo invertido	2
Facilidad del entorno	3
Valoración general	3

Como conclusión, el primer tema sirve para tomar contacto con la forma de trabajar de la asignatura, algo tediosa en mi opinión, de ahí la baja valoración de la eficacia del aprendizaje en cuanto al tiempo invertido, porque creo que, al menos en este tema introductorio, no se refleja la cantidad de tiempo en el aprendizaje. Es posible que en algún tema más complejo pueda ser eficaz la realización de mapas, resúmenes, etc.