El cambio está listo, los ingenieros tienen una ventana de mantenimiento y solo falta la aprobación para el tiempo de inactividad. Pero ¿quién debería firmar? El propietario original del servicio se trasladó a otro departamento, su sucesor no sabe que ha heredado el rol y el líder del equipo dice que no es su decisión. La solicitud viaja de bandeja a bandeja y la ventana expira.
Lo mismo sucede con las incidencias, solicitudes y auditorías. Un auditor pregunta quién aprobó una intervención en particular y la respuesta se busca en hilos de correo electrónico antiguos. Para el personal de operaciones, esto significa esperas innecesarias y la sensación de cargar con una responsabilidad que nadie delegó formalmente. Para los propietarios de servicios, significa el riesgo de enterarse de trabajos en su servicio después de los hechos.
Por qué se difumina la responsabilidad
La mayoría de las organizaciones tienen un documento que describe quién es responsable de qué. El problema es que vive separado de la herramienta donde se realiza el trabajo.
- Una matriz RACI en una hoja de cálculo no se refleja en los permisos. La persona marcada como "responsable" a menudo no puede aprobar nada en el sistema, y viceversa.
- La propiedad es ambigua. A veces el propietario se registra en el servicio, a veces en la aplicación, a veces en el equipo, y cada proceso elige uno diferente.
- No hay un aprobador alternativo. Cuando un propietario está ausente o no asignado, el proceso se detiene.
- Los permisos son demasiado amplios. Las personas ven todo o nada, por lo que los roles se otorgan de manera más amplia "por si acaso".
Una mejor forma de pensar sobre la propiedad
La responsabilidad solo es útil cuando el sistema lo sabe y lo hace cumplir. Sugerimos algunos principios:
- Una regla de propiedad para cada proceso. Aprobar un tiempo de inactividad, una solicitud o una lista de precios debe seguir la misma lógica.
- Siempre hay un tomador de decisiones alternativo. Si no se asigna un propietario, está claro de antemano quién decide.
- Los roles tienen alcance. Un permiso se aplica a un cliente específico, equipo o elemento, no a todo el sistema.
- RACI y permisos deben coincidir. Quien sea responsable de algo necesita los derechos para actuar en consecuencia, y nadie más debería tenerlos.
- Cada decisión es rastreable. Quién, cuándo y por qué.
Cómo lo maneja Eywo Stratum
En Eywo Stratum, cada servicio tiene un propietario y una regla determina quién es el propietario. La misma regla se aplica a todos los procesos que necesitan consentimiento: tiempos de inactividad en cambios, solicitudes, acuerdos de parche y propuestas de lista de precios. Todos estos llegan a una sola cola de "En espera de aprobación". Si un servicio no tiene propietario, el gestor de cambios decide como aprobador alternativo, por lo que nada se queda atascado. Un rechazo siempre viene con una razón.
Los permisos se basan en 14 roles con alcance: todo, un cliente, un equipo o un elemento específico. Las personas obtienen exactamente los derechos que su rol requiere. Stratum también incluye una matriz RACI con una comprobación de coherencia contra permisos. Señala a cualquier persona que figure como responsable en la matriz que carece del rol coincidente en el sistema, y viceversa.
Cada decisión se escribe en un registro de auditoría que se conserva durante cinco años. Cuando un auditor pregunta quién aprobó algo, la respuesta tarda momentos, no días. Durante la implantación, la verificación de preparación operativa verifica, entre otras cosas, que los servicios tienen propietarios asignados y que los roles están en su lugar.
Conclusión
La propiedad clara no es burocracia. Protege a las personas. Los ingenieros saben a quién preguntar. Los propietarios de servicios saben que nada sucede con su servicio sin su conocimiento. Y la organización puede mostrar en cualquier momento quién fue responsable de qué. Solo se requiere que la responsabilidad viva dentro del sistema en lugar de en una hoja de cálculo junto a él.
La propiedad del servicio, los roles con alcance, la comprobación de coherencia de RACI y el registro de auditoría son parte de la edición Estándar.
Eywo Stratum Standard
Para organizaciones que desean una CMDB fiable y procesos de ITSM gestionados.