Değişim Yönetiminden Çıkarılan Dersler

[00:00:00] Bugün bizi dinleyen herkese çok teşekkürler. Bugün sizinle değişim yönetimi hakkında konuşacağız. Bu, son zamanlarda sohbetimizde sıkça gündeme gelen bir konu. Bu yüzden artık yeterince konuşulduğunu düşünüp birkaç kişiyi bir araya getirerek yaşananları konuşmak istedim.

Amacımız, kendi projelerimizde ve kuruluşlarımızda değişim yönetiminden geçtiğimiz, bu sürecin hem uygulayan hem de etkilenen tarafında yer aldığımız için, burada ortak bilgiyi paylaşmak ve geliştirmeye yardımcı olmak. Bu zamanı bazı hikâyeleri paylaşmak, süreç boyunca öğrendiklerimizi konuşmak ve kendi süreçlerinde ya da değişimlerinde nerede olurlarsa olsunlar başkalarına yardımcı olmak için kullanmak istedim.

Bence topluluğun güzelliği de bu: ortak bilgiyi geliştirmek. Birkaç kişiden hikâyelerini getirmelerini istedim. Eğer sizin bir hikâyeniz yoksa sorun değil. Oturum sırasında aklınıza bir örnek gelirse o da olur. Amacım bu hikâyelerden bazılarını paylaşabilmek.

Sorular ortaya çıktıkça lütfen onları sohbete yazmaktan ya da doğrudan sormaktan çekinmeyin. Bu büyük ölçüde bir tartışma olacak. Yol boyunca öğrendiğimiz bazı şeyleri paylaşabiliriz. Umarım bugün ayrılırken kendi projelerimizde değişime yaklaşmak için birkaç araç ve fikir edinmiş oluruz.

Başlangıç yapmak üzere bir hikâye getirmesini istediğim kişilerden biri Fred’di. Fred, istersen sözü sen al; buradan başlayalım. Daha sonra sohbetten soruları paylaşabilir, el kaldırabilir ve sorularınızı doğrudan sorabilirsiniz.

Evet, kesinlikle. Öncelikle bunu düzenlediğiniz için çok teşekkürler. Böyle etkinlikleri görmek güzel; insanların sorularına ve ihtiyaçlarına doğrudan yanıt veren etkinlikleri görmek ise daha da güzel. Bu, topluluk oluşturuyor.

Bir hikâye paylaşmaya davet ettiğiniz için de teşekkürler. Benim geçmişim öğretim sistemleri tasarımı alanında ve bu alanda doktoram var. Teori ve modellerin tamamına baktım. Öğretim sistemleri tasarımının bir parçası da kurumsal gelişimdir ve değişim yönetimi bunun önemli bir bölümünü oluşturur.

Resmî değişim yönetimi konusunda, örneğin bir değişim ekibinde görev yapmak gibi, çok büyük bir deneyimim olmasa da öğrenen organizasyonlar hakkında araştırma yaptım. Peter Senge’nin öğrenen organizasyon yaklaşımını, Beşinci Disiplin’i, Kotter’ın sekiz adımlı modelini ve Lewin’in çözülme-değişim-yeniden donma modelini inceledim. Bu modeller değişimi düşünmek için gerçekten yararlı çerçeveler sunuyor.

Bunlar, geçebileceğiniz süreçleri ve bu süreçte yapabileceğiniz şeyleri düşünmenize yardımcı oluyor. Uygulama çalışmaları açısından da Everett Rogers’ın yeniliklerin yayılımı ve benimsenmesi üzerine çok çalışması var. Teknoloji benimsenirken kritik bir kitleye ulaşma fikrinden söz ediyoruz. Her şeyi hemen benimseyen yenilikçiler vardır; bir süre bayrağı onlar taşır. Ancak bu grup doyuma ulaştığında daha geniş bir kesime ulaşmak gerekir.

