Bagaimana manajemen perubahan dapat digunakan untuk operasi GIS?


8

Saya bekerja di organisasi besar moderat di mana GIS hanya pada bagian dari platform TI. Sisa organisasi bekerja dengan "Manajemen Perubahan" dan sekarang mereka ingin agar para insinyur GIS kami menjadi lebih baik dengan permintaan Perubahan dan seterusnya.

Masalahnya adalah, sebagai Administrator GIS, kami melakukan banyak perubahan sepanjang waktu. Mulai, mulai ulang layanan peta, buat layanan baru, pindahkan data, perbarui layanan dan data.

Pertanyaan saya adalah apakah ada orang lain yang memiliki pengalaman dengan Change Management dan GIS dalam pekerjaan sehari-hari mereka dan bagaimana hasilnya bagi Anda :)

Menantikan diskusi yang menarik.

Ini adalah tautan yang menjelaskan konsep Manajemen Perubahan .


2
Apakah Change Management adalah semacam platform atau hanya nama dari alur / proses sewenang-wenang? Apakah Anda punya tautan yang menjelaskannya?
Martin

menambahkan tautan di pos asli
Andersson

Jawaban:


9

Saya juga bekerja dalam organisasi yang memanfaatkan proses Manajemen Perubahan. Bagi kami, manajemen perubahan tidak berlaku untuk operasi manajemen data harian ... yang akan luar biasa. Ini umumnya berlaku untuk perubahan pada [ sistem / basis data ] yang mungkin memiliki dampak hilir pada sistem lain.

Pada tingkat tinggi, tanyakan pada diri sendiri pertanyaan-pertanyaan ini:

  1. "Apakah orang lain mengharapkan [ sistem / basis data ] yang saya kerjakan tersedia secara konsisten?"
  2. "Apakah seseorang akan menelepon dan bertanya kepada saya apa yang salah dengan [ sistem / basis data ] karena pekerjaan yang saya rencanakan?"
  3. "Apakah bermanfaat untuk mengerjakan [ sistem / basis data ] pada waktu yang direncanakan ketika semua orang tahu itu tidak akan tersedia?"

Jika jawabannya "Ya", itu mungkin harus menjadi bagian dari Manajemen Perubahan.

Jadi gunakan contoh Anda:

  • Mulai, mulai ulang layanan map = ubah manajemen
  • Buat / perbarui layanan = ubah manajemen
  • Pindahkan data (dengan asumsi itu ke server / database baru) = ubah manajemen
  • Ubah skema data (tabel / tampilan nama, kolom, dll) = ubah manajemen
  • Perbarui data = tidak mengubah manajemen karena tidak mungkin ada orang yang peduli jika FeatureID 123 atau atribut X diisi. Mereka hanya perlu dapat menganalisis data apa pun yang ada di kelas fitur.

Cara lain untuk menganggapnya seperti layanan pengiriman: Jika Anda pindah ke alamat baru, ganti nama Anda, minta alamat Anda diubah oleh kotamadya, Anda harus memberi tahu Kantor Pos. Jika Anda mendapatkan langganan baru ke majalah, PO tidak perlu tahu karena pengiriman hanya akan muncul.


7

Artikel untuk Kontrol perubahan mungkin lebih dekat dengan apa yang Anda pikirkan.

Di organisasi saya, kami mengadakan pertemuan "operasi" mingguan di mana kami membahas daftar perubahan yang akan datang dan meminta personel kunci yang terlibat untuk pembaruan status dan memberikan kesempatan bagi operasi yang bertentangan untuk dikoordinasikan.

Prosedur ini umumnya dicakup oleh prosedur operasi standar (SOP), perjanjian tingkat layanan (SLA) dan / atau perjanjian tingkat operasional (OLA), dengan tugas / alur kerja masing-masing didokumentasikan dalam basis pengetahuan (KB). Prioritas strategis proyek-proyek besar ditangani melalui tata kelola TI .

Toko TI menengah hingga besar harus sudah menerapkan setidaknya beberapa standar ini.


3

Bagi saya sepertinya Change Management lebih tentang mengubah struktur organisasi atau persyaratan menjadi sebuah proyek, bukan pemeliharaan teknologi sehari-hari (misalnya memulai kembali layanan). Dari bagian "Contoh" dari artikel Wikipedia yang Anda tautkan ke:

Perubahan strategis, Perubahan operasional (termasuk perubahan struktural), Perubahan teknologi, Mengubah sikap dan perilaku personil, Kepribadian Perubahan Luas


3

Di pekerjaan sebelumnya di perusahaan menengah, kami harus melakukan "kontrol perubahan" kapan pun kami perlu melakukan perubahan yang memengaruhi produksi besar apa punSistem atau komponen IT, seperti, tetapi tidak terbatas pada perubahan basis data / migrasi / koneksi, pekerjaan ETL, konfigurasi server, dll. Lingkungan pengembangan dan pengujian tidak memerlukan kontrol perubahan. Untungnya, kami telah (mendapatkan) kepercayaan dari departemen TI kami, jadi mereka memberi kami kebebasan seperti kendali penuh atas lingkungan produksi kami sehingga kami dapat dengan mudah menyebarkan aplikasi kami dan membuat perubahan yang diperlukan. TI tidak memiliki staf dengan pengetahuan tentang cara kerja aplikasi GIS untuk menangani semua tugas manajemen sehari-hari, jadi mereka menyerahkannya kepada kami. Memantul layanan peta tidak memerlukan kontrol perubahan bagi kami, tetapi itu ada dalam SOP dan dokumen kami, yang tersedia secara internal untuk semua.

Maksud saya: Dapatkan kepercayaan dari departemen TI Anda, Admin DBA dan Sys Anda, perlihatkan kepada mereka bagaimana prosedur Anda memengaruhi sistem, dan cobalah yang terbaik untuk bekerja dengannya sebanyak mungkin. Cobalah untuk membuat SOP dan mendokumentasikan apa yang membutuhkan kontrol perubahan dan apa yang tidak, dan tetap melakukannya.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.