Estoy trabajando en una gran organización moderada donde GIS es solo parte de la plataforma de TI. El resto de la organización está trabajando con "Change Management" y ahora quieren que los ingenieros de GIS sean mejores con las solicitudes de cambio, etc.
El problema es que, como administrador de SIG, hacemos muchos cambios todo el tiempo. Inicie, reinicie mapaservicios, cree nuevos servicios, mueva datos, actualice servicios y datos.
Mi pregunta es si alguien más tiene experiencia con Change Management y GIS en su trabajo diario y cómo funcionó para usted :)
Esperamos una discusión interesante.
Este es un enlace que explica el concepto de Gestión del Cambio .
workflow
organizations
Andersson
fuente
fuente
Respuestas:
También trabajo dentro de una organización que utiliza el proceso de Gestión del Cambio. Para nosotros, la gestión de cambios no se aplica a las operaciones diarias de gestión de datos ... eso sería abrumador. Generalmente se aplica a cambios en un [ sistema / base de datos ] que pueden tener un impacto aguas abajo en otros sistemas.
En un nivel superior, hágase estas preguntas:
Si la respuesta es "Sí", probablemente debería ser parte de Change Management.
Entonces, usando sus ejemplos:
Otra forma de verlo como un servicio de entrega: si se muda a una nueva dirección, cambia su nombre, si la municipalidad cambia su dirección, debe notificar a la oficina de correos. Si obtiene una nueva suscripción a una revista, el PO no necesita saberlo porque la entrega simplemente aparecerá.
fuente
El artículo para Control de cambios probablemente esté más cerca de lo que está pensando.
En mi organización tenemos una reunión semanal de "operaciones" durante la cual repasamos una lista de los próximos cambios y pedimos al personal clave involucrado actualizaciones de estado y brindamos la oportunidad de coordinar cualquier operación conflictiva.
Estos procedimientos generalmente están cubiertos por un procedimiento operativo estándar (SOP), un acuerdo de nivel de servicio (SLA) y / o un acuerdo de nivel operativo (OLA), con tareas / flujos de trabajo individuales documentados en una base de conocimiento (KB). La priorización estratégica de grandes proyectos se maneja a través del gobierno de TI .
Cualquier tienda de TI mediana o grande ya debería tener implementadas al menos algunas de estas normas.
fuente
Me parece que Change Management se trata más de cambiar la estructura de la organización o los requisitos de un proyecto, no el mantenimiento diario de la tecnología (el reinicio de los servicios, por ejemplo). Desde la sección "Ejemplos" del artículo de Wikipedia que vinculó a:
fuente
En un antiguo trabajo en una empresa mediana, teníamos que poner "controles de cambio" cada vez que necesitábamos hacer cambios que afectaran cualquier producción importante.Sistema o componente de TI, como, entre otros, cambios / migraciones / conexiones de la base de datos, trabajos ETL, configuraciones de servidor, etc. Los entornos de desarrollo y prueba no requieren controles de cambio. Afortunadamente, habíamos (ganado) la confianza de nuestro departamento de TI, por lo que nos dieron libertades como el control total sobre nuestro entorno de producción para que pudiéramos implementar fácilmente nuestras aplicaciones y realizar los cambios necesarios. TI no tenía el personal con conocimiento del funcionamiento interno de las aplicaciones SIG para manejar todas las tareas de administración diarias, por lo que nos lo dejaron a nosotros. Los servicios de mapas de rebote no requerían un control de cambio para nosotros, pero estaba en nuestro SOP y documentos, que estaban disponibles internamente para todos.
Mi punto: gane la confianza de su departamento de TI, sus administradores de bases de datos y administradores de sistemas, muéstreles cómo afectan sus procedimientos a los sistemas y haga todo lo posible para trabajar con ellos tanto como sea posible. Trate de llegar a un SOP y documente lo que requiere un control de cambio y lo que no, y cúmplalo.
fuente