Calidad del Servicio TI - SERVQUAL

La última sesión teórica se dedicó a estudiar SERVQUAL, una herramienta diseñada para medir la calidad del servicio. Para ello, considera las siguientes dimensiones:

• Elementos tangibles: apariencia de instalaciones y equipamiento
• Confiabilidad: aptitud para entregar el servicio
• Respuesta: predisposición y rapidez para ayudar a los clientes
• Seguridad: conocimiento, cortesía y aptitud para transmitir confianza
• Empatía: cuidado y atención individual que se proporciona a los clientes

Analizar las mediciones desde dos puntos de vista:

• Expectativas
• Percepciones

Entonces se analiza la brecha existente (Q (Calidad) = Percepciones - Expectativas) entre ambos puntos de vista. Si las percepciones superan a las expectativas tendremos una calidad del servicio aceptable, de forma general.

Por tanto, para realizar un estudio de calidad se deberá:

1. Diseñar la muestra
2. Recolectar datos (encuestar)
3. Procesar los datos: calcular la brecha y ponderar las dimensiones
4. Presentación de resultados

Tema 4 - Gestión de la Calidad

En este cuarto y último tema de la asignatura se trata la gestión de la calidad. Partimos como casi siempre de un concepto central, en este caso calidad.

Definimos calidad como "adecuación de las características de un producto o servicio a las necesidades de sus clientes, de tal forma que satisfaga los requisitos de estos". 

Además, también se presentan como importantes los siguientes conceptos:

• Control de calidad
• Gestión de calidad
• Sistema de calidad
• Plan de calidad
• Auditoría de calidad

Sus definiciones se pueden encontrar en la actividad realizada que está disponible en mi portafolio de la asignatura. Además, la relación entre las mismas se explica en este mapa conceptual:

Así, encontramos los elementos que influyen en la calidad: las buenas prácticas, las herramientas, las personas y las medidas y métricas.

La gestión de la calidad en referencia a las TI se basa en seis ejes:

1.- Políticas

La política de calidad de una organización debe ser suscrita por la alta gerencia para demostrar compromiso y además deberá asegurarse de que todo miembro de la organización la comprende y asimila.

La escritura de una política de calidad debe basarse en los principios básicos de calidad, que son:

• Enfoque hacia el cliente
• Liderazgo
• Compromiso con las personas
• Enfoque basado en procesos
• Enfoque del sistema hacia la gestión (interacción de procesos)
• Mejora continua
• Enfoque hacia la toma de decisiones
• Relaciones mutuamente beneficiosas con el exterior

2.- Objetivos

Los objetivos, como siempre que se marcan objetivos, deben cumplir unos requisitos: tener un horizonte temporal definido, ser alcanzables, realistas, algo ambiciosos, etc. Deben servir para motivar y analizar, entre otras cuestiones.

Centrados en la calidad de un software, los objetivos deben gestionarse a tres niveles:

• Nivel de proyecto (todas las fases del mismo)
• Nivel de proceso (todas las áreas de proceso implantando metodología)
• Nivel de producto (corrección de defectos)

Además, la calidad puede verse desde el punto de vista del cliente (sus requisitos y expectativas) o desde el punto de vista del desarrollador (la calidad se obtiene cumpliendo todas las especificaciones del cliente).

3.- Planificación

Se deberá realizar un plan de calidad de los proyectos, que describe la adaptación del sistema de gestión de calidad a cada uno de los proyectos particulares. Deberá cubrir los siguientes temas:

• Objetivos y metas de calidad
• Alcance del sistema de gestión de calidad
• Recursos necesarios
• Análisis coste-beneficio
• Actividades y resultados
• Planificar
• Análisis de riesgo

4.- Control

Se compone de las actividades de control, que incluyen pero no se limitan a definir la diversidad de los defectos, inspeccionar documentos y código y realización de pruebas.

Como es lógico, para realizar un control efectivo se servirá la organización de indicadores, que ya hemos trabajado en temas anteriores. Es importante que los indicadores sean de valor y aporten información. Además, se recomienda elaborar un procedimiento que esté estructurado para la medición y análisis de los indicadores.

5.- Mejora

Para impulsar la mejora de la calidad, se debe permitir que todos los implicados en la organización se involucren con la calidad. Toman vital importancia la revisión y actualización constantes.

6.- Aseguramiento

Asegurar la calidad implica obtener la confianza del cliente. En cuanto al software, no es tan sencillo generar confianza en los clientes ya que las relaciones no suelen perdurar a lo largo de los años por la volatilidad de las organizaciones de desarrollo. Para evaluar un producto software se debe considerar:

• Aseguramiento de proceso (verificación mediante auditorías)
• Aseguramiento de producto (cumplimiento de requisitos)
• Aseguramiento del sistema de calidad (auditorías del propio sistema de calidad)

En todo este tema de gestión de la calidad podremos tomar como referencia las normas ISO, como de costumbre, correspondiendo en este caso las normas ISO 9000. Además, también existe EFQM (European Foundation for Quality Management), que tiene como misión impulsar la excelencia sostenida en Europa.

Entrando en el tema software de forma específica, existe la relativamente nueva (2015) norma ISO 25000, que define requisitos y evaluación de características de calidad en el desarrollo software.

Resumen Tema 3

Hemos dedicado la última sesión de Tema 3 a recapitular, realizar un mapa de conceptos del tema y su interpretación textual.

A la hora de elaborar el mapa ya Mindomo alerta de que solo se pueden tener tres mapas en la cuenta gratuita por lo que será este el último que se pueda subir sin tener que estar esquivando las restricciones. 

En lo que respecta a este tema, las valoraciones realizadas son las siguientes:

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

En comparación con los temas anteriores, hay que tener en cuenta que en este se realizó un caso práctico y un cuestionario de cumplimiento de la norma ISO. Esta última actividad fue algo abstracta, a la par que tediosa por lo que la valoración de las actividades ha caído un punto.

Las impresiones no varían en exceso con los temas anteriores. Las actividades requieren un tiempo extenso que, para el aprendizaje obtenido, quizás se podría adquirir con actividades más simples o con menor número de ellas.

Gestión de los Servicios TI

En esta sesión hemos trabajado con la gestión de los servicios relacionados con las TI, por lo que es importante tener claro de inicio que es un servicio TI. Lo vamos a definir como un "medio para entregar valor a los clientes facilitándoles los resultados que quieren conseguir sin que tengan la propiedad de costes y riesgos".

En todo este tema de servicios y su gestión tomaremos como referencia a ITIL, que proporciona un conjunto de las mejores prácticas para la gestión de los servicios TI, entendiendo esta gestión como las capacidades de la organización especializadas para proporcionar valor a los clientes mediante los servicios.

Así, entre los objetivos de esta gestión de los servicios TI encontramos:

• Alinear los servicios TI con las necesidades del negocio y sus clientes
• Mejorar la calidad de los servicios TI
• Reducir el coste en la provisión de estos servicios

Para trabajar en esta gestión emplearemos ITIL, como ya se comentó anteriormente, pero también se toma como referencia la norma ISO 20000, sabiendo que ella también se basa en las prácticas recomendadas por ITIL. Por ello, la diferencia clave entre ambas es que ITIL es utilizada para certificar a las personas mientras que la norma ISO se emplea para certificar a las organizaciones. A modo de resumen diríamos que ISO proporciona un checklist de ítems que coleccionan las buenas prácticas recomendadas por ITIL.

Lo que ITIL ofrece y posteriormente la norma ISO certifica es que la organización cuente con:

• Procesos alineados con los requerimientos del negocio
• Personal del área de TI que entiende lo que se requiere de ellos
• Procesos definidos, medidos, comunicados, usados y mejorados de forma continua
• Una estrategia de administración de servicios definida claramente

La principal diferencia entre la norma ISO 20000 (Estándar) e ITIL (Guía de buenas prácticas) es que la norma permite ser auditada, de tal forma que las empresas pueden certificarse en esta norma mientras que ITIL certificará a las personas.

La gestión de los servicios la dividiremos en cinco fases:

1. Estrategia

Debe mantener las "4P de Mintzberg": perspectiva, posición, planificación y patrón. Requiere un enfoque multidisciplinar. Los procesos de esta fase incluyen:

• Gestión de la demanda
• Gestión financiera
• Gestión del portfolio de servicios

2. Diseño

Diseño de nuevos servicios o modificación de los existentes para incorporarlos al catálogo de servicios y a la producción. Entre sus procesos están:

• Gestión del catálogo de servicios
• Gestión de niveles de servicio
• Gestión de la capacidad
• Gestión de la disponibilidad
• Gestión de la continuidad de los servicios TI
• Gestión de la seguridad de la información
• Gestión de proveedores

Destacable el primero de ellos, la gestión del catálogo, por ser esta la que incluye la oferta de servicios y debe ser tratada con especial atención ya que es el documento que guía a los clientes a la hora de seleccionar un servicio.

Además, deberá contener el SLA (Acuerdo del nivel de servicio) donde se definen a un gran nivel de detalle las especificaciones del servicio (vigencia, alcance, objetivos, etc.), los OLA (Acuerdos de nivel de operaciones), que determinan los procesos y procedimientos a nivel interno que son necesarios para ofrecer los SLA anteriormente indicados y los UCs (Contratos de soporte con proveedores) que determinarán precisamente el nivel de responsabilidad de estos proveedores externos en el proceso de prestación de servicios.

3. Transición

La cuestión de esta fase es hacer que lo que se ha definido en la fase de diseño se pueda integrar en el entorno de producción para que sea accesible a los clientes y usuarios autorizados. Sus procesos son:

• Planificación y soporte a la transición
• Gestión de cambios. Aprobación de modificaciones
• Gestión de la configuración y activos del servicio
• Gestión de entregas y despliegues. Control de versiones
• Validación y pruebas
• Evaluación (En términos de calidad)
• Gestión del conocimiento

4. Operación

Se centra en el uso diario y cotidiano de los servicios desarrollados. Los procesos identificados en esta fase son:

• Gestión de eventos
• Gestión de incidencias
• Petición de servicios TI
• Gestión de problemas
• Gestión de acceso a los servicios TI

5. Mejora continua 

Esta fase está ubicada también como gestión de la calidad, entendiendo la mejora continua como un proceso continuo en busca de la calidad en los servicios prestados. En esta fase emplearemos el ciclo "Actuar, planificar, realizar, comprobar", de forma continua, consolidando niveles de calidad y creciendo de forma constante.

Gobierno TI. Metodologías COBIT y PMBOK

Dentro del estudio del gobierno corporativo y en concreto el gobierno de las TI se encuentran diversas metodologías como la norma ISO 38500 que ya estudiamos en la clase anterior. En esta nos centraremos en otras dos: COBIT y PMBOK.

COBIT (Control Objectives for Information and related Technologies) ofrece un conjunto de buenas prácticas mediante un marco de trabajo basado en procesos. Se dirige al control principalmente, dejando de lado la ejecución.

Así, se orienta hacia el negocio, vinculando los objetivos del negocio con las metas de las TI, alineando las estrategias y proporcionando métricas y modelos de madurez para medir logros. Es, en resumen, un nexo entre los negocios y las TI.

Características clave del modelo del marco de trabajo de COBIT

Áreas focales del Gobierno TI

Las áreas en las que se centra el COBIT son la alineación estratégica de las TI con el negocio, la administración de los recursos y los riesgos TI y la medición del rendimiento.

Orientación al negocio

El principio fundamental se resume en que la empresa deberá invertir, administrar y controlar los recursos TI mediante una estructura de procesos que ofrezcan los servicios que suministren información de calidad.

Orientación a los procesos

Una de las bases de COBIT es la distinción entre gobierno TI y gestión TI. Así, encontramos los procesos de gobierno, aquellos que desarrollan los objetivos de gobierno proporcionando la dirección TI, y los procesos de gestión, centrados en desarrollar las prácticas y actividades y cubriendo PBRM (Planificar, Construir, Ejecutar y Monitorizar).

Dentro de este ítem aparece el dominio de gobierno TI, basado en EDM (Evaluar, Orientar y supervisar.

Basado en controles

Se define el control como las medidas existentes para evitar los eventos no deseados y promover su detección y corrección, disminuyendo el riesgo.

Existirán unos objetivos de control de TI, compuestos por:

• Controles del negocio y controles TI
• Controles generales de TI y aplicación

Medidas e indicadores

Para medir dónde se encuentran y dónde deben mejorar, COBIT propone:

• Modelos de madurez. Sus niveles son:
1. No existente
2. Inicial
3. Repetible
4. Definido
5. Administrado
6. Optimizado
• Metas y mediciones de rendimiento para los procesos TI
• Metas en actividades

PMBOK (Project Management Body Of Knowledge) es una guía con fundamentos para la dirección de proyectos desarrollada por el Project Management Institute (PMI). 

Se define proyecto como un conjunto de actividades interdependientes orientadas a un fin específico con duración predeterminada. Así, tendrán un inicio y un final definidos, debiendo tener un resultado único, lo que lo diferencia de las tareas. Dirigir proyectos plantea la necesidad de obtener un equilibrio entre coste, alcance, tiempo y calidad, además de los riesgos.

A la hora de dirigir un proyecto PMBOK identifica 42 procesos para transformar un proyecto en procesos concatenados, considerando para cada proyecto entradas, herramientas, técnicas y salidas.

Los procesos además se clasificarán según: 

Dimensión temporal 

• Procesos de inicio
• Procesos de planificación
• Procesos de ejecución
• Procesos de control
• Procesos de cierre

Dimensión funcional

Agrupa los procesos en función a las áreas de conocimiento a las que pertenecen. Como ejemplo de estas áreas están Gestión del alcance, gestión del tiempo, gestión de los costes y gestión de la calidad, aunque existen varias más.

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.