XavMP

En CSI hice unos primeros dubitativos pasos por unos problemas de agenda, pero voy avanzando igual. Me llamó la atención especialmente el punto 8.5.1 de las Baselines, donde la norma nos recomienda tener indicadores a pesar de que los mismos no sean confiables. Copio el párrafo porque está en la raíz de muchas discusiones tecnológicas que tuve con la MAYORÍA de mis colaboradores a cargo. If a baseline is not initially established the first measurement efforts will become the baseline. That is why it is essential to collect data at the outset, even if the integrity of the data is in question. It is better to have data to question than to have no data at all.  ¿Vieron? ¡Yo sabía! No hablemos de medición sin haber medido, démosle forma de indicador a la realidad. Avanzar sobre lo poco que sabemos y construir sobre eso un proceso de mejora. Mejora de medición, mejora de resultados, mejora de calidad, mejora de percepción del cliente. También vean el 8.5.2 que nos llama a revis...

¿Pensaron que el suplicio de ITIL - Entrando en Service Operation y lo que te g... había terminado? Tsk Tsk, sigo leyendo y voy a terminar este libro. Es muy interesante Ahora me interné en el CSI y la mejora continua, también repasé el capítulo de Service Desk que tiene sabor a poco. Yo de Service Desk escribiría un libro de 400 páginas acerca de la importancia, el alcance, la responsabilidad, los roles, lecciones aprendidas, eficiencia. ¡Hay para hacer dulce!, además me acompaña una experiencia muy buena que tuve en mi empresa actual, donde lamentablemente veo languidecer el trabajo que dejé hace dos años (La Gerencia actual no cree en la atención del usuario). Después están las unidades funcionales de infraestructura y operaciones, dos sobre las cuales tengo mucho para decir y que en general suelen ser un desafío para alocar recursos. Son zona de conflicto, donde mantener motivado un especialista es una obra de arte de día a día. En general las tareas de Operation Management van a...

Metidos de lleno en lo de Change Management con la diferencia de conceptos entre Event, incident, Problem y Service Request. Ojo. Todos entendemos que son categorías reales y necesarias, que en algunos casos como en los sistemas viejos donde la incidencia de los problemas puede ser muy alta, se requiere aislarlos y proporcionarles una atención especial. También imagino que en compañías de más de 5000 empleados se transforma en necesidad. Pero en general, con un buen sistema de gestión de incidentes y un Service Desk de carne y hueso, se puede dar vida a un proceso eficaz y satisfactorio para el usuario. Lo que si es claro es que estas estructuras tradicionales de Service Desk no suelen alcanzar al Problem (que suele estar bajo el ala de Desarrollo) y no suelen catalogar los eventos e incidentes en la esfera de un control de gestión de un servicio. Imagino que volcar las relaciones Servicio/Incidente con una categorización común, debe ser una recompensa instantánea y un empujón ...

Muy buena la lectura de The Official Introduction to de ITIL Service Lifecycle, el Change management aparece relacionado con todos los problemas entendidos de modo general en el Service Design. Me intriga mucho entender cómo funcionaría mi empresa bajo el dominio de ITIL y frente a la ausencia de mejora tecnológica en años. El desafío es entender un gap de proyectos de mejora tecnológica que requiere un portfolio de proyectos ad-hoc. Ayuda mucho el tema de las 7 erres: Who RAISED the change? What is the REASON for the change? What is the RETURN required from the change? What are the RISKS involved in the change? What resources are REQUIRED to deliver the change? Who is RESPONSIBLE for the build, test and implementation of the change? What is the RELATIONSHIP between this change and other changes? Y le agregaría una R adicional relacionada con el tiempo que el servicio viene trabajando sin cambios: How much the service has been ROLLING without changes? Ahora estoy ...

Avanzo tozudamente en ITIL. A medida que el proceso de conocer la norma avanza nos encontramos con múltiples herramientas de disponibilidad, catálogo, capacidad, análisis de fallos, etc. Son todas funciones que entiendo que se pueden implementar por separado, pero que ITIL entiende como si fuera el anillo de Sauron, las suma a todas y acompaña la lucha de todo gerente de IT: la pelea entre una gestión ordenada y el desafío de perder agilidad en el camino. Viendo esto muchos pensarán que ITIL es penoso. Nada de eso, ITIL es poner en blanco y negro lo que cualquier área de TI orientada a mejora continua haría para garantizar la satisfacción de aquellos que le pagan el sueldo (y un suculento bono anual). Lo que no entiendo bien de ITIL es ese foco en montar una entrada especial para Information Security Management cuando debería ser parte incluida de molde en el Service Design, analizando para cada servicio los riesgos y planes de mitigación. No sé si esté asunto no es parte ...

Me sumergí profundamente en los mares de ITIL , porque soy así de valiente y porque tengo energía para entenderlo. En principio la primera reflexión que surge es que se trata de otro sistema de mapeo de procesos de sistemas, que requiere ingente documentación y que se transforma en tarea titánica para cualquier gestión de TI. El problema es que eso lo puede decir alguien que piensa eso de todos los modelos de calidad, sin embargo para mí son un bálsamo y tuve muchos proyectos aplicándolos. Pude en el pasado trabajarlos sin problema y con relativo éxito. Recuerdo aquella matriz de riesgo que hice para la eficiencia del control de pérdida de información (hasta hice una presentación del modelo a un grupo de colegas), las otras matrices de riesgo que hice luego de esa, todo el proceso de certificación ISO 9000 y también lo mucho que me ayudó COBIT a entender el control de TI. Procesos lentos, que requieren centrarse en una evaluación de especialista y que te cuentan al final lo que sab...