¿Cómo se puede utilizar la gestión de cambios para las operaciones SIG?

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 .

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:

1. "¿Esperan otros [ sistema / base de datos ] en los que estoy trabajando que estén disponibles de manera consistente?"
2. "¿Alguien me llamará y me preguntará qué tiene de malo [ sistema / base de datos ] debido al trabajo que estoy planeando?"
3. "¿Sería beneficioso trabajar en [ sistema / base de datos ] en un momento planificado cuando todos sepan que no estará disponible?"

Si la respuesta es "Sí", probablemente debería ser parte de Change Management.

Entonces, usando sus ejemplos:

• Iniciar, reiniciar Mapservices = gestión de cambios
• Crear / actualizar servicios = gestión de cambios
• Mover datos (suponiendo que sea a un nuevo servidor / base de datos) = gestión de cambios
• Cambiar el esquema de datos (nombre de tabla / vista, columnas, etc.) = gestión de cambios
• Actualizar datos = no cambiar la administración porque es poco probable que a alguien le importe si se presenta FeatureID 123 o atributo X. Solo necesitan poder analizar cualquier dato que exista en la clase de entidad.

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á.

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.

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:

Cambios estratégicos, cambios operativos (incluidos los cambios estructurales), cambios tecnológicos, cambio de actitudes y comportamientos del personal, cambios amplios de personalidad

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.