Bir keresinde bir CFO, şirketinin bir "dijital dönüşüm" için on sekiz ay ve yedi haneli bir bütçe harcadığını söyledi. İşi yapan insanlar için gerçekte neyin değiştiğini sorduğumda duraksadı, sonra itiraf etti: işi hâlâ aynı üç elektronik tablo yürütüyordu. Platform yayındaydı. Kimse kullanmıyordu.
İşte dönüşüm tuzağı budur. Bir teknoloji başarısızlığı değil — bir çerçeveleme, sıralama ve sahiplenme başarısızlığı. Ve nereye bakacağınızı bildiğinizde son derece öngörülebilirdir.
Bu projeler gerçekte neden başarısız olur
Otopsiler her zaman tedarikçiyi, entegrasyonu ya da zaman çizelgesini suçlar. Danışmanlık verdiğim projelerde asıl nedenler çok daha yukarıda durur ve sektörler boyunca birbirini tekrarlar.
- Dönüşüm, sonuçlar olarak değil, yazılım olarak tanımlandı. "ERP'yi devreye al" bir teslimattır. "Siparişten-tahsilata süresini 40 günden 15 güne indir" bir hedeftir. Aracın etrafında kapsamlandırılan projeler neredeyse her zaman aracı teslim eder ve asıl amacı ıskalar.
- Tek bir hesap verebilir sahip yok. Bir program BT, operasyon ve bir yönlendirme komitesi tarafından ortaklaşa sahiplenildiğinde, hiç kimse tarafından sahiplenilmez. Kararlar, departmanlar arasındaki dikiş yerlerinde takılıp kalır.
- Büyük patlama teslimatı. Ekipler her şeyi inşa etmek için bir yıllığına ortadan kaybolur, sonra ortaya çıkıp işin ilerlemiş olduğunu keşfeder. Harcama ile geri bildirim arasındaki boşluk ne kadar uzunsa, krater o kadar büyük olur.
- Son adıma bütçe ayrılmaz. Değişim yönetimi, eğitim, veri temizliği ve süreç yeniden tasarımı sonradan akla gelen şeyler olarak görülür — oysa benimsenme tam da orada kazanılır ya da kaybedilir.
İnsanların bir salı günü nasıl çalıştığındaki ölçülebilir bir değişiklik olarak tarif edemediğiniz bir dönüşüm, dönüşüm değildir. O bir satın alma faaliyetidir.
Büyük patlama efsanesi
Kurumsal teknolojideki en pahalı varsayım, uzun ve sessiz bir inşanın teslimatın riskini azalttığıdır. Tam tersini yapar. Sistem ile gerçek bir kullanıcı arasında temas olmayan her ay, biriken, görünmez yanlış varsayımların bir ayıdır.
Müşterilerimi ince dikey dilimlere doğru iterim: bir ekip, bir iş akışı, bir ölçülebilir metrik seçin ve haftalar içinde üretimde kullandıkları bir şey çıkarın — bir demo değil, bir kum havuzu değil, gerçek iş. Her katmana (veri, mantık, arayüz ve etrafındaki insani süreç) dokunan bir dilim, entegrasyon acısını ve siyasi sürtüşmeyi erkenden, ikisi de hâlâ ucuza düzeltilebilirken yüzeye çıkarır. Her biri bir sayıyı oynatan on küçük sürüm, yalnızca bir lansman tarihini oynatan tek bir kahramanca sürümü yener.
Riski azaltmak: gerçekte işe yarayan şey
Risk, daha iyi planlama belgeleriyle ortadan kalkmaz. Geri bildirim döngülerini kısaltarak ve başarısızlığı atlatılabilir kılarak ortadan kalkar. Tutarlı biçimde karşılığını veren birkaç hamle:
Her aşamayı bir iş metriğine bağlayın
Bir satır kod yazmadan önce, aşamanın oynatması gereken sayı üzerinde uzlaşın — döngü süresi, hata oranı, işlem başına maliyet, gelir sızıntısı. Bir iş kolu kendi metriğini adlandıramıyorsa, o yol haritasının değil, çıkarılacaklar listesinin bir adayıdır.
Gerçek yetkiye sahip tek bir sahip belirleyin
Sonuçtan hesap verebilen, hayır deme yetkisiyle donatılmış tek bir kişi. Bir komite değil, on dört isimli bir RACI çizelgesi değil. Kimin karar verdiğine dair belirsizlik, tıkanmış bir programın tek başına en güvenilir habercisidir.
Göç etmeden önce ölçümleyin
Eskisini hiç ölçmediyseniz, bir sistemin daha iyi olduğunu kanıtlayamazsınız. Önce temel değeri yakalayın. Bunu atlayan ekipler, sonunda farklar (delta) yerine duygular üzerine tartışır ve en yüksek ses kazanır.
Son adım için baştan bütçe ayırın
Benimsenme çalışmasının bir yuvarlama hatası değil, çabanın üçte biri olduğunu varsayın. Onu kullanacak insanları eğitin, veriyi yeni sistemi zehirlemeden önce temizleyin ve eski keçi yolunu pahalı yeni asfaltla döşemek yerine süreci yeniden tasarlayın.
Yapay zekâ hızlandırıcısı
Yapay zekâ tuzağı daha iyi değil, daha kötü hâle getirdi. "Yapay zekâyla bir şeyler yap" baskısı, sahibi olmayan, temel değeri olmayan ve üretime giden bir yolu olmayan pilotlar üretiyor — aynı başarısızlık deseni, şimdi daha moda bir etiketle. Bir demoda etkileyen ama gerçek bir iş akışına hiç dokunmayan bir model dönüşüm değildir; bir tiyatrodur. Aynı disiplini uygulayın: bir iş akışı, bir metrik, bir sahip ve onun bir şeyi oynatıp oynatmadığına dair hızlı, dürüst bir ölçüm.
Pazartesi nereden başlamalı
Yeni bir strateji sunumuna ihtiyacınız yok. Şu anda yürümekte olan ve sizi en çok endişelendiren tek dönüşümü seçin ve üç soru sorun: Hangi sayıyı oynatması gerekiyor? Oynatmazsa kim hesap verecek? Gerçek bir kullanıcı ona üretim ortamında bir sonraki kez ne zaman dokunacak? Herhangi bir yanıt muğlaksa, riskinizi bulmuşsunuz demektir — ve ilk düzeltmenizi.
Başarılı olan projeler nadiren en iyi finanse edilen ya da en iddialı olanlardır. Onlar, büyümeye hak kazanana kadar küçük kalacak kadar dürüst olanlardır. Bu yüzden bir sonraki başlangıcınızdan önce, kendinize o rahatsız edici soruyu sorun: işin nasıl yapıldığını mı değiştiriyoruz, yoksa yalnızca altındaki yazılımı mı?