Daha sonra erken benimseyenlere ulaşılır ve herkesin ne olduğunu bildiği, üzerinde düşünmeye başladığı kritik kitleye erişilir. Sonra süreç ilerler ve geç benimseyenler ortaya çıkar. Kuruluşta herkes Microsoft Teams ya da benzeri bir aracı kullanırken bile, sonunda “Ben bunu kullanmıyorum” diyen birkaç kişi mutlaka olur.

Yükseköğretim alanından geliyorum. Okulun tamamı Google ya da Microsoft kullanıyor olsa bile, “Ben o e-postayı kullanmıyorum, diğer adresimi kullanıyorum” diyen birkaç öğretim üyesi mutlaka vardır. Öğrenciler sizinle nasıl toplantı ayarlayacak? Takviminize nasıl erişecekler? Programınızı bağlamanın, taşıyıcı güvercinle e-posta göndermenin ve buna benzer şeylerin karmaşık yollarını bulmaları gerekir.

Bunun arkasında modeller ve teoriler var. Çok uzatmamak için hızlıca bir deneyim paylaşayım. Yıllar boyunca birçok farklı deneyim yaşadım ve burada en uygun olacağını düşündüğüm örnek, kuruluşların monday.com ve benzeri araçlarla yeniden yapılandırılmasına yardımcı olmakla ilgili.

Bir müşterim büyük şirketler için eğitimler hazırlayan bir e-öğrenme firmasıydı. Bu müşterilerden biri daha önce Monday kullanmıştı ancak araç gerektiği gibi planlanmadan uygulanmıştı. Çoğu Monday projesi aslında Monday projesi değil, iş süreci projesidir. İnsanların standart operasyon prosedürlerini oluşturmadığını, iş akışlarını haritalamadığını ya da ideal sürecin nasıl olması gerektiğini düşünmediğini görürsünüz.

Nerede olduğunuzu bilmiyorsanız değişim yapamazsınız. Bu nedenle istediğiniz sonuçları elde edemezsiniz. Bu müşteriyle yaklaşık bir yıl boyunca derinlemesine çalıştım; sistemlerini yeniden yapılandırdık, performansı ve proje teslimini geliştirdik, kalite sorunlarını azalttık.

Bütün bunlar, ideal durumun ne olması gerektiğini, mevcut durumun ne olduğunu ve ikisini nasıl birleştirebileceğimizi anlamaya yönelik yinelemeli döngülerden oluştu. Bu süreç muhtemelen en basit hâliyle bütün değişim modellerinin ulaşmaya çalıştığı şeydir.

İster kilo vermeye, güçlenmeye, yeni bir beceri öğrenmeye ya da evinizi düzenlemeye çalışın, önce ideal durumun nasıl göründüğünü ve şu anda nerede olduğunuzu analiz etmeniz gerekir. Bu projeden aldığım en önemli derslerden biri, problemin tanımlanmamış olmasıydı; tanımlanmamış bir problemi çözemezsiniz.

Ayrıca farklı proje iş akışlarının mevcut olduğunu ama birbirine bağlanmadığını gördüm. Bir danışman projenin nerede olduğunu sorduğunda, “Müşteriye teslim ettim” deniyordu. Ne zaman? Üç hafta önce. Şimdi nerede? Müşteriden haber gelmedi. Takip ettin mi? Henüz değil. Bu tür devir süreçlerini haritalamak ve farkında olmak çok önemli.

Bu deneyimden çıkardığım dersler şunlar: Yeni bir müşteriyle çalışmaya başladığımda önce problemi net biçimde tanımlamaya, analiz etmeye ve ne yapmaya çalıştıklarını tam olarak anlamaya çalışırım. Hangi aracı kullanacağımıza hemen karar vermem. Programlama da böyledir; kod yazmaya başlamadan önce ne yapmaya çalıştığınızı bilmeniz gerekir.

