Dijital dönüşüm neden tıkanır?

Başarısızlık gerçekten bu kadar yaygın mı?

Dönüşüm projelerinin büyük kısmının hedefine ulaşmadığı yönetim literatüründe uzun zamandır tartışılıyor. John Kotter’ın Harvard Business Review’da yayımlanan “Leading Change: Why Transformation Efforts Fail” makalesi, bu konuda hâlâ en çok başvurulan metinlerden biri. Kotter, yeterli aciliyet duygusu yaratmamak, vizyonu yeterince anlatmamak ve zaferi erken ilan etmek gibi hataları sıralar. Makale 1990’larda, bulut ve yapay zeka araçlarından çok önce yazıldı ama hataların neredeyse hepsi bugün de geçerli.

Bu yazıda bir başarısızlık yüzdesi vermiyoruz. Böyle oranlar tanıma ve örnekleme göre çok değişiyor. Daha işe yarar olan, kendi projenizde hangi sebebin etkili olduğunu erken görmektir. Aşağıdaki beş sebep, Kotter’ın listesinin bugünkü bulut, veri ve yapay zeka projelerindeki karşılığıdır. Her birinin erken bir belirtisi ve uygulanabilir bir düzeltmesi var.

Beş sebep ve erken belirtileri neler?

Sebep	Erken belirti	Düzeltme
İş hedefi yok	Proje bir yazılımın adıyla anılıyor (“CRM projesi”)	Değişecek iş sonucunu tek cümleyle yazın
Veri temeli zayıf	Aynı müşteri üç sistemde üç farklı adla kayıtlı	Bir süreç için veri sahibi ve tanımları belirleyin
Araç dağınıklığı	Her departman kendi aboneliğini alıyor	Ortak araç listesi ve entegrasyon kuralı koyun
Değişim yorgunluğu	Yeni sistemin yanında eski Excel yaşamaya devam ediyor	Nedenini anlatın, eğitimi işin içine yerleştirin
Yanlış ölçüt	Raporlarda yalnız “kurulan modül” sayısı var	Faaliyet yerine sonuç ölçütü seçin

1. Hedef yerine araçla başlamak

En yaygın hata, “ne değişecek” sorusundan önce “hangi yazılımı alalım” sorusunu sormaktır. Proje bir ERP, CRM veya yapay zeka aracının kurulumuna dönüşür. Kurulum bittiğinde iş sonucu aynı kalır.

Düzeltmesi basit ama disiplin ister. Projenin değiştireceği iş sonucunu tek cümleyle yazın: “Teklif hazırlama süresini kısaltmak”, “e-Fatura girişindeki hataları azaltmak”, “müşteri talebinin doğru kişiye ulaşma süresini düşürmek”. Sonra mevcut değeri ölçün. Araç seçimi bu cümleden sonra gelir.

2. Veriyi düzene sokmadan sonuç beklemek

Otomasyon ve yapay zeka, beslendikleri veri kadar iyidir. Aynı müşteri Logo’da bir adla, CRM’de başka bir adla, muhasebenin Excel dosyasında üçüncü bir adla duruyorsa hiçbir rapor güvenilir olmaz.

DAMA International’ın veri yönetimi bilgi birikimini derleyen DAMA-DMBOK’u, veri yönetişimi, veri kalitesi, ana veri ve meta veriyi ayrı disiplinler olarak ele alır. KOBİ ölçeğinde bunun hepsini birden kurmanız gerekmez. Başlangıç için tek bir süreç seçin ve üç şeyi netleştirin: hangi sistem bu verinin asıl kaynağı, kim bu veriden sorumlu ve temel alanların tanımı ne.

3. Her departmanın kendi aracını seçmesi

Pazarlama bir araç, satış başka bir araç, operasyon üçüncü bir araç alır. Her biri kendi başına makul bir karardır. Toplamda ise aynı veri beş yerde tutulur, entegrasyon yoktur, abonelik maliyeti kimse tarafından görülmez ve kişisel verinin nerede işlendiği bilinmez. Bu son nokta, KVKK açısından doğrudan bir risktir.

Çözüm, merkezi bir yasak değil, ortak kurallardır. Onaylı araçların kısa bir listesini tutun. Yeni bir araç için üç soru sorun: mevcut bir araç bu işi yapıyor mu, diğer sistemlerle nasıl konuşacak ve kişisel veri nerede saklanacak?

4. Çalışanları değişime hazırlamamak

Yeni bir sistem, çalışanın alışkanlığını değiştirmesini ister. Neden değiştiğini bilmeyen, yeni aracı kullanmayı yeterince öğrenmemiş ve aynı anda üç başka girişimle uğraşan bir ekip, eski yönteme geri döner. En sık görülen belirti, yeni sistemin yanında “asıl” bilginin tutulduğu bir Excel dosyasının yaşamaya devam etmesidir.

Prosci’nin ADKAR modeli bireysel değişimi beş aşamada tarif eder: farkındalık, istek, bilgi, yetenek ve pekiştirme. Pratikte bu şu anlama gelir: değişikliğin nedenini yöneticiler anlatır, eğitim kurulumdan önce değil işin içinde verilir ve eski yöntem belli bir tarihte gerçekten kapatılır.

5. Sonuç yerine faaliyeti ölçmek

“Kurulan modül sayısı”, “eğitim verilen çalışan sayısı” ve “taşınan kayıt sayısı” ilerleme gibi görünür ama iş sonucu hakkında bir şey söylemez. Yönetim bu raporları bir süre sonra ciddiye almamaya başlar ve proje desteğini kaybeder.

Her girişim için üç katmanlı bir ölçüt zinciri kurun. Faaliyet ölçütü işin yapıldığını gösterir (sistem kuruldu). Sonuç ölçütü davranışın değiştiğini gösterir (teklifler artık sistemde hazırlanıyor). Değer ölçütü iş sonucunun değiştiğini gösterir (teklif hazırlama süresi kısaldı). Raporda üçü birlikte durmalıdır.

Ölçütleri seçerken veriyi kimin, hangi sistemden ve ne sıklıkla çekeceğini de yazın. Elle hazırlanan bir rapor, birkaç ay sonra hazırlanmamaya başlar. Ölçütü mümkünse doğrudan ERP, CRM veya e-Fatura kayıtlarından otomatik çeken basit bir panel, programın ömrü boyunca dürüst bir ayna olur.

Dönüşüm programı nasıl sıralanmalı?

Beş sebebin ortak bir çözümü var: her şeyi aynı anda başlatmamak. Şirket genelinde bir “dijital dönüşüm programı” ilan etmek yerine tek bir iş sonucu ve tek bir süreçle başlayın.

İlk doksan günde o süreç için hedef cümlesini yazın, başlangıç ölçümünü alın, verinin sahibini ve tanımlarını belirleyin, gereken aracı seçin ve ekibi işin içinde eğitin. Doksanıncı günde üç katmanlı ölçüt zincirine bakın. Değer ölçütü değişmişse aynı yöntemi ikinci sürece taşıyın. Değişmemişse sebebini yukarıdaki tablodan arayın.

Bu sıralama yavaş görünür ama aslında daha hızlıdır. Paralel başlatılan on girişim, yönetimin dikkatini ve ekibin enerjisini bölüştürür. Sırayla ilerleyen üç başarılı süreç ise bir sonraki bütçe görüşmesinde en güçlü argümandır. Bir başka faydası da şudur: ilk süreçte öğrenilen veri, entegrasyon ve eğitim dersleri sonraki süreçlerin maliyetini düşürür.

İlk süreci seçerken görünürlüğü yüksek ama riski sınırlı bir iş arayın. Satış ekibinin teklif hazırlığı veya muhasebenin fatura girişi, sonucunu herkesin göreceği ama hatasının telafi edilebileceği tipik başlangıç noktalarıdır.

Corrplus’ta nasıl yaklaşıyoruz?

Dönüşüm projelerine bir yazılım listesiyle değil, değişecek iş sonuçlarının listesiyle başlıyoruz. Keşif aşamasında bu sonuçları, mevcut veri durumunu ve araç envanterini birlikte çıkarıyoruz. Tasarım aşamasında öncelikli süreçleri, veri sahipliğini, KVKK değerlendirmesini ve ölçüt zincirini yazılı hale getiriyoruz. Kurulumu kısa döngülerle yapıyor, gerekirse ekibinize kurumsal yapay zeka eğitimi veriyoruz. Ayrıntılar için dijital dönüşüm danışmanlığı sayfamıza bakabilirsiniz.