Dijital Dönüşüm Projeleri Neden Başarısız Olur? Sebepler ve Önlemler
Dijital dönüşüm projeleri neden başarısız olur? Hedefsiz başlangıç, veri, entegrasyon ve saha sahiplenmesi sorunlarının erken işaretleri ve önlemleri.
Yazar: Abdulaziz Akyol · Kurucu ve CEO, CX Teknoloji
Dijital dönüşüm projeleri çoğunlukla teknoloji yüzünden değil, yanlış tanımlanmış hedef, ölçülmemiş başlangıç durumu, hafife alınan veri ve entegrasyon işi ve sahanın sahiplenmemesi yüzünden başarısız olur. Bu sebeplerin her birinin projenin ilk haftalarında görülebilen erken işaretleri vardır; işaretler fark edildiğinde alınacak önlemler de bellidir.
Sahada sistem kuran bir ekip olarak, bize gelen projelerin bir kısmı daha önce başlatılıp yarım kalmış işlerin ikinci denemesidir. Bir üretim şirketinde lisansı alınmış ama sahada kullanılmayan bir MES modülü, bir lojistik firmasında kimsenin açmadığı bir yönetim panosu, bir kimya tesisinde pilotu bitmiş ama hiç yaygınlaşmamış bir kamera projesi. Bu yarım kalmış projelerin hikâyeleri birbirine çok benzer. Aşağıda en sık karşılaştığımız sebepleri, her birinin erken işaretini ve önlemini sıraladım. Yeni bir projeye başlamadan önce bu listeyi bir kontrol aracı olarak kullanabilirsiniz; projeyi baştan birlikte kurgulamak isterseniz danışmanlık hizmetimizin çalışma modeli de bu tecrübeden çıktı.
Sebep 1: Hedef bir teknoloji olarak tanımlanıyor
Proje adı “ERP'ye geçiş”, “yapay zekâ projesi” ya da “fabrikayı dijitalleştirme” olduğunda başarısızlığın tohumu atılmış olur. Bu ifadeler bir araç tarif eder; hangi iş sonucunun değişeceğini söylemez. Proje bittiğinde başarılı olup olmadığına karar verecek bir ölçüt olmadığı için tartışma, sistemin kurulup kurulmadığına kayar. Sistem kurulmuştur, ama sevkiyat gecikmeleri aynıdır.
Önlem basittir ama disiplin ister: her proje bir iş cümlesiyle başlamalıdır. “Sipariş teslim tarihini müşteriye aynı gün içinde söyleyebilmek”, “vardiya sonu üretim raporunu elle birleştirmeyi bırakmak”, “fire sebebini hat bazında görmek” gibi. Teknoloji seçimi bu cümleden sonra gelir.
Sebep 2: Başlangıç durumu ölçülmüyor
Bir iyileşmeden söz edebilmek için önce mevcut durumun ölçülmesi gerekir. Pek çok projede bu adım atlanır, çünkü herkes sorunun büyüklüğünü bildiğini düşünür. Proje sonunda yönetim kurulu “ne kazandık” diye sorduğunda elde karşılaştırılacak bir sayı yoktur ve sonuç, kişilerin izlenimine kalır.
Önlem olarak proje başlamadan önce iki üç gösterge seçilip birkaç hafta boyunca mevcut yöntemle ölçülmelidir. Ölçüm kusurlu olabilir; önemli olan aynı yöntemin proje sonrasında da kullanılmasıdır. Pilotun bu mantıkla nasıl kurgulanacağını doğru pilot nasıl tasarlanır yazısında ayrıntılı anlattık.
Sebep 3: Veri kalitesi çok geç fark ediliyor
Yeni bir sistem, beslendiği veri kadar iyidir. Malzeme kodlarının iki farklı listede iki farklı yazıldığı, birimlerin bir yerde kilogram bir yerde adet tutulduğu, reçetelerin güncellenmediği bir ortamda özenle tasarlanmış bir pano bile yanlış sayı gösterir. Sorun genellikle canlıya geçişten birkaç hafta sonra, kullanıcılar ekrandaki sayıya güvenmemeye başladığında ortaya çıkar.
Önlem, ana veri temizliğini projenin bir alt işi değil, ilk iş paketi olarak planlamaktır. Hangi verinin hangi sistemde tek doğru kaynak olacağı, kimin güncelleyeceği ve hatalı kaydın nasıl düzeltileceği proje başında yazılı hâle getirilmelidir. Veri sahipliği ve saklama kuralları için veri yönetişimi yazısı iyi bir başlangıç noktasıdır.
Sebep 4: Entegrasyon işi hafife alınıyor
Tekliflerde yazılımın lisansı ve kurulumu ayrıntılı yazılır, mevcut sistemlerle konuşması ise tek satırla geçilir. Oysa ERP, MES, SCADA ve eski Excel tabanlı araçlar arasındaki veri akışı çoğu projede işin en uzun ve en riskli kısmıdır. Entegrasyon geciktiğinde kullanıcılar aynı veriyi iki sisteme elle girmeye başlar ve yeni sistem iş yükünü azaltmak yerine artırır.
Önlem, entegrasyonu ayrı bir iş paketi olarak tanımlamak ve keşif aşamasında her arayüzün kaynağını, sıklığını ve hata senaryosunu çıkarmaktır. Keşifte her arayüz için şu dört soru cevaplanmalıdır: veri hangi sistemde doğuyor, karşı tarafa ne sıklıkla gitmeli, aktarım başarısız olursa kim ve nasıl haberdar olacak, iki sistem arasındaki fark hangi raporla mutabık kılınacak. Bu sorulara cevap verilemeyen arayüz, takvimdeki en büyük belirsizliktir.
Sebep 5: Saha projeyi sahiplenmiyor
Projeyi yönetim ve BT tasarlar, sistemi ise vardiya şefi, operatör, depo sorumlusu kullanır. Kullanıcılar tasarıma dahil edilmediğinde sistem onların iş akışına uymaz; ekran fazla alan ister, tablet yanlış yerde durur, alarm gereksiz yere çalar. Sonuçta sistem resmî olarak kullanılır, gerçek iş yine defterde ya da WhatsApp grubunda yürür.
Önlem olarak her sahada bir anahtar kullanıcı belirlenmeli, tasarım ekranları pilot öncesinde bu kişilerle denenmeli ve ilk haftalarda sahada fiilen bulunulmalıdır. Bu konunun tamamını dijital dönüşümde değişim yönetimi yazısına ayırdık.
Sebep 6: Pilot bitiyor, yaygınlaştırma başlamıyor
Pilot başarılı olur, sunum yapılır, herkes memnundur ve proje orada kalır. Bunun arkasında genellikle üç şey vardır: pilotun başarı ölçütü baştan yazılmamıştır, yaygınlaştırma bütçesi ayrılmamıştır ya da pilot, diğer hatlarda tekrarlanamayacak özel koşullarda kurulmuştur. Pilotun hangi kararla biteceği (yaygınlaştır, düzelt ve tekrar dene, durdur) pilot başlamadan yazılmalıdır. Ölçeğe geçişi pilottan ölçeğe yazısında ele alıyoruz.
Bu altı sebebin yanında iki sebep daha sık görülür. Birincisi karar sahibinin olmamasıdır: proje BT'ye verilmiştir, üretim ise sonucu sahiplenmez; her sorun iki bölüm arasında gidip gelir ve kararlar haftalarca bekler. İkincisi işletme maliyetinin unutulmasıdır. Kurulum bütçesi onaylanır, ama lisans yenileme, destek sözleşmesi, donanım değişimi ve yeni çalışanların eğitimi hiçbir bütçede yer almaz. Sistem ilk yıl çalışır, ikinci yıl destek kesildiğinde yavaş yavaş terk edilir.
Erken işaretler ve önlemler tablosu
Aşağıdaki tablo, yukarıdaki sebeplere iki ek sebep daha ekleyerek bir proje yöneticisinin aylık gözden geçirmede kullanabileceği biçimde toplar.
| Sebep | Erken işaret | Önlem |
|---|---|---|
| Hedef teknoloji olarak tanımlı | Proje belgesinde iş ölçütü yok; toplantılar ekran ve modül üzerine dönüyor. | Her projeye tek cümlelik iş hedefi ve iki üç ölçüt yazın. |
| Başlangıç ölçülmemiş | Kazanım sorusuna “herkes biliyor” cevabı veriliyor. | Proje öncesinde mevcut yöntemle birkaç hafta ölçüm yapın. |
| Veri kalitesi | Test sırasında kullanıcılar ekrandaki sayıyı Excel'le kontrol ediyor. | Ana veri temizliğini ilk iş paketi yapın; veri sahiplerini atayın. |
| Entegrasyon | Teklifte arayüzler tek satır; aynı veri iki sisteme elle giriliyor. | Her arayüzü kaynak, sıklık ve hata senaryosuyla ayrı tanımlayın. |
| Saha sahiplenmiyor | Eğitime katılım düşük; paralel kâğıt kayıt sürüyor. | Anahtar kullanıcı atayın, ilk haftalarda sahada bulunun. |
| Pilot kısır döngüsü | Pilot uzatılıyor, karar toplantısı erteleniyor. | Pilot öncesinde karar ölçütünü ve yaygınlaştırma bütçesini yazın. |
| Karar sahibi yok | Sorunlar BT ile üretim arasında gidip geliyor. | İş tarafından bir proje sahibi atayın; BT destekleyen taraf olsun. |
| İşletme maliyeti unutulmuş | Canlıya geçişten sonra destek, lisans ve donanım yenileme için bütçe yok. | Bütçeyi kurulum ve en az birkaç yıllık işletme maliyeti olarak birlikte onaylayın. |
Projeye başlamadan önce yönetimin soracağı sorular
Yukarıdaki sebeplerin neredeyse hepsi proje onaylanmadan önce sorulacak birkaç soruyla görünür hâle gelir. Yönetim kurulunda ya da bütçe toplantısında şu soruları cevapsız bırakan bir projeyi bekletmek, sonradan yarım kalmasından daha ucuzdur:
- Bu proje bittiğinde hangi iş sonucu değişmiş olacak ve bunu hangi göstergeyle ölçeceğiz?
- Bu göstergenin bugünkü değerini biliyor muyuz? Bilmiyorsak ne zaman ve nasıl ölçeceğiz?
- Projenin iş tarafındaki sahibi kim? BT ve tedarikçi ona mı raporlayacak?
- Hangi sistemlerle veri alışverişi gerekecek ve bu arayüzler teklifte ayrı kalem olarak var mı?
- Sahada sistemi kullanacak kişiler tasarıma ne zaman dahil olacak?
- Pilot hangi ölçütle başarılı sayılacak ve başarılı olursa yaygınlaştırma bütçesi nereden gelecek?
- Sistem canlıya geçtikten sonra bakımını, güncellemesini ve kullanıcı desteğini kim yapacak?
Bu soruların bir kısmı stratejik düzeydedir ve yönetim kurulunun gündemine taşınmalıdır. Soruların hepsine ilk toplantıda kusursuz cevap beklemek gerçekçi değildir. Ama cevabın kimde olduğu ve ne zamana kadar netleşeceği belli olmalıdır; bu bile projeyi sahipsiz başlamaktan kurtarır.
Raporu çizen ekip sistemi de kurmalı mı?
Yarım kalmış projelerde gördüğüm ortak bir durum, stratejiyi yazan ekip ile sistemi kuran ekibin farklı olmasıdır. Strateji raporu teknik olarak uygulanabilirliği sınanmadan yazılır; uygulayıcı ise o rapordaki varsayımların neden konduğunu bilmez. Arada kalan boşluk proje sahibine düşer. Bizim çalışma modelimizde keşif raporunu, yol haritasını, pilotu ve devir planını aynı ekip üstlenir. Bu, her şeyi tek bir firmaya bırakmak anlamına gelmez; ama hangi danışmanla çalışırsanız çalışın, önerdiği yol haritasının sahada kim tarafından ve nasıl uygulanacağını sormanızı öneririm. Firma seçimindeki diğer sorular için danışmanlık firması nasıl seçilir yazısını hazırladık.
Projenizin bu sebeplerden hangilerine açık olduğunu görmek için kısa bir başlangıç noktası arıyorsanız, ücretsiz dijital olgunluk ön değerlendirmesi mevcut durumunuzu boyut boyut ortaya koyar.
Sık sorulan sorular
Dijital dönüşüm projelerinin başarısız olmasının en yaygın sebebi nedir?
Sahada en sık gördüğümüz sebep, projenin bir iş sonucu yerine bir teknoloji olarak tanımlanmasıdır. Hedef “sistemi kurmak” olduğunda proje kurulumla biter ve iş sonucunun değişip değişmediği ölçülmez. Her projeye tek cümlelik bir iş hedefi ve ölçütü yazmak bu riski büyük ölçüde azaltır.
Başarısız bir projeyi kurtarmak mümkün mü?
Çoğu durumda mümkündür, ancak önce durumun dürüstçe teşhis edilmesi gerekir. Sorun veri kalitesi, entegrasyon ya da sahada kullanılmama olabilir ve her birinin çözümü farklıdır. Kurtarma çalışması genellikle hedefin yeniden yazılması ve başlangıç ölçümünün yapılmasıyla başlar.
Pilot projeler neden yaygınlaştırılamıyor?
Çünkü pilotun başarı ölçütü ve yaygınlaştırma bütçesi çoğunlukla pilot başlamadan belirlenmez. Pilot ayrıca diğer hatlarda tekrarlanamayacak özel koşullarda kurulmuş olabilir. Pilot öncesinde karar ölçütünü ve yaygınlaştırma koşullarını yazılı hâle getirmek bu döngüyü kırar.
Dijital dönüşüm projesinin sahibi BT mi olmalı?
Projenin sahibi değişecek iş sonucundan sorumlu iş birimi olmalıdır. BT altyapı, güvenlik ve entegrasyon tarafında vazgeçilmez bir destekçidir, ancak üretim, satış ya da lojistik sonucunun sahibi değildir. Sahiplik BT'de kaldığında sorunlar bölümler arasında gidip gelir.
Proje bütçesinde en sık unutulan kalem hangisidir?
En sık unutulan kalem canlıya geçiş sonrasındaki işletme maliyetidir. Lisans yenileme, destek, donanım değişimi, model ya da yazılım güncellemesi ve kullanıcı eğitimi kurulum bütçesine dahil edilmez. Bütçeyi kurulum ve birkaç yıllık işletme maliyeti olarak birlikte onaylamak sürprizleri önler.