Daha sonra onlarla birlikte istedikleri süreci ifade etmelerini sağlarım. Bir şeyin gerçekleşmesini istiyorsak bu nasıl görünüyor? Sonra kime gidiyor? Nereye aktarılıyor? Bundan sonra ne oluyor? Girdileri nereden alıyorsunuz? Amaç basitçe bir harita oluşturmaktır.

Bu noktada şunu sormak istiyorum: Bu alana geldiğinizde ve insanların hiçbir şeyi olmadığı için onlar adına standart operasyon prosedürleri oluşturmaya başladığınızda, kendi yöntemlerine alışmış kişiler direnç gösterdi mi? Onları bu süreçlere nasıl dâhil ettiniz?

Bu gerçekten iyi bir soru. Bu örnekte çoğunlukla sahiplerle çalışıyordum. Bu avantajlıydı çünkü asıl paydaş oydu ve her şeyi o biliyordu. Sorun, bütün bilgilerin yalnızca onun zihninde bulunmasıydı; bunlar mutlaka uygulanmıyor ya da başkalarına aktarılmıyordu.

Diğer kişiler danışmanlardı, tam zamanlı çalışan değillerdi. Amaçları projeyi mümkün olduğunca hızlı ve verimli biçimde teslim etmekti. İşletmeye ve işletmenin uzun vadeli başarısına, iyi bir ürün teslim etmenin ötesinde yatırım yapmış değillerdi. Onların da tercih ettikleri bir çalışma yöntemi vardı; bu yöntem tanımlı olabilir ya da olmayabilirdi.

Bu iki yaklaşım her zaman örtüşmüyordu. Sahip süreci belirliyor ve danışmanın buna uymasını istiyordu; danışman ise aynı fikirde olmayabilirdi. Burada proje saatleri, kontrol noktaları ve denge mekanizmaları devreye girer. Direnç vardır ve bence her zaman olacaktır.

Bunun bir kısmı, sürecin nasıl olacağına ilişkin yönlendirme yapmaktır. Bir kısmı ise önerilere açık olmak ve insanların doğru yaklaşımın ortak yazarı olmasına izin vermektir. Doğru denge, duruma göre değişir ve müzakere edebileceğiniz şeylere bağlıdır.

Bu deneyimin sizin için nasıl yankı bulduğunu merak ediyorum. Kendi alanınızda benzer zorluklar ya da yaklaşımlar gördünüz mü?

Bir sorum var Fred. Her şeyin bir kişinin zihninde olduğu durumda, bilginin önemli olduğunu ve bu kişinin size zaman ayırması gerektiğini nasıl anlatıyorsunuz? Kaotik ortamlarda çalışıyorum; insanlar sürekli meşgul ve “Bunu yapacak bir dakikam yok” diyorlar.

Aklıma birçok şey geliyor. Proje yöneticileri olarak direksiyonu biz tutmuyoruz; haritayla yolcu koltuğunda oturuyor ve sürücüye hangi yöne dönmesi gerektiğini söylüyoruz. “Yarım mil sonra sola dönmemiz gerekiyor, sinyalini şimdiden ver” diyoruz. Ama direksiyon onların elinde.

Dönüşü kaçırırlarsa yapabileceğimiz en iyi şey, bunu fark edip bir sonraki uygun yerde dönerek rotayı düzeltmektir. Yolculuğun sonunda neden üç saat fazla sürdüğünü sorduklarında, onlara kaçırılan dönüşleri ve bunları telafi etmek için yaptığımız değişiklikleri hatırlatmamız gerekir.

Bazen insanlar sürecin zaten tamamlandığını düşünür ama aslında değildir. Bu müşteride toplantıların önemli bir kısmını onun tüm işlerini ve mesajlarını dinleyerek geçirdim. Bir saatlik toplantının sonunda ancak iki ya da üç aksiyon maddesi belirleyebildiğimiz oluyordu.

