Yazılım Değişim Yönetimi: İletişim, Eğitim ve Benimseme

Değişim yönetimi genellikle projenin sonuna yakın bir eğitim haftası olarak planlanır; oysa benimsemeyi belirleyen kararlar o noktada çoktan verilmiştir. Kimin işinin değiştiği ve ne kaybettiği bir kapsam sorusudur.

Bu rehber kapsam belirlenmeden önce kime sorulacağını, değişen süreci öğretmenin neden ekranları öğretmekten iyi olduğunu ve altıncı haftaya kadar neyin hazır olması gerektiğini anlatıyor.

Kısa cevap

• Canlıya geçişte değil onayda karar verin: Kimin işinin değiştiği ve ne kaybettiği kapsam sorularıdır; bir eğitim haftası bunları yanıtlayamaz.
• Ekranları değil işi öğretin: Düğmeleri öğrenip değişen süreci öğrenmeyen personel, yeni sistemin arkasında eski yolu sürdürür.
• Eski yolu bir tarihte kapatın: İkisi de açık kalırsa öngörülebilir bir kesim hiç geçmez ve işletme iki sürecin bedelini öder.
• Altıncı haftayı planlayın: Benimseme, ilgi bittikten sonra, ilk zor vaka geldiğinde ve ekip dağıldığında kaybedilir.

Önce sonuç, sonra çözüm

Değişim yönetiminin hedefi, insanların işi yeni yoldan yapmasıdır; yeni ekranın arkasında eski süreci sürdürmesi değil. Hangi rollerin ve nasıl değiştiğini yazın. Bu liste yazılmadan hazırlanan iletişim planı, kimsenin sormadığı soruları yanıtlar.

Etkilenen rolleri ve her birinin neyi bıraktığını listeleyin. Biri inisiyatifini, biri bir ilişkisini, biri uzmanı olduğu şeyi kaybeder ve devreye almanın kaderini bu üç kişi belirler. Listeyi ilgili yöneticilerle değil, işi yapan kişilerle birlikte çıkarın.

Bu listeyi proje onaylanırken çıkarın. Lansmana yakın yapılan bir eğitim haftası, benimsemeyi belirleyen kararlar çoktan verildiği için hiçbir şeyi değiştiremez. Onay toplantısına etkilenen gruptan birini çağırın; sonradan yapılan davet geç kalmış olur.

Yazılım değişim yönetimi planı için dört karar alanı

Liderlik

Değişimin başarısından açıkça kimin sorumlu olduğunu belirleyin ve bu kişinin sistemi kendisinin kullanıp kullanmadığını kontrol edin. Hiç açmayan bir sponsor iki hafta içinde personele görünür olur ve değişimin ne kadar önemsendiğini onlara tam olarak anlatır.

Kullanıcılar

En çok kaybedecek grubu, tam olarak neyi kaybettiğini ve bunu kendisine soran olup olmadığını belirleyin. Direnç genellikle kabul edilmemiş bir bedele verilen akılcı bir yanıttır ve yanıtlamak, aşmaya çalışmaktan ucuzdur.

Geçiş

Eski yöntemin biteceği tarihi sabitleyin, istisnaları kimin onaylayacağına karar verin ve kaç istisna beklediğinizi tahmin edin. İki yol da açık kalırsa personelin öngörülebilir bir bölümü bildiği yolu kullanmaya devam eder ve işletme iki süreci birden çalıştırır.

Pekiştirme

Altıncı haftada, proje ekibi başka işe geçtiğinde ve ilk zor vakalar geldiğinde ne olacağını planlayın. Benimseme, ilgi bittikten sonra kaybedilir ve yanıtı bilecek kişi o zamana kadar genellikle başka bir projededir.

Kodlamadan önce riskleri konuşun

• Sponsor sistemi hiç kullanmaz: Sorumlu kişinin sistemi açıp açmadığını kontrol edin; personel bunu iki haftada fark eder. Sponsor kullanmıyorsa personel de kullanmaz.
• Kaybeden tarafa sorulmaz: Etkilenen grubun neyi bıraktığını öğrenin ve bunu aşmaya değil yanıtlamaya çalışın. Kaybı adlandırmadan direnci aşmaya çalışmak süreyi uzatır.
• Eski yol açık kalır: Kapanış tarihini sabitleyin, istisnaları kimin onaylayacağını belirleyin ve sayısını tahmin edin. İstisna sayısı beklenenden çoksa tarih gerçekçi değildir.
• Altıncı haftada destek biter: Proje ekibi dağıldıktan sonra soruları kimin yanıtlayacağını lansmandan önce yazın. Altıncı hafta sahibi yoksa sorular yanıtsız kalır ve eski yol geri gelir.

Yol haritası: uygulanabilir adımlar

1. Değişimin bedelini bulun. Etkilenen rolleri ve her birinin neyi bıraktığını listeleyin, birini yönlendirme kuruluna çağırın.
2. Bir kişinin gününü yazın. İşin yeni halini tarif edin ve siz izlerken o kişiye adım adım uygulatın.
3. Değişen işi öğretin. Eğitimi ekran özellikleri üzerine değil, tereddüt ettikleri noktalar üzerine kurun.
4. Altıncı haftayı planlayın. Proje ekibi dağıldıktan sonra soruları kimin yanıtlayacağını şimdi belirleyin.

