Como o gerenciamento de alterações pode ser usado para operações GIS?

Estou trabalhando em uma grande organização moderada, na qual o GIS faz parte da plataforma de TI. O resto da organização está trabalhando com "Gerenciamento de mudanças" e agora eles querem que os engenheiros de GIS sejam melhores com solicitações de mudança e assim por diante.

O problema é que, como administrador de GIS, fazemos muitas mudanças o tempo todo. Inicie, reinicie os serviços de mapas, crie novos serviços, mova dados, atualize serviços e dados.

Minha pergunta é se alguém tem experiência com Gerenciamento de Mudanças e SIG no trabalho diário e como isso funcionou para você :)

Ansioso por uma discussão interessante.

Este é um link que explica o conceito de Gerenciamento de mudanças .

Também trabalho em uma organização que utiliza o processo de Gerenciamento de Mudanças. Para nós, o gerenciamento de mudanças não se aplica às operações diárias de gerenciamento de dados ... isso seria esmagador. Geralmente se aplica a alterações em um [ sistema / banco de dados ] que podem ter impactos posteriores em outros sistemas.

Em um nível alto, faça a si mesmo estas perguntas:

1. "Outros esperam que [ sistema / banco de dados ] em que estou trabalhando esteja disponível de forma consistente?"
2. "Alguém ligará e perguntará o que há de errado com [ sistema / banco de dados ] por causa do trabalho que estou planejando?"
3. "Seria benéfico trabalhar no [ sistema / banco de dados ] em um horário planejado em que todos saibam que não estará disponível?"

Se a resposta for "Sim", provavelmente deve fazer parte do Gerenciamento de Mudanças.

Então, usando seus exemplos:

• Iniciar, reiniciar mapservices = gerenciamento de alterações
• Criar / atualizar serviços = gerenciamento de alterações
• Mover dados (supondo que seja para um novo servidor / banco de dados) = gerenciamento de alterações
• Esquema de dados de alteração (nome da tabela / exibição, colunas, etc.) = gerenciamento de alterações
• Atualizar dados = não alterar o gerenciamento porque é improvável que alguém se importe se o FeatureID 123 ou o atributo X for preenchido. Eles só precisam ser capazes de analisar quaisquer dados existentes na classe de recurso.

Outra maneira de pensar nisso como um serviço de entrega: se você mudar para um novo endereço, mudar seu nome, mudar de endereço pelo município, deverá notificar os Correios. Se você receber uma nova assinatura de uma revista, o pedido não precisará saber porque a entrega será exibida.

O artigo para Controle de alterações provavelmente está mais próximo do que você está pensando.

Na minha organização, temos uma reunião semanal de "operações", durante a qual revisamos uma lista de mudanças futuras e solicitamos ao pessoal-chave envolvido atualizações de status e fornecemos uma oportunidade para coordenar qualquer operação conflitante.

Esses procedimentos geralmente são cobertos por um procedimento operacional padrão (SOP), contrato de nível de serviço (SLA) e / ou contrato de nível operacional (OLA), com tarefas / fluxos de trabalho individuais documentados em uma base de conhecimento (KB). A priorização estratégica de grandes projetos é tratada através da governança de TI .

Qualquer loja de TI de médio a grande porte deve ter pelo menos alguns desses padrões já implementados.

Parece-me que o Gerenciamento de Mudanças tem mais a ver com mudar a estrutura da organização ou os requisitos para um projeto, não a manutenção diária da tecnologia (a reinicialização dos serviços, por exemplo). Na seção "Exemplos" do artigo da Wikipedia você vinculou a:

Mudanças estratégicas, Mudanças operacionais (incluindo mudanças estruturais), Mudanças tecnológicas, Mudança de atitudes e comportamentos do pessoal, Mudanças na personalidade

Em um trabalho anterior em uma empresa de médio porte, tivemos que colocar "controles de mudança" sempre que precisávamos fazer alterações que afetassem qualquer produção importanteSistema ou componente de TI, como, sem limitação, alterações / migrações / conexões de banco de dados, trabalhos ETL, configurações de servidor, etc. Os ambientes de desenvolvimento e teste não exigiam controles de alteração. Felizmente, tínhamos (conquistado) a confiança de nosso departamento de TI, de modo que eles nos deram liberdades, como controle total sobre nosso ambiente de produção, para que pudéssemos implantar facilmente nossos aplicativos e fazer alterações conforme necessário. A TI não possuía a equipe com conhecimento do funcionamento interno dos aplicativos GIS para lidar com todas as tarefas diárias de gerenciamento; portanto, eles deixaram isso para nós. Os serviços de mapas de rejeição não exigiam um controle de alterações para nós, mas estavam em nossos POP e documentos, que estavam disponíveis internamente para todos.

Meu ponto de vista: ganhe a confiança de seu departamento de TI, de seus DBAs e administradores de sistemas, mostre a eles como seus procedimentos afetam os sistemas e tente o seu melhor para trabalhar com eles o máximo possível. Tente criar um POP e documente o que requer um controle de alterações e o que não exige, e cumpra-o.