Saatlik çalışıyorsanız bu yaklaşım işe yarayabilir. Proje bazlı çalışıyorsanız farklı davranmanız gerekir. İnsanlara bazen pahalı bir terapist ya da arkadaş olduğumu söylüyorum. Ancak ne yapılması gerektiğini açıkça belirtmek de benim sorumluluğum.

Bazen müşteriler bir şey yapmamı ister, ben çalışmaya başladıktan sonra fikrini değiştirip başka bir şey yapmamı ister. Saatlik çalışıyorsam bunu sürdürebilirim ama proje bazlı çalışıyorsam hemen durumu netleştirmem gerekir. Aksi hâlde saatlerce yaptığım iş boşa gidebilir.

Bu durumlarda yapılabilecek en iyi şey, müşterinin hızlı bir araba istemesine benzer. Bunun Porsche mi yoksa Lamborghini mi olduğunu başlangıçta bilmiyor olabilir. Süreç ilerledikçe ne istediğini fark eder. Müşteriyle konuşup toplantının sonunda alınan kararları özetlemek ve e-posta ile kayıt altına almak çok yararlıdır.

Böylece iki hafta sonra ne üzerinde çalıştığımızı hatırlatabilirsiniz. Kimin ne yapacağını, hangi teslimatların beklendiğini ve hangi işlerin başkasından gelecek bilgiye bağlı olduğunu açıkça gösterebilirsiniz.

Kayıtlar özellikle aksiyon maddeleri için çok faydalıdır. Değişim yönetiminin proje yönetiminden farkı konusunda da bir soru vardı. Proje, bir ürün ya da sonuç ortaya çıkaran geçici bir girişimdir. Değişim yönetimi ise değişimin kendisini yönetme sürecidir.

Örneğin yeni bir web sitesi teslim ettiğinizde, bu durum müşterinin süreçlerinde değişikliğe yol açar. İletişim formu değişmiş olabilir, başvurular farklı biçimde gelebilir ya da yeni CRM alanları eklenmiş olabilir. Bunların hepsi olumlu gelişmeler olabilir ama yine de değişimdir.

Bu değişimi nasıl iletişim kurarak yöneteceğimizi, insanları nasıl hazırlayacağımızı ve değişime direnç gösterenlerin nasıl destekleneceğini düşünmemiz gerekir. Bir projede, eski bir yazılımın yerine yeni bir sistem konulurken paydaşlara yeterince danışılmadı. Kullanıcı testleri sırasında alınan kararların yanlış olduğu ortaya çıktı ve milyonlarca dolarlık ek çalışma gerekti.

Başlangıçta kullanıcılarla çok fazla konuşulmamasının geçerli nedenleri vardı; diğer tedarikçi sistemi erkenden çekseydi işletme çalışamazdı. Ancak geriye dönüp bakıldığında daha iyi iletişim yöntemleri kullanılabilir ya da risk kaydında bu kararların sonuçları açıkça belgelenebilirdi.

Projenin sonuna yaklaşırken kullanıcıların sistemi doğrudan kullanmaya başlaması yerine kontrollü bir ön uygulama süreci başlatıldı. Bu, sürekli kullanılabilirlik testi gibi işledi ve kullanıcılara geri bildirim verme imkânı sundu. İnsanlar dinlendiklerini hissettiklerinde değişimi zorla dayatıldığından daha kolay kabul ederler.

İlk denemede sistemi insanlara verip “başlayın” demenin kötü bir fikir olduğunu gördük. Daha sonra grupları birlikte test yapacak şekilde organize ettik. Herkesin soruları ve ilerlemesi görünür hâle geldi; böylece kimlerin sürece katıldığını ve kimlerin geride kaldığını takip edebildik.

Değişim yönetiminde iletişim, geri bildirim ve paydaşların sürece katılması çok önemlidir. Büyük hataları paydaşlara anlatırken de durumu yumuşatmak yerine gerçekleri, nedenleri ve olası çözüm yollarını açıkça sunmak gerekir. Tarafsız bir üçüncü taraf olarak, “Şu anda durumumuz bu; buradan çıkmak için A, B ve C seçenekleri var” demek çoğu zaman en iyi yaklaşımdır.

