GIS管理に変更管理をどのように使用できますか？

私は、GISがITプラットフォームの一部である、適度な大規模組織で働いています。組織の他のメンバーは「変更管理」を使用して作業しており、GISエンジニアに変更要求などの改善を求めています。

問題は、GIS管理者として、常に多くの変更を行っていることです。mapservicesの起動、再起動、新しいサービスの作成、データの移動、サービスとデータの更新。

私の質問は、他の誰かが日常業務で変更管理とGISの経験を持っているかどうか、そしてそれがどのようにうまく機能したかです:)

興味深い議論を楽しみにしています。

これは、変更管理の概念を説明するリンクです。

また、変更管理プロセスを利用する組織内で働いています。私たちにとって、変更管理は日常のデータ管理操作には適用されません...それは圧倒的です。これは通常、他のシステムにダウンストリームの影響を与える可能性のある[ システム/データベース ] への変更に適用されます。

高レベルでは、次の質問を自問してください。

1. 「他の人は、私が取り組んでいる[ システム/データベース ]が一貫して利用可能であることを期待していますか？」
2. 「私が計画している作業のために、誰かが[ システム/データベース ]の何が問題であるかを問い合わせてきますか？」
3. 「[ システム/データベース ]で作業を行うことは、誰もがそれが利用できないことを知っている計画された時間に行うことは有益でしょうか？」

答えが「はい」の場合、それはおそらく変更管理の一部であるべきです。

だからあなたの例を使って：

• mapservicesの開始、再起動=変更管理
• サービスの作成/更新=変更管理
• データを移動する（新しいサーバー/データベースにあると想定）=変更管理
• データスキーマの変更（テーブル/ビュー名、列など）=変更管理
• FeatureID 123または属性Xが入力されているかどうか誰も気にしないので、データを更新する= 管理を変更しない。フィーチャクラスに存在するデータを分析できる必要があるだけです。

それを配達サービスのように考える別の方法：新しい住所に引っ越した場合、名前を変更した場合、自治体によって住所が変更された場合は、郵便局に通知する必要があります。雑誌の新規購読を取得した場合、配達は表示されるだけなので、POは知る必要はありません。

変更管理に関する記事は、おそらくあなたが考えているものに近いでしょう。

私の組織では、毎週行われる「運用」会議で、今後の変更のリストを確認し、関係者にステータスの更新を依頼し、競合する運用を調整する機会を提供しています。

これらの手順は通常、標準の運用手順（SOP）、サービスレベル契約（SLA）、運用レベル契約（OLA）でカバーされ、個々のタスク/ワークフローはナレッジベース（KB）に文書化されています。大規模プロジェクトの戦略的な優先順位付けは、ITガバナンスによって処理されます。

中規模から大規模のITショップでは、これらの標準の少なくとも一部が既に実装されているはずです。

変更管理は、組織の構造や要件をプロジェクトに変更することではなく、日常のテクノロジーメンテナンス（サービスの再起動など）ではないようです。リンクしたウィキペディアの記事の「例」セクションから：

戦略的変更、運用上の変更（構造上の変更を含む）、技術的な変更、人員の態度や行動の変更、人格全体の変更

中規模企業での以前の仕事では、主要な生産に影響を与える変更を行う必要があるときはいつでも、「変更管理」を行わなければなりませんでしたデータベースの変更/移行/接続、ETLジョブ、サーバー構成などのITシステムまたはコンポーネント。これらに限定されません。開発およびテスト環境では、変更管理は必要ありませんでした。幸いなことに、私たちはIT部門からの信頼を得て（獲得しました）、運用環境を完全に制御するなどの自由を与えられ、必要に応じてアプリを簡単に展開して変更を加えることができました。ITには、日常の管理タスクのすべてを処理するためのGISアプリケーションの内部動作の知識を持つスタッフがいなかったため、私たちに任せていました。バウンスマップサービスは変更コントロールを必要としませんでしたが、SOPとドキュメントにありました。これらはすべて内部で利用可能でした。

私の要点：IT部門、DBA、システム管理者の信頼を獲得し、手順がシステムに与える影響を示し、できる限りそれらと連携するよう最善を尽くしてください。SOPを考え出して、変更管理が必要なものと必要でないものを文書化し、それに固執するようにしてください。