Pilot yönetişimi ve yatırım kararları

Yazılım değişim yönetimi planı pilotunun amacı ürünün bütün gelecek kapsamını kanıtlamak değildir. En önemli kullanıcı veya işletme varsayımını gerçek koşullarda sınamalıdır. Pilot grubu, başlangıç seviyesi, gözlem süresi, destek modeli ve devam kararı baştan yazılırsa sonuçlar yalnızca olumlu örnek seçerek yorumlanmaz.

Haftalık karar ritmi kurun. Kullanıcı değeri, operasyon akışı, veri ve sistem sınırları ve başarı ölçümü başlıklarında toplanan kanıtı aynı masada değerlendirin; ürün kullanımı ile iş sonucunu ayırın. Karar seçenekleri “devam et” ile sınırlı olmasın: kapsamı düzeltme, veriyi iyileştirme, operasyonu değiştirme, belirli kullanıcı grubunu erteleme veya yatırımı durdurma da meşru sonuçlardır.

Pilot sonunda hangi yeteneğin işletmeye devredileceğini netleştirin. Ürün erişimleri, veri görünürlüğü, izleme, destek bilgisi, karar geçmişi ve sonraki yol haritası yalnızca geliştirme ekibinde kalmamalıdır. Bu sahiplik, yazılım değişim yönetimi planı yatırımının kontrollü biçimde büyümesini sağlar.

Sonraki adım

Yazılım değişim yönetimini lansman öncesi bir eğitim haftası olmaktan çıkarın. Kimin işinin değiştiği ve ne kaybettiği kapsam sorusudur ve projenin onaylandığı gün yanıtlanmalıdır.

Konunun diğer yarısı şurada: Tasarım Sistemi Platformu Geliştirme Maliyetini Neler Belirler?

30 günlük doğrulama planı: Yazılım değişim yönetimi

1-5. günler: değişimin kime neye mal olduğunu bulun. Etkilenen rolleri listeleyin ve her biri için neyi bırakacağını, bıraktığında neyi kaybedeceğini yazın. Biri inisiyatifini kaybeder, biri bir ilişkisini, biri uzmanı olduğu şeyi. Devreye almanın işe yarayıp yaramayacağına bu üç kişi karar verir ve genellikle hiçbiri proje toplantılarında bulunmaz. Onlardan birini bir sonraki yönlendirme toplantısına çağırın; bedelini ödeyen insanlar olmadan tasarlanan bir değişim, başarısızlık noktası önceden belli bir plandır.

6-15. günler: ekranları değil değişen işi öğretin. Bir kişinin yeni iş gününü yazın ve onunla birlikte adım adım gidin. Eğitim hangi düğmeye basılacağını anlatıp işinin artık ne olduğunu anlatmıyorsa personel arayüzü öğrenir ve arkasında eski süreci sürdürür; teknik olarak başarılı bir lansmanın en yaygın başarısızlık biçimi budur. Adımları siz izlerken kendileri uygulasın; tereddüt ettikleri yerler, eğitim malzemesinin hakkında yazılması gereken yerlerdir.

16-30. günler: altıncı haftayı planlayın. Proje ekibi dağıldıktan sonra soruları kimin yanıtlayacağına ve o dönemde bildirilen bir sorunun nasıl düzeltmeye dönüşeceğine şimdi karar verin. Benimseme genellikle ilginin bittiği haftalarda, ilk zor vaka geldiğinde ve yanıtı bilecek kişi başka bir projedeyken kaybedilir. O kişiyi lansmandan önce belirleyin; bu rol önceden atanması kolay, ekip dağıldıktan sonra doldurulması neredeyse imkansız bir roldür.

Pratik çalışma sayfası: Yazılım değişim yönetimi

Değişim yönetimi genellikle projenin sonuna yakın bir eğitim haftası olarak planlanır. Bunun yerine bu satırları proje onaylandığı anda doldurun ve tabloyu yönlendirme kurulunun göreceği bir yerde tutun.

Teknik olarak başarılı sayılan devreye almaların en yaygın nedeni, insanlara değişen süreç yerine ekran özelliklerinin öğretilmesidir. Personel düğmelere basmayı bilir ama işinin artık ne olduğunu bilmez ve bu, destek yükü olarak geri döner.

İlgili rehberler

• Uygulamada nasıl göründüğü için bakın: Pratik Bir Dijital Dönüşüm Yol Haritası Nasıl Hazırlanır?.
• İkinci bir bakış açısı için: Kağıtsız İş Akışı: Kağıt Tabanlı Süreçler Nasıl Dijitalleştirilir?.

Yazılım Değişim Yönetimi: İletişim, Eğitim ve Benimseme yazısındaki öncelikler gerçek bir bütçeye göre sıralanacaksa Dijital Yol Haritanızı Konuşalım.