establecer ITIL como un marco común para múltiples equipos de TI en todo el mundo

Mi gerente y yo recibimos la tarea de administrar/incentivar varios equipos de TI en diferentes regiones geográficas (con múltiples zonas horarias y diferentes conocimientos culturales).

Los equipos aún no tienen experiencia y carecen de disciplina básica sobre cómo probar, revisar y desplegar.

Estaba pensando en establecer una metodología como ITIL o Information Technology Infrastructure Librarysentar las bases para un entendimiento mutuo, por ejemplo, no se implementa sin una prueba o sin una comunicación básica con los usuarios.

  • ¿Sería ITIL un marco decente para eso?
  • Si ITIL no era la 'cosa', ¿hay otra metodología para eso?
  • ¿Alguien tiene alguna experiencia con esto y estaría dispuesto a compartirla, por favor?

Gracias

Esta pregunta es sobre el gobierno de TI, en lugar del campo o la práctica de la gestión de proyectos como se define en nuestro centro de ayuda.
Hola, @CodeGnome, sería honesto, eché un vistazo a varios sitios y ninguno se acercó más que pm SE para hacer mi pregunta. Desearía poder preguntar en otro lugar, pero este es el mejor lugar hasta ahora. Lo siento por eso.
Hola, aunque potencialmente hay una buena pregunta aquí, tal como está es más "tengo una herramienta, ¿cómo puedo hacer que se adapte a mis necesidades" en lugar de "tengo un problema, ¿cuál es la mejor herramienta para solucionarlo?"
hola @TiagoCardoso, traté de encontrar una solución en lugar de un problema. Puedo hacer otra pregunta donde lo enmarcaré de manera diferente... ¿Cuál es su consumo...?
Es mejor reescribir este compañero, centrándose en su problema real. Una vez que lo haga, la comunidad puede seguir editándolo para convertirlo en una pregunta más sólida y valiosa. Salud

Respuestas (1)

No estoy tan familiarizado con los detalles de ITIL. Cuando lo encontré, lo que generalmente encontré es que el proceso estaba estancando la organización.

Lo que aconsejaría es darle la vuelta a las cosas, en lugar de colocar en un gran proceso (con toda la documentación, capacitación, aceleración, etc.), comience donde está y desarrolle algo a partir de ahí. Esto cae bajo los conceptos sueltos de Kaizen, comienza donde estás, que proviene de Toyota Way.

Aquí está el esquema que recomendaría:

  1. No hagas absolutamente nada. Eres nuevo, no sabes cómo funcionan todos estos equipos hoy en día. Pase los primeros 90 días aprendiendo.
  2. Haz un Gemba Walk (busca el término en Google). Es otra cosa de los conceptos Toyota Way. Ve a cada lugar y observa. Mira cómo van las cosas. Vea sus desafíos. Escuche lo que tienen que decir.
  3. Realice un mapeo de vapor de valor: identifique las tres cosas más comunes que hacen o harán sus equipos. Traza el cronograma para pasar de la idea a la realización. Está buscando particularmente tiempos de espera, cuando está esperando a otra persona y en puntos de "retroceso" en los que el proyecto puede retroceder a una fase anterior (QA, por ejemplo).
  4. Decide tus objetivos. Ahora debe decidir cómo quiere que sea su organización. Crea objetivos basados ​​en estos. Estos objetivos deben ser "Por qué" o "Qué", no "Cómo". Suficiente orientación para que los equipos puedan encontrar la mejor manera de alcanzar esos objetivos. Recuerde, las metas deben ser medibles, o tendrá confusión. "Es rápido" no es un objetivo, "reducir el tiempo de entrega en un 50%" es un objetivo.
  5. Comienzo. Solo empieza. No cree procesos, no entre en detalles. Solo empieza.
  6. Inspeccionar y Adaptar. Ahora empiezas a mirar semanalmente o incluso a diario cómo van las cosas. Modifique las cosas para que funcionen, documente lo que funciona y siga adelante.

También debe estar preparado para que diferentes equipos terminen con diferentes procesos de "Cómo". Si están cumpliendo con el objetivo "Qué" y han documentado el proceso de trabajo, está bien.