Comment la gestion du changement peut-elle être utilisée pour les opérations SIG?

Je travaille dans une grande organisation modérée où les SIG ne font partie que de la plate-forme informatique. Le reste de l'organisation travaille avec la «gestion du changement» et maintenant, ils veulent que nous, les ingénieurs SIG, soyons meilleurs avec les demandes de changement, etc.

Le problème est qu'en tant qu'administrateur SIG, nous faisons tout le temps de nombreux changements. Démarrez, redémarrez les services de carte, créez de nouveaux services, déplacez les données, mettez à jour les services et les données.

Ma question est de savoir si quelqu'un d'autre a de l'expérience avec la gestion du changement et les SIG dans leur travail quotidien et comment cela a fonctionné pour vous :)

Dans l'attente d'une discussion intéressante.

Il s'agit d'un lien qui explique le concept de gestion du changement .

Je travaille également au sein d'une organisation qui utilise le processus de gestion du changement. Pour nous, la gestion du changement ne s'applique pas aux opérations quotidiennes de gestion des données ... ce serait écrasant. Elle s'applique généralement aux modifications d'un [ système / base de données ] qui peuvent avoir des impacts en aval sur d'autres systèmes.

À un niveau élevé, posez-vous ces questions:

1. "Les autres s'attendent-ils à ce que [ système / base de données ] sur lequel je travaille soit toujours disponible?"
2. "Est-ce que quelqu'un appellera et me demandera ce qui ne va pas avec [ système / base de données ] à cause du travail que je prévois?"
3. "Serait-il avantageux de travailler sur [ système / base de données ] à un moment prévu où tout le monde sait qu'il ne sera pas disponible?"

Si la réponse est "Oui", cela devrait probablement faire partie de la gestion du changement.

Donc, en utilisant vos exemples:

• Démarrer, redémarrer mapservices = gestion du changement
• Créer / mettre à jour des services = gestion du changement
• Déplacer les données (en supposant que ce soit vers un nouveau serveur / base de données) = gestion du changement
• Changer le schéma de données (nom de table / vue, colonnes, etc.) = gestion du changement
• Mettre à jour les données = ne pas modifier la gestion car il est peu probable que quiconque se soucie si FeatureID 123 ou l'attribut X est rempli. Ils doivent simplement être en mesure d'analyser les données existantes dans la classe d'entités.

Une autre façon de voir les choses comme un service de livraison: Si vous déménagez à une nouvelle adresse, changez de nom, faites changer d'adresse par la municipalité, vous devez en informer la Poste. Si vous obtenez un nouvel abonnement à un magazine, le bon de commande n'a pas besoin de le savoir car la livraison apparaîtra simplement.

L'article sur le contrôle du changement est probablement plus proche de ce à quoi vous pensez.

Dans mon organisation, nous avons une réunion hebdomadaire sur les «opérations» au cours de laquelle nous passons en revue une liste des changements à venir et demandons au personnel clé impliqué des mises à jour de statut et donnons la possibilité de coordonner toutes les opérations conflictuelles.

Ces procédures sont généralement couvertes par une procédure d'exploitation standard (SOP), un accord de niveau de service (SLA) et / ou un accord de niveau opérationnel (OLA), avec des tâches / workflows individuels documentés dans une base de connaissances (KB). La priorisation stratégique des grands projets est gérée par la gouvernance informatique .

Tout magasin informatique de taille moyenne à grande devrait déjà avoir au moins certaines de ces normes mises en œuvre.

Il me semble que la gestion du changement consiste davantage à changer la structure de l'organisation ou des exigences en projet, pas la maintenance technologique au quotidien (le redémarrage des services par exemple). À partir de la section "Exemples" de l'article Wikipedia auquel vous avez lié:

Changements stratégiques, changements opérationnels (y compris les changements structurels), changements technologiques, changement des attitudes et des comportements du personnel, changements de personnalité

Lors d'un ancien emploi dans une entreprise de taille moyenne, nous avons dû mettre en place des «contrôles de changement» chaque fois que nous devions apporter des modifications qui affectaient une production importante.Système ou composant informatique, tels que, mais sans s'y limiter, les modifications / migrations / connexions de base de données, les travaux ETL, les configurations de serveur, etc. Les environnements de développement et de test ne nécessitaient pas de contrôle des modifications. Heureusement, nous avions (gagné) la confiance de notre service informatique, ils nous ont donc donné des libertés telles que le contrôle total de notre environnement de production afin que nous puissions facilement déployer nos applications et apporter les modifications nécessaires. Le personnel informatique ne connaissait pas le fonctionnement interne des applications SIG pour gérer toutes les tâches de gestion quotidiennes, ils nous l'ont donc laissé. Le rebond des services de carte ne nécessitait pas de contrôle des modifications pour nous, mais il figurait dans nos SOP et documents, qui étaient accessibles en interne à tous.

Mon point: gagnez la confiance de votre service informatique, de vos administrateurs de base de données et administrateurs système, montrez-leur comment vos procédures affectent les systèmes et faites de votre mieux pour travailler avec eux autant que possible. Essayez de trouver un SOP et de documenter ce qui nécessite un contrôle des modifications et ce qui ne le fait pas, et respectez-le.