Değişim yönetimi ekipleriyle birlikte çalışmak da ilginç olabilir. Bu ekipler genellikle iletişim kurma, geri bildirim alma ve destek sağlama konularında uzmanlaşır. Proje ekibi belirli bir teslimata odaklanırken değişim yönetimi ekibi bütün kuruluşun bu değişime nasıl uyum sağlayacağını düşünür.

Bazen görev sınırları belirsizleşebilir. Örneğin değişim yöneticisi bunun bir e-posta, toplantı ya da eğitim olması gerektiğini söyler; iletişim sorumlusu da buna uygun içeriği hazırlar. Değer, bu parçaları bir araya getirip değişimin önceliklendirildiğinden emin olmaktan gelir.

Küçük kuruluşlarda özel bir değişim yönetimi ekibi bulunmayabilir. Bu durumda değişim yönetimi proje yöneticisinin sorumluluğuna kalabilir. Değişim hiç düşünülmezse proje sonrasında sistem başarısız olabilir.

Bir başka örnekte, küçük bir yaratıcı ajans birden fazla işten çıkarma dalgası yaşadı. Yaratıcı ekip ortadan kalktı; ajansın ihtiyaçları büyük yaratıcı projelerden araştırma ve stratejiye kaydı. Kullanılan araçlara ilişkin belgeler artık mevcut ekibin ihtiyaçlarını karşılamıyordu.

Operasyon ekibi de üç kişiden iki kişiye, ardından tek kişiye düşmüştü. Asana ana proje yönetimi aracıydı ancak ekip Asana’nın nasıl kullanılacağını bilmiyor, Slack ile Asana arasındaki sorumluluklar karışıyordu. Bu nedenle kısa parçalardan oluşan bir eğitim programı hazırladım.

Önce sorunu tanımladım: Ekibin gerçekten neyi bilmesi gerekiyordu? Ardından mevcut kaynaklara baktım. Asana’nın hazırladığı kısa videoları kullandım ve her kişi için kopyalanabilen bir Asana projesi oluşturdum. Her görev, yaklaşık beş dakikalık küçük bir bilgi parçasıydı.

Eğitim; görev yorumlarının nasıl kullanılacağını, profilin nasıl ayarlanacağını, bildirimlerin nasıl kapatılacağını ve gelen kutusundan nasıl çalışılacağını açıklıyordu. İnsanları gereksiz bilgilerle boğmak istemedim. Amaç, aracın nasıl kullanılacağını ve kuruluşun bu araçla nasıl çalışacağını netleştirmekti.

İnsanların bunları uyguladığından nasıl emin oldum? Eğitim başlamadan önce kısa bir toplantı yaptım ve bunun istikrar ve kolaylık sağlamak için hazırlandığını anlattım. Görevleri tamamladıklarında işaretlemelerini, bir şey açık değilse işaretlemeyip yorum yazmalarını istedim.

Ekibin küçük olması ve insanların kontrol listelerini sevmesi süreci kolaylaştırdı. Bazen hatırlatma göndermek işin bir parçasıdır. Yapılan konuşmaları ve verilen talimatları yazılı olarak kaydetmek, değişimin uygulanmasını takip etmeyi kolaylaştırır.

Ekip zaten kontrol listelerine yatkın olduğu için sistemi onların doğal çalışma biçimine uyarladım. Bu, yeni bir davranış dayatmak yerine mevcut alışkanlıkları bir avantaja dönüştürdü.

Değişimden sonra insanların eski yöntemlerine dönebileceği de unutulmamalıdır. Bazı kişiler araçları sevmez ve daha tanıdık gelen Slack’i kullanmaya devam edebilir. Böyle durumlarda beklentileri baştan açıkça belirlemek, düzenli takip yapmak ve gerektiğinde dostça hatırlatmalar göndermek gerekir.

Bir diğer önemli konu değişim yorgunluğudur. Uzun projelerde öncelikler sürekli değişebilir, müşteriler her gün yeni talepler getirebilir ve ekipler tekrar tekrar yeniden yapılanabilir. Kısa vadeli ve uzun vadeli değişim yorgunluğuyla başa çıkmak için öncelikle insanların yaşadığı zorluğu kabul etmek gerekir.

İnsanlara yeni durumda tanıdık olan şeyleri göstermek yararlıdır. Örneğin yüz yüze eğitimden çevrim içi eğitime geçerken öğretme, tartışma ve öğrencileri sorumlu tutma gibi temel faaliyetler aynı kalabilir; yalnızca yöntem değişir.

Uzun vadede sürekli araç ve süreç değiştirmek güveni zedeler. İnsanlar yeni bir aracın birkaç ay sonra değişeceğini düşünürse onu öğrenmek için enerji harcamak istemez. Bu nedenle değişimin kültürel yönünü konuşmak ve temel çalışma ilkelerini araçlardan bağımsız biçimde tanımlamak gerekir.

Değişim yorgunluğu yaşayan ekiplerle açık ve insani bir iletişim kurmak önemlidir. “Bunun zor olduğunu biliyorum, bunun zaman alacağını biliyorum” demek insanların görüldüğünü hissetmesini sağlar. Değişimin onların günlerini nasıl kolaylaştıracağını da açıklamak gerekir.

Proje yöneticisi, projenin içindeki tonu belirler. Yönetici her şeyi anlamsız buluyorsa ekip de bunu hisseder. Bu nedenle kendi duygu ve düşüncelerimizi süzgeçten geçirerek ekibe istikrar sağlamaya çalışmalıyız.

Çok fazla değişim olduğunda işlerin yavaşlaması ve verimliliğin geçici olarak düşmesi normaldir. İnsanların yeni süreçleri öğrenmek, yeniden yönlenmek ve değişime uyum sağlamak için zamana ihtiyacı vardır. Bu nedenle beklentileri buna göre ayarlamak gerekir.

Ayrıca daha az iş yapıyor gibi hissetmek moral bozucu olabilir. İnsanlar kendilerini önceki dönemle karşılaştırabilir. Bu noktada daha yavaş ilerlemenin geçici ve gerekli olduğunu hatırlatmak, küçük ilerlemeleri görünür kılmak ve insanların kendilerine alan tanımasına yardımcı olmak önemlidir.

Günün sonunda yalnızca üç işi tamamlamış olmak da yeterli olabilir. Kendimize “Bugün yeterince çalıştım” deme izni vermeliyiz. Çalışma temposu da ayrıca konuşulabilecek önemli bir konudur; insanlar çoğu zaman başkalarının hızına göre kendi hızlarını belirler.

Artık görüşmenin sonuna geldik. Katılan ve bu tartışmaya katkıda bulunan herkese teşekkür ederim. Başkalarının yaşadığı zorlukları duymak hem doğrulayıcı hem de öğretici oldu. Bu fikirlerden ve süreçlerden bazılarını kendi işlerimize taşıyabiliriz.

Bir sonraki etkinliğimiz 23 Mayıs’ta gerçekleşecek. Canlı bir forum düzenleyeceğiz. İşte karşılaştığınız, aklınızda olan zorlukları getirecek ve bunları hep birlikte tartışacağız. Bu etkinlik yalnızca değişim yönetimiyle sınırlı olmayacak; iş hayatında karşılaştığınız her türlü güncel konuya açık olacak.

Tekrar teşekkürler. Günün geri kalanının güzel geçmesini dilerim. Slack’te görüşürüz. Herkese hoşça kalın. [00:55:00] [00:56:00] Teşekkürler.