Zona BusIT

los 3 aspectos fundamentales para actualizar ITIL. Quizá alguno piense que soy algo presuntuoso en considerar que ITIL se puede actualizar en 3 pasos y pido disculpas por ello; sin embargo creo que a través de la polémica -en este caso en especial- se puede generar el intercambio de ideas que sean útiles para llegar a conclusiones valederas. 1- ¿Cuáles procesos deben ser eliminados? Así es. ELIMINADOS. Las herramientas están automatizando muchas actividades, sobre todo de control , lo que hace que algunos procesos puedan "transformarse" en un equipo que mida para mejorar. Si uno de los objetivos declarados es aplicar técnicas Agile, pues esperemos que la gente encargada de la actualización (me gustaría que dijeran renovación ) tenga la valentía de eliminar algunos procesos. ¿Qué tal si, al menos, algunos fueran "subprocesos"? Por ejemplo: la G. de Eventos podría ser un subproceso de G. de Incidencias? ¿G. de la Continuidad dentro de G. de la Disponibilidad?¿Se...

.. bueno eso es lo que piensan algunos. Luego de leer/escuchar a varios "expertos" (gurues??) en -una vez más, lo siento- transformación digital donde declaro NO ser un experto en este tema.; no creo que con mi afirmación haya defraudado a nadie pero el que me conoce sabe que soy un infiltrado en la gestión de tecnología y que sólo se algo de gestión de personas que entregan servicios IT. Y la primer tirada de mis dados, que me obsequiara hace muchos años mi amigo Frank Pérez, para "ayudarme" en momentos de indecisión, arrojó el siguiente resultado: Bueno, los dados no están trucados, al menos eso creo. Así que observando el cruel resultado de esta primer tirada, me dije que debería intentarlo de nuevo, ya que estaba buscando alguna ayuda para enfocar soluciones digitales. Ahh claro Uds estarán pensando, obviamente, que no estoy demasiado cuerdo pensando en que los dados me darán una solución a la transformación que pretendo... Y ¿qué creen Uds que est...

Participando de un seminario sobre DevOps organizado por Tecnofor esta mañana se destacaba sobre todo la necesidad de la implantación de una "cultura Devops" y eso asociado a que los equipos Devops no tienen jefes o controladores, sino alguien que determine la dirección y el enfoque en el negocio.  Nada desconocido de lo que venimos escuchando hace ya muchos -demasiados- años a expertos internacionales del management y en los últimos tiempos a analistas de gestión de servicios IT. Al final es más de insistir en que se derriben las barreras existentes entre los equipos de desarrollos y de operaciones.  Dice W. E. Deming (1900 - 1993) creador del famoso ciclo PDCA, en uno de sus principios de calidad, creo que el 9:  " Derribe las barreras entre las áreas del personal.  Todos deben trabajar como un equipo, en pos de una meta común. El trabajo en equipo es un imperativo en la administración moderna. Pueden ser necesarias nuevas estructuras organizativas. Transfor...