Mostrando entradas con la etiqueta Métricas. Mostrar todas las entradas
Mostrando entradas con la etiqueta Métricas. Mostrar todas las entradas

miércoles, 17 de noviembre de 2010

Métricas Proceso de Gestión de Cambios II

Tenemos ya todo. Proceso. Su responsable. CAB. Sistema de Gestión que soporta el proceso. Por lo tanto, solamente nos queda definir, medir, evaluar y mejorar.


Establezcamos unos referentes, para definir nuestras métricas, enfocándonos en aquellos que es entrada o desencadenante del proceso. Tengamos presente indicadores de rendimiento (valores, sumatorios y otros, que nos ayuden al cálculo de los KPI) para poder medir diferentes actividades dentro del proceso, y en su salida. Con el apoyo del sistema de gestión que soporta el proceso, nos proporcione los valores de nuestras métricas e informes, podremos compararlos con los valores objetivos de efectividad, que en suma son los que realmente adquieren o deben adquirir la verdadera importancia, y los que espera el negocio.

Deben salvaguardarse todas las solicitudes de cambio registradas, pudiendo clasificar las mismas en cambios estándar o peticiones de servicio, cambios normales y cambios urgentes, por solicitante y por unidad de pertenencia de dicho solicitante.

Para los cambios normales cuya validación de ser establecida en el CAB, se debería realizar un acta por reunión, en el que se evidencien las solicitudes registradas, cuáles de ellas son aprobados, cuáles rechazadas/canceladas (indicando su por qué y remitiéndolo al solicitante), cuáles pendientes de evaluar (por falta de información). Con dichos datos, el responsable del proceso puede analizar tendencias (minimizar o reducir los cambios urgentes, por ejemplo), volumetrías e indicar por ejemplo si el personal sigue los procedimientos establecidos y conoce la forma de actuar.

Para gestionar la salida del proceso, debemos identificar con un periodo establecido por ejemplo, mensual, los cambios que han sido llevados a la práctica y cerrados. Igualmente en su entrada, por solicitante, grupo de pertenencia y tipología de cambios (estándar, normales y urgentes). De dicho cierre, a la efectividad del negocio, nos interesará conocer de los cerrados, cuáles de ellos se han cerrado en plazo y justificados en costes. El incremento de estos, hará que el proceso está alineado con el negocio, por satisfacer sus necesidades a tiempo, y en definitiva poder reducir el time-to-market.

De los cerrados fuera de plazo, sería interesante, su revisión (PIR) vía CAB o directamente por el responsable del proceso, intentando analizar y justificar dicho retraso, aunque teniendo el condicionante que se ha adoptado o se ha cumplido su objetivo. Y aquellos otros, que su realización no ha tenido éxito, identificando la marcha atrás, evaluando que acciones se van a llevar a cabo. Y en su suma, de todos estos últimos aprender de las lecciones y las casuísticas encontradas para mejorar o no volver a caer de nuevo en errores cometidos.

Teniendo unas seríe de informes de por ejemplo tres meses, podemos visualizar las tendencias, y empezar a poner factores críticos de éxito, que vayan alineados con el negocio. Es decir, Podamos comparar la salida del proceso (métricas de eficacia y eficiencia) con la que le importa al negocio las de efectividad. Las cuáles comprenden el camino entre la salida y el outcomes. Marcándonos unas metas no ambiciones, si no reales, y volviendo a medir. En caso que la salidas mensuales no se adecúen a los target, es el responsable del proceso, a través de las actividades de mejora continua el que tendrá que establecer unas medidas o acciones correctoras, para acortar dicha brecha o GAP.

Debemos de forma correcta tener indicadores qué nos sean necesarios, medibles y nos den valor para nuestro negocio. En el caso, de analizar o entender por qué no se alcanzan dichos target esperados, lo propio es dispensar o poner indicadores de rendimiento, en las diferentes actividades del flujo dentro del proceso, que nos indiquen, que es lo que no funciona o no da la salida apetecida, en tiempo o en otras circunstancias o adversidad. Con ello, granularizamos nuestro proceso, lo entendemos mejor, y en cada vuelva, lo hacemos más eficaz y eficiente, siempre mirando cumplir con los objetivos y los resultados que espera el negocio.

Tener siempre presente y para cada proceso un indicador de satisfacción del cliente y otro de salvaguarda de los niveles de servicio, los cuales, serán alcanzados y calculados de abajo hacia arriba por reglas de propagación y de ponderación de los diferentes indicadores que cada organización, para su proceso de gestión de cambios, crea conveniente llevar a la práctica.

Espero que de forma general y particularizando en el proceso de gestión de cambios, por las respectivas entradas haya ayudado al entendimiento y la forma de proceder. Para el resto de procesos, bajo sus circunstancias, es bastante parecido. Notando que el establecer métricas similares o estándares hace que la sinergia de los procesos se imbriquen o relacionen correctamente y den valor, todos ellos a la TI por su prestación pero como fin último al que le interesa. Al negocio.

Leer más...
Share/Bookmark

sábado, 6 de noviembre de 2010

Métricas Proceso de Gestión de Cambios I

El responsable del proceso de gestión de Cambios debe definir las métricas de su proceso alineadas con los objetivos del negocio; debe modelar la tipología de cambios; debe definir el impacto y la prioridad; debe establecer los parámetros de la RFC; debe supervisar el CAB; debe hacer seguimiento de los cambios; debe cerrarlos; debe supervisar aquellos que requieran la realización del PIR; debe establecer informes de gestión y métricas para indicar el grado de madurez del proceso y su alineación con el negocio.

Por tanto, debe ser un rol con autoridad, independiente y cercano al CIO, que le informe del estado de los cambios que se realicen sobre la  infraestructura (servicios y componentes que los soporta), de sus beneficios hacia el negocio y de minimizar el riesgo o el impacto sobre los cambios realizados por y para el negocio.

Todo cambio debería disponer de una RFC con una serie de campos que hagan y sirvan para valorar la viabilidad y autorización del cambio y haga de ayuda para supervisar cualquier mínimo detalle de un cambio a realizar, para minimizar cualquier tipo de impacto hacia el negocio.

¿Qué campos debería estar incluidos en la RFC?
¿Cuál es la razón del cambio; su beneficio y resultado que se espera al realizarlo?
Descripción de los pasos o proceso a realizar en el cambio.
¿Cuándo debería realizarse, indicando diferentes fechas alternativas?
¿Qué sistemas, servicios y en definitiva que CI´s se van a ver afectados por el cambio?
¿Quién es el coordinador del cambio y a quién debe ser informado por el mismo?
¿Va a ser necesario realizar un PIR una vez realizado el cambio?
¿Qué riesgos se pueden producir por la realización del cambio?
¿Qué riesgos se puede producir si no se lleva a cabo dicho cambio?
¿Requiere la actualización de la CMDB o de cualquier tipo de documentación?
Grupos de soporte necesarios para la realización del cambio.
¿Tiempo estimado para la realización del cambio?
¿Tiempo estimado en realizar la marcha atrás del cambio?
¿Bajo qué circunstancias se debe activar la marcha atrás?

Establecida la RFC, debemos indicar que los cambios estándar son las peticiones de servicio, que identifica la operativa diaria de tareas predefinidas que se realizan de la misma forma y por tanto, están pre autorizadas.

Los cambios normales son aquellos que deben ser analizados en el CAB (junta asesora de cambios) para su aprobación o rechazo. El objetivo fundamental ¿Cuál es la razón del cambio? Siempre interpretada y enfocada a proporcionar valor al negocio. FUNDAMENTAL, estudiar la planificación y grupos intervinientes. También debe analizarse los riesgos, la marcha atrás, cosa que con excepciones nunca se realiza. En definitiva, por cada cambio ver la viabilidad de dar respuesta a las preguntas antes mencionadas que debe contener una RFC como dios manda.

Los cambios urgentes, son aquellos que en su contexto a reducir y minimizar debe darse cuando, el negocio tenga una gran indisponibilidad o interrupción, en alguna de sus funciones vitales, que no pueda esperar, y por lo tanto, por su impacto y prioridad deba acometerse, tras aprobación de forma inmediata como cosa importante y como su nombre indica de forma urgente.

Tengamos presente en la definición y adopción de las métricas un hecho fundamental y alineado con toda el sistema de gestión de IT. La relación con los otros procesos. Les remito un gráfico ejemplo  de ello.


Leer más...
Share/Bookmark

viernes, 29 de octubre de 2010

Sinteticemos …sigamos avanzando…profundicemos en la materia:


Ø  CIO compartiendo mesa con CEO, en la visión, metas, objetivos, definición de la estrategia de la empresa y su plan de acción.
 Ø  Solamente existes objetivos del y para el Negocio (NegocioTI)…proyectos del Negocio, para satisfacer su demanda y necesidades (NegocioTI).


















Ø  Formalizar un sistema de gestión de calidad integrado, siendo su referente a nivel de empresa, el sistema de gestión de calidad (ISO 9001). Y englobando por las diferentes partes de la misma, crear un marco de trabajo, con otros sistemas de:

·         Gestión de Gobierno IT (CobIT, ISO 38500)
·         Gestión de Servicios (ITIL, ISO 20.000)
·         Gestión de Proyectos (PMBook, Prince2)
·         Gestión de Desarrollo (CMMi, SPICE)
·         …….

Ø  Dentro del Sistema de Gestión de Servicios IT, en su plan estratégico:

·         Crear un grupo de trabajo que supervise todo el proyecto de definición y adopción del sistema y su marco de trabajo. 
·         Realizar un Assessment para contrastar nuestros actuales procesos tomando como referente los procesos de las buenas prácticas de ITIL.
·         Priorizar y establecer un plan de acción de acuerdo a los resultados del assessment.
·         Definir los procesos estándar y su definición de métricas correspondientes.
·         Optimizar los mismos, en cuanto a las necesidad propias de la organización TI. Concienciar, comunicar, formar, adoptar el marco de trabajo, crear cultura de servicio….

Sea ITIL V2 …como ejemplo se acuerdan...




















…Caso particular de un proceso…Gestión de Cambios

Proceso que “Supervisa” la implementación de los cambios de la infraestructura (servicios y los componentes que los soportan) para promover beneficios para el negocio así como de causar el menor impacto posible al negocio. Y Supervisar que dichos cambios se realizan de acuerdo a los estándares y/o procedimientos establecidos.


Si estableciéramos dentro de nuestro modelo de procesos, las distintas métricas ha identificar según su alcance y niveles estratégicos, tácticos y operativos y su alineación con los objetivos de negocio.



Las métricas de eficacia, miden si las actividades son realizadas de forma correcta, evidenciando que siempre que se espera o se dispara una entrada, ocurrirá siempre la misma salida.
Las métricas de eficiencia, miden si estas actividades eficaces, que se realizan de forma correcta, se ejecutan con el menor coste y esfuerzo mínimo (recursos).
Las métricas de efectividad, se concentrar en que la salida del procedimiento, alcance el resultado esperado por el negocio (outcomes).

Para la siguiente entrada, se entrará a establecer dichas métricas cómo ejemplo para el proceso de Gestión de Cambios.....saludos.

Leer más...
Share/Bookmark

jueves, 28 de octubre de 2010

¿Qué se espera del Responsable del Proceso de Gestión de Cambio?

A nivel del proceso en sí, el responsable debe acometer las siguientes cuatro acciones: 
·         Definir
·         Adoptar
·         Controlar
·         Mejorar de manera continua

A nivel de salida del proceso debe:
·         Revisar todos los cambios adoptados en la infraestructura y supervisar que cumplan con los objetivos de coste, en plazo y beneficios esperados por y para el negocio
·         Supervisar que los mismos se realizan de acuerdo a los estándares y/o procedimientos establecidos
·         Emitir, distribuir, publicar y mantener los cambios programados para que los intervinientes estén informados
·         Supervisar que se tiene actualizada la infraestructura a través de la CMDB tras la ejecución de un cambio

A nivel de métricas debe planear a nivel de su proceso, y teniendo en cuenta los objetivos que espera el negocio para estar alineados con él, qué debería medir, dónde, cuándo (inclusive el momento y frecuencia), quién y cómo.

Y tener establecido un proceder para quién y con qué frecuencia se debería revisar los cambios, los métodos, los procedimientos, para auditar y demostrar cómo de bien se está realizando la labor y si se cumplen con los objetivos marcados.

Para estar alineados con el negocio, ¿qué factores debería supervisar su cumplimiento el responsable del proceso de gestión de cambios?

¿Qué indicador/es de efectividad podríamos emplear para dar su medida y cumplimiento para generar beneficios para el negocio?

Supervisar un proceso que identifique y demuestre la agilidad para efectuar los cambios que el negocio nos demanda por sus necesidades. Por lo que si conseguimos establecer los mecanismos necesarios para entregar lo que requiere el negocio a tiempo según la planificación y su adopción cumple con los requisitos marcados, la satisfacción del cliente, del negocio, será palpable.

¿Qué indicador/es de efectividad podríamos emplear para evidenciar el menor impacto posible al negocio ante la adopción de un cambio?

Claramente se podría presuponer que debemos supervisar y minimizar la indisponibilidad del negocio, debido a la adopción de cambios o las posibles degradaciones de los servicios utilizados por el negocio o interrupciones completa del negocio, por las incidencias posiblemente provocadas por la adopción de los mismos.

Leer más...
Share/Bookmark

martes, 26 de octubre de 2010

Definición del Proceso de Gestión de Cambios y sus métricas asociadas. Parte I

Alineándome con una idea de la entrada anterior, donde toda definición de proceso y sus métricas asociadas deben realizarse al mismo tiempo, siendo el objetivo de ambos conceptos - su medida -  estar únicamente relacionada por y para el negocio, establezcamos un ejemplo con el proceso de Gestión de Cambios.

La Gestión de Cambios es el proceso que “Supervisa” la implementación de los cambios de la infraestructura (servicios y los componentes que los soportan) para promover beneficios para el negocio así como de causar el menor impacto posible al negocio. El proceso que ejecuta  - brazo ejecutor del cambio - dicha implementación es la Gestión de la Entrega.

Creo que este aspecto puede ocasionar bastante confusión y espero intentar paliar  o eliminar dichas dudas sobre la misma (si las hubiere) con el siguiente párrafo.
La Gestión de Cambios evalúa el impacto del cambio (Assess: evalúa el desempeño previsto), aprueba/deniega el cambio, autoriza el cambio, por último Evalúa la post-implementación (Review: evalúa el desempeño real) y muy importante, el responsable o gestor del proceso cierra el cambio (O DEBERÍA HACERLO, por una vital cuestión: es la única manera de supervisar y tener todo bajo control de principio a fin).
Mientras que la Gestión de la Entrega, se encarga de construir el cambio, controla la implementación, informa y controla el lanzamiento y pone el cambio en producción. Así como ejecuta el PIR – realiza el estudio de la revisión post-implementación - facilitando su resultado a la Gestión de Cambios y/o Problemas dependiendo de su origen.

Gráficamente no serían dos proceso separados si no que la Gestión de la Entrega estaría “como” incrustada dentro de la Gestión de Cambios.

Su alcance debería ser definido dependiendo del ámbito de nuestra definición de infraestructura (a qué llamamos servicio y sus componentes que lo soportan) que nuestro proceso pretende supervisar su alteración de un estado a otro (posible definición de cambio). De forma genérica, está claro, que nos aparecen de forma rápida en nuestra conciencia, las categorías de HW y SW.

Y me pregunto, ¿Por qué no añadir en este punto la documentación? Cuántos problemas hay en las organizaciones, con la documentación, su generación, aprobación, versionado, su mantenimiento y revisión. Si de esta categoría se encargara el proceso de Cambios, ¿cuánto ahorraríamos en re-trabajos (dedicando nuestros recursos a otro menester o tarea, a esto se llama eficiencia) y costes en nuestro día a día, el tomar dicha decisión? Si compráramos una hucha e insertáramos el dinero de lo comentado, creo estar en disposición que el ROI de la inclusión de la documentación como elemento a supervisar por Cambios retornaría en menos de lo que estimaríamos, en un principio.

Otro ejemplo; imaginemos que nos hemos certificado en una norma. Aunque cada documento tenga o deba tener un responsable, el control de dicho documento sería supervisado de forma transversal a toda la organización, por el proceso en cuestión. Otra cosa sería su ubicación (red, intranet, CMDB, gestor documental, etc), o el apunte de dónde está ubicado (CMDB). El apunte es sencillo. Por supuesto. El realizarlo tiene bastante trabajo. Por supuesto. Estaría alineado con los objetivos de la organización, de tener un control de la documentación y que esté disponible en cualquier momento, para cualquier individuo con los correspondientes permisos y aparte sirva de evidencia para nuevas auditorías. Es obvio, que sí.

¿Qué objetivos relacionados por y para el negocio presenta dicho proceso de Cambios? Considero que para que el negocio tenga el mínimo impacto al llevar a cabo la adopción de un cambio para satisfacer una necesidad de nuevas prestaciones o por falta de capacidad en su infraestructura, es condición necesaria y suficiente, el asegurar para dicha SUPERVISIÓN que se utilizan métodos y procedimiento estándares para manejar eficiente y rápidamente dicha adopción o cambio. Y se tenga de la autoridad pertinente para su cumplimiento.

Si se dispongo de este rigor y de una cultura suficientemente implantada en la organización, las actividades del propio proceso tendrían un grado de eficacia y eficiencia bastante alto, eliminando las tales consabidas incidencias acaecidas por no disponer del rigor y procedimiento evaluador antes de realizar dicho cambio, en nuestro entorno de producción. La optimización de los recursos sería estratosférica, la priorización y calendario establecido y publicado a todos los niveles que intervinieran en este proceso o el de la entrega, recortaría y nos daría otro gran objetivo ansiado por el negocio. Entregar cambios de acuerdo a los tiempos que el negocio necesita.

Y por último si partimos con la premisa (si es de interés para la organización en la que se defina este proceso) que el responsable o gestor de cambios es el que cierra el cambio. Es el proceso de gestión de cambios el que indica cuándo se da por terminado el mismo (o incide en su marcha atrás, por no conseguir el desempeño o la razón por la cual se ha llevado a efecto en dicho instante o pasado un tiempo tras evaluar el informe del PIR realizado por la Entrega) y por tanto antes de su cierre, es el que promueve la veracidad de la información actual de nuestro infraestructura, proporcionando a la gestión de configuración, su aprobación para que establezca las nuevas propiedades, valores o atributos de sus CI´s o las modificaciones acontecidas por la adopción de un cambio.

En la siguiente entrada hablaré de las métricas asociadas a dicho proceso y cómo éstas así con la definición del proceso están alineadas como objetivo fundamental y único con el negocio.
Leer más...
Share/Bookmark

lunes, 25 de octubre de 2010

Sistema de Métricas. Parte II

He vuelto a leerme el libro “Metric for IT Service Management”. Y no hay nada como incidir en conceptos para profundizar, aseverar nuevos aprendizajes, enfoques, proyecciones y nuevos puntos de vista, que me gustaría compartir con la audiencia.

¿Cuál es el propósito de un modelo de métricas? Para mí solamente hay una respuesta. Medir aquello, que únicamente tenga sentido para el negocio. Con dicha respuesta, asevero una directriz que deberíamos tener ya presente a nivel de empresa. Desde mi punto de vista, deberían dejar de existir los objetivos de TI, proyectos de TI, casi todo aquello que habla de TI. Y tomar conciencia; modificando su contenido tanto sintáctico como semántico, para convertirse única y exclusivamente en objetivos para el negocio (con diferentes niveles estratégicos, tácticos y operativos, pero mirando solo al negocio o hacia y para su resultado), proyectos para el negocio, etc. Dicha base estratégica, se asentaría en el lenguaje de cualquier organización, y se fundamentaría más concretamente - sin tirarnos de los pelos - visionando hacia dónde ir, si sentáramos al CIO en la misma mesa que el CEO. Y ambos hablaran, por fin el mismo idioma y tuvieran los únicos y mismos objetivos a cumplir y alcanzar.

Volvamos a la unidad de dicho modelo. ¿Qué es una métrica y para qué sirve? Es un indicador que nos debe permitir medir la calidad del servicio qué prestamos. Nos debe motivar al describir cómo de bien lo estamos haciendo, al realizar nuestras actividades cotidianas, basadas en obtener un resultado...no olvidemos...para el negocio. Nos debe hacer reflexionar qué acciones o medidas correctoras de mejora continua debemos llevar a cabo, para corregir las desviaciones en la calidad de los resultados y el comportamiento de nuestros procesos. Nos debe representar la madurez de los mismos y nos puede evidenciar cuál es nuestra situación con respecto al mercado (benchmarking).

Una buena práctica, que acelera la madurez de la organización, es definir y adoptar a la vez procesos con su correspondiente modelo de métricas. Siendo este proceso sencillo y rápido, adaptando en primera instancia la definición de procesos considerados como estándares y adaptándolos a las particularidades de cada empresa. La optimización de los procesos, de sus actividades, de su entendimiento y control - de su eficacia y eficiencia - es factor necesario y suficiente, sí desde el primer momento se hace a la par de métricas específicas, medibles, alcanzables, realistas y proporcionadas a tiempo, ese acrónimo reconocido como SMART.

La razón estriba en el concepto de control. Únicamente se puede controlar un proceso, una vez establecidas su medida. Hecho esto, podremos comparar tiempos de cada transición entre estados con otros procesos similares. Así como podremos identificar cuáles son las transiciones que consumen más tiempo y recursos con el objetivo de centrarse en estos puntos para evaluar y realizar posibles mejoras en los procesos.

Otra buena práctica es que cada proceso debería disponer o tener un métrica que nos midiese la satisfacción del cliente. No solamente, el de siempre, el de gestión de incidencias y peticiones de servicio. Piensen y tómenlo a consideración si les parece correcto.

Por último, si es que se ha invertido dinero en definir e implantar procesos, métricas y sus correspondientes herramientas de gestión de apoyo. Por Dios, ¿Hacen algo con los informes que detallan o describen cómo lo estamos haciendo?. ¿Analizan los resultados obtenidos con los esperados? ¿Toman alguna acción correctora o analizan y estudias posibles mejoras dentro del proceso?. Hablo en conjunto o del propietario del proceso, que para eso exclusivamente está. Ya que de forma común la definición del mismo, la suele realizar el consultor o la empresa de turno adjudicataria a tal efecto. Por tanto, respondamos. ¿Realmente gestionamos los procesos adoptamos en nuestra organización? ¿Si lo hacemos, Cómo y para qué?
Leer más...
Share/Bookmark

viernes, 23 de abril de 2010

Sistema de Métricas. Parte I.

Para continuar con el propósito, de obtener eficacia y eficiencia, en las Gestión de Servicios de IT en empresas que encuentran favorable para sus intereses de negocio, invertir en las buenas prácticas de ITIL, ya sea orientada en procesos (ITIL V2, con la idea de definir esa actividad de mejora continua, comentada en mi anterior entrada) u orientada a servicios (ITIL V3, con la fase de Mejora Continua del Servicio), considero fundamental, definir y establecer un modelo de métricas.

A través de dicho marco de trabajo, se pueda alcanzar el objetivo de alinear TI con la estrategia del negocio (ITIL V2) y medir por tanto aquello que tenga sentido y valor para el negocio. O profundizado más el concepto (ITIL V3) de integrar de forma sistemática y holística ambas partes. Negocio y TI.

Llegados aquí y antes de continuar el razonamiento, por si acaso y no dar nada por hecho, les detallo, una serie de conceptos, que se utilizarán:

COBIT: Control OBjetives for Information and related Technologies
ITIL: Information Technology Infraestructure Library
KGI: Key Goal Indicator. (Indicador clave de objetivo)
KPI: Key Performance Indicator (Indicador clave de rendimiento)

Así como si están interesados en profundizar sobre el tema, les recomiendo el título “Metric for IT Service Management”. Más información sobre este libro la puede obtener en la web del itsmf España, a través del siguiente: 

El alcance del Sistema de Métricas, debería imbricar todos los procesos ITIL adoptados, para obtener información de control y gestión sobre los mismos, aunando conocimiento para el cumplimiento de los objetivos de TI.

Para que el gobierno de TI, realice las acciones o toma de decisión oportunas, si la información recopilada y analizada, de sus objetivos cumple con lo pactado con el negocio y con sus objetivos.  O si realiza las correcciones o acciones de mejora, para solventar dicho gap entre ambos objetivos que deben ir alineados o integrados.


De ahí viene la relación fundamental que se establece entre CobIT e ITIL. Una vez establecida por la empresa sus objetivos de negocio y planes estratégicos, a través de CobIT, se alinean dicho objetivos de Negocio con los objetivos de TI, relacionando los objetivos de Control del primero con los procesos de ITIL. Por lo que, si se establecen los Outcomes a nivel de proceso relacionado con el negocio, a través de la realización de las diferentes actividades de cada proceso y se miden e identifican los indicadores validando los target definidos anteriormente, su cumplimiento, estará integrado. Por lo que la definición a nivel de empresa va de arriba abajo, y la medición, control y verificación de los definido en base a los objetivos de negocio, se validará, propagando dichas métricas de abajo hacia arriba.

Por último, en esta primera parte, es fundamental, definir y conocer el alcance de dichas métricas, en cuanto a eficacia, eficiencia y efectividad.


Las métricas de eficacia, miden si las actividades son realizadas de forma correcta, evidenciando que siempre que se espera o se dispara una entrada, ocurrirá siempre la misma salida.

Las métricas de eficiencia, miden si estas actividades eficaces, que se realizan de forma correcta, se ejecutan con el menor coste y esfuerzo mínimo (recursos).

Las métricas de efectividad, se concentrar en que la salida del procedimiento, alcance el resultado esperado por el negocio (outcomes).

Nota: Como el objetivo del blog es compartir ideas y experiencias, todas las imágenes, información y datos que estén reflejados, pueden utilizarse de forma libre como se desee.
Leer más...
Share/Bookmark

miércoles, 21 de abril de 2010

¿Realmente se “Controlan” o “Gestionan” los procesos una vez adoptados según las buenas prácticas de ITIL o se debería quitar la palabra “Gestión” de los mismos?

Un proceso podría describirse como un conjunto actividades relacionadas entre si, con el siguiente propósito. Su fin, obtener o alcanzar un objetivo definido. Definición e imagen, supongo que conocidas, se detallan en diferentes libros, foros, o se describen y relatan en cursos de formación. De igual forma, se detallan los elementos del proceso, entradas, salidas, actividades, roles, recursos, owner, objetivos, indicadores de calidad y rendimiento.


Tomemos como premisa, cualquier empresa, que haya invertido en las buenas prácticas de ITIL, para mejorar su eficacia y eficiencia en la gestión de servicio de TI. La misma ha definido y ha adoptado en su organización, diferentes procesos ITIL.

Utilizamos constantemente, la codificación de “proceso de gestión de …” pero sin que particularicemos en un proceso. ¿Estamos seguros que realmente dicho proceso se gestiona?. ¿Se controla el proceso?. Se mide y/o hay definida una actividad de mejora continua.

Habrán oído o leído la frase, “Todo lo que no se puede medir, no se puede gestionar”. Mi opinión al respecto, es que aunque se definan indicadores, se midan y se obtengan informes para sacar en claro la salud de dicho proceso, el dueño del mismo, debería definir en cada uno de ellos, una actividad de mejora continua.

Con ella y; junto con la de otros owner de otros procesos adoptados, aunarían información y conocimiento relevante de la situación actual, para la toma de decisiones junto con el Service Manager, en cuanto a eficacia, eficiencia y efectividad de la gestión de servicios y en definitiva, verificar si las actividades van alineadas con la necesidades del negocio, alcanzando los outcomes estratégicamente planeados. Sin que obvien, si tienen presente, el nivel de madurez evaluado de cada proceso, y que actividades o acciones, se tiene proyectadas, para incrementar dicha madurez, según el plan de acción pertinente.

Por lo tanto, siguiendo mi razonamiento, la idea sería, disponer de una actividad de mejora continua, paralela al resto de actividades principales y, que sería estándar y aplicable a cada uno de los procesos que se implantarán en dicha organización, referida anteriormente.

La figura siguiente, muestra el contenido dentro de dicha actividad de mejora continua, con 3 flujo dispuesto en forma paralela:

Sistema de Métricas del Proceso
• Sistema de Informes del Gestión

• Sistema de Auditorías

Y las salidas de las anteriores, seguiría un flujo en serie, con el sistema de mejora continua del proceso.

El Sistema de Métricas del Proceso, estaría compuesto de dos actividades, en las cuales, el owner del proceso, definiría los indicadores, los implantaría y marcaría las directrices necesarias para su recolección, según una periodicidad. Y por otro lado, validaría y custodiaría dichos valores obtenidos.

El Sistema de Informes de Gestión, estaría compuesto de dos actividades, en las cuales, el owner del proceso, se encargaría, de manera continua y fija, generar informes de gestión y su distribución, al resto de owner y gestor o manager de los servicios TI.

El Sistema de Auditorías, contendría una actividad consistente en auditar end-to-end todo el proceso, en base a unos requerimientos, control de calidad, para que desde fuera del mismo, se evaluara su eficacia y eficiencia.

Con la información contenida en los tres anteriores sistemas, vendría el flujo en serie, en el cual, con una periodicidad definida, se analizaría y evaluaría los resultados anteriormente citados, generando unas conclusiones y acciones a tomar, que vendría refrendadas en un documento, en el que se identificarían y definirían diferentes propuestas de mejora.

Dicho documento, sería distribuido al comité para su estudio, análisis y debate. Y en caso, de aprobarse alguna de las medidas dispuestas en dicho documento, se implantarían y se llevarían a cabo.

Y desde aquí vuelta a empezar. Por ello, tras varios recorridos por el proceso, la mejora continua, traería, la efectividad del proceso, en el que las salidas del mismo, debería estar más cercanas a los outcomes definidos en los objetivos, todo ello, relacionados con el negocio.

Propondría que opinión les merece y les animaría a establecer y compartir diferentes ideas, sobre el tema expuesto.
Leer más...
Share/Bookmark