Un cambio podríamos comentar sin formalismos que es la alteración o modificación del estado de un CI como propia entidad, o por sus posibles relaciones o por la información contenida de sus atributos.
Estos por su naturaleza - los CI´s -, no tienen resistencia al cambio. Pero en cambio las personas, somos de otra pasta y aquí, por nuestros condicionantes, si que la tenemos.
De igual forma, habría que tener como conceptos claros, que los clientes o sus usuarios, solamente tienes dos aspectos o necesidades. Ellos tienen o su necesidad es referente a tener peticiones de servicio e incidencias. De igual forma, los grupos de soporte, solamente mirando de manera de alto nivel, solamente se dedican a dos aspectos. A incidencias y a cambios. A Actividades que tengan que ver con esto. Cuando hablamos de problemas, ni los usuarios ni los grupos de soporte tienen problemas. Los problemas solamente los tenemos las personas.
Siguiendo con el concepto de cabecera, un cambio no está totalmente implementado, hasta que su documentación, tanto sí es dado de alta ese CI, como sí es modificado, está totalmente descrito donde corresponda y esté dicha información disponible hacia el personal que deba interaccionar con él. En mucha medida, nos acostumbramos, supongo que por tiempos, a jugar con el HW y el SW porque consideramos que esto es importante. Y claro que lo es; pero con el mismo criterio, la información de dichos activos, es necesaria, para quien deba disponer de ella.
Sí los conceptos no los tenemos desarrollados y los tenemos claro, la información no será veraz a lo largo del tiempo y, cuando la vayamos a consultar no tendremos claro, sí la misma es la real, está actualizada o está devaluada porque cuando se debería haber actualizada no se hizo por el personal responsable de la misma. A veces, por no entender la imbricación de los procesos, el síntoma es echar culpas a quién debería gestionar la información, que es los responsables de la CMDB, es decir, el personal que gestiona el SACM. Pero esto no es del todo cierto. Realmente el responsable de todo ello, es de quién gestionó o gestiona el cambio, el cuál, una de las tareas del mismo, antes de terminar con el alcance que solicitó y fue aprobado, sería el de comunicar a configuración o a quien deba, dicha actualización.
Nos pasamos generando y generando nueva información, actualizando la misma y no nos damos cuenta, que el valor de salvaguardar la información es poder reutilizarla cuando tengamos que hacerla, que la tengamos disponible y accesible para quién deba disponer de ella. Y cualquier información que no sea factible y fácil el explotarla no generará el valor esperado para el servicio que estamos prestando o llevando a cabo.
Mucho de esto, nos produce o nos acontece, porque nos quedamos mucho a alto nivel y no llegamos a evaluar lo realmente importante y en muchos casos lo que deberíamos hacer alineado a lo que ha definido el cliente como valor.
Estos por su naturaleza - los CI´s -, no tienen resistencia al cambio. Pero en cambio las personas, somos de otra pasta y aquí, por nuestros condicionantes, si que la tenemos.
De igual forma, habría que tener como conceptos claros, que los clientes o sus usuarios, solamente tienes dos aspectos o necesidades. Ellos tienen o su necesidad es referente a tener peticiones de servicio e incidencias. De igual forma, los grupos de soporte, solamente mirando de manera de alto nivel, solamente se dedican a dos aspectos. A incidencias y a cambios. A Actividades que tengan que ver con esto. Cuando hablamos de problemas, ni los usuarios ni los grupos de soporte tienen problemas. Los problemas solamente los tenemos las personas.
Siguiendo con el concepto de cabecera, un cambio no está totalmente implementado, hasta que su documentación, tanto sí es dado de alta ese CI, como sí es modificado, está totalmente descrito donde corresponda y esté dicha información disponible hacia el personal que deba interaccionar con él. En mucha medida, nos acostumbramos, supongo que por tiempos, a jugar con el HW y el SW porque consideramos que esto es importante. Y claro que lo es; pero con el mismo criterio, la información de dichos activos, es necesaria, para quien deba disponer de ella.
Sí los conceptos no los tenemos desarrollados y los tenemos claro, la información no será veraz a lo largo del tiempo y, cuando la vayamos a consultar no tendremos claro, sí la misma es la real, está actualizada o está devaluada porque cuando se debería haber actualizada no se hizo por el personal responsable de la misma. A veces, por no entender la imbricación de los procesos, el síntoma es echar culpas a quién debería gestionar la información, que es los responsables de la CMDB, es decir, el personal que gestiona el SACM. Pero esto no es del todo cierto. Realmente el responsable de todo ello, es de quién gestionó o gestiona el cambio, el cuál, una de las tareas del mismo, antes de terminar con el alcance que solicitó y fue aprobado, sería el de comunicar a configuración o a quien deba, dicha actualización.
Nos pasamos generando y generando nueva información, actualizando la misma y no nos damos cuenta, que el valor de salvaguardar la información es poder reutilizarla cuando tengamos que hacerla, que la tengamos disponible y accesible para quién deba disponer de ella. Y cualquier información que no sea factible y fácil el explotarla no generará el valor esperado para el servicio que estamos prestando o llevando a cabo.
Mucho de esto, nos produce o nos acontece, porque nos quedamos mucho a alto nivel y no llegamos a evaluar lo realmente importante y en muchos casos lo que deberíamos hacer alineado a lo que ha definido el cliente como valor.
No hay comentarios:
Publicar un comentario