ERP projesi neden başarısız olur? Sekiz sebep, erken belirtileri ve önlemi

Proje altı ay önce başladı, iki modül açıldı, ekip hâlâ Excel’de çalışıyor. Satıcı “kapsam dışı” diyor, muhasebe “eski programdan daha yavaş” diyor, yönetim “biz bunu niye aldık” diye soruyor. ERP projelerinin başarısızlığı genelde büyük bir çöküş değil, böyle sessiz bir sürüklenmedir.

Sektör anketleri ERP projelerinde yüksek başarısızlık oranları verir; oranlar ölçütlere göre değiştiği için burada bir yüzde yazmıyoruz. Yazdığımız şey, kurduğumuz ve devraldığımız projelerde tekrar tekrar gördüğümüz sekiz sebep, her birinin erken belirtisi ve önlemi.

Sekiz sebep, belirtisi ve önlemi

Sebep	Erken belirti	Önlem
Belirsiz kapsam	Teklifte modül adı var, ekran ve işlem listesi yok	Kapsamı ekran ve işlem düzeyinde yazın, ilk fazı dar tutun
Sahipsiz proje	Kararı veren kişi belli değil, toplantıya her seferinde başkası geliyor	Tek proje sahibi ve haftalık 30 dakikalık karar toplantısı
Kirli veri	Mükerrer cari ve tutmayan bakiye için "sonra düzeltiriz" deniyor	Göçten önce temizlik, yalnız açık kayıtları taşıyın
Tek seferde geçiş	Altı modül aynı hafta açılacak, eğitim tek günde	Tek süreç, tek ekip; iki hafta sorunsuz çalışmadan ikinci modül yok
Süreci sisteme zorlamak	"Paket böyle yapıyor" ya da tersi: çekirdek yeniden yazılıyor	Uyuşmayan süreci çekirdeğe değil yanına yazın
Kabul kriteri yok	"Çalışır durumda teslim edilir" dışında ölçüt yok	Kriteri kullanacak kişi yazsın, ödeme kapıları kritere bağlansın
Ekip direnci	Eğitimden üç hafta sonra kayıt hâlâ kâğıtta veya Excel'de	En çok acıtan işten başlayın, ekranı ekibe çizdirin
Tedarikçi bağımlılığı	Kaynak kod ve doküman satıcıda, çıkış maddesi sözleşmede yok	Kod teslimi ve çıkış maddesi imza gününde yazılır

1. Belirsiz kapsam

“Stok modülü dahildir” satırı bir kapsam tanımı değildir. Aynı satır bir firmada yalnız giriş-çıkış kaydını, diğerinde sayım, transfer, lot takibi ve fark raporunu kapsar. Proje başladığında iki taraf da kendi tanımını doğru sanır; üçüncü ayda “bu kapsamda değildi” listesi çıkar.

Önlem imzadan önce alınır: her modülün altında ekran ve işlem listesi, her işlemin karşısında onu kimin kullanacağı. Teklifi bu düzeye indirmenin yolu yazılım firması seçimi ve teklif okuma yazısında, şartnamenin kendisi yazılım şartnamesi nasıl yazılır rehberinde.

2. Sahipsiz proje

Satıcı tarafında proje yöneticisi vardır; şirket tarafında çoğu zaman yoktur. Kararı kimin verdiği belli olmayınca her toplantıda bir önceki karar yeniden açılır, satıcı iki ayrı kişiden iki ayrı talimat alır ve ikisini de yapmamayı seçer.

Önlem: tek bir proje sahibi, haftalık 30 dakikalık karar toplantısı ve yazılı karar listesi. Sahibin genel müdür olması gerekmez; süreci bilen ve karar yetkisi verilmiş biri olması gerekir.

3. Kirli veri

Eski sistemdeki mükerrer cariler, boş stok kartları ve tutmayan bakiyeler yeni sisteme olduğu gibi taşınırsa yeni sistem ilk günden yanlış rapor üretir. Ekip yanlış raporu görür, “sistem hatalı” der ve Excel’e döner. Veri temizliği projede en çok ertelenen ve en pahalıya patlayan iştir.

Önlem: göçten önce temizlik ve yalnız açık kayıtların taşınması. Aktif cari, açık sipariş, mevcut stok ve aktif personel taşınır; kapanmış yıllar arşivde kalır. Sıra Excel’den sisteme geçiş rehberinde.

4. Tek seferde geçiş

Altı modülü aynı hafta açmak ekibe altı yeni alışkanlığı birden dayatmaktır. Hata çıktığında hangi modülden geldiği anlaşılmaz, eğitim tek günde yapılır ve unutulur, veri göçü altı tabloda aynı anda temizlenemez.

Önlem: tek süreç, tek ekip, tek hat. İlk süreç iki hafta sorunsuz çalışmadan ikinci modül açılmaz. Bu sıra daha yavaş görünür; pratikte projeyi daha erken bitirir, çünkü hiçbir modül geri alınmaz.

5. Süreci sisteme zorlamak, ya da sistemi süreçle bozmak

İki uç da başarısızlık üretir. Birinci uçta paket “böyle yapıyor” diye şirketin işleyen süreci pakete uydurulmaya çalışılır; ekip paketin yapmadığı işi Excel’de yapmaya devam eder. İkinci uçta paketin çekirdeği şirkete göre yeniden yazılır; ilk sürüm yükseltmesinde özelleştirmeler kırılır ve şirket eski sürümde kalır.

Önlem: süreç paketle uyuşmuyorsa çekirdeği bozmak yerine yanına yazın. Muhasebe ve e-belge pakette kalır, süreç özel sistemde yürür, ikisi API ile konuşur. Yükseltme testi ve karar tablosu ERP özelleştirme riskli mi yazısında; kurgunun adımları paketten özel sisteme geçiş sayfasında; paketlerin entegrasyon farkı Logo, Mikro, Netsis ve DİA karşılaştırmasında.

6. Kabul kriteri yok

“Bittiğini kim, neye bakarak söyleyecek” sorusunun cevabı yazılı değilse teslim tartışmaya açılır. Satıcı ekranın açıldığını gösterir, şirket işin yürümediğini söyler ve ikisi de kendince haklıdır.

Önlem: kriteri kullanacak kişi yazar. “Depo sorumlusu 50 kalemlik sayım fişini girer, fark raporunu ekrandan alır, üç tekrarda hata çıkmaz” gibi. Ödeme kapıları takvime değil kritere bağlanır. Beş aşamalı kabul listesi yazılım projesi nasıl teslim alınır yazısında.

7. Ekip direnci

Sistem açıldı, eğitim yapıldı, üç hafta sonra depo hâlâ kendi Excel’ine yazıyor. Direnç bir tutum değil, bir hesaptır: yeni ekran işi uzatıyorsa direnç mantıklı davranıştır.

Önlem beş adımlıdır: en çok acıtan işten başlamak, ekranı kullanacak kişiye çizdirmek, kademeli devreye almak, değeri ilk hafta görünür kılmak ve Excel’i yasaklamak yerine gereksiz kılmak. Ayrıntı yeni sisteme ekip direnci yazısında.

8. Tedarikçi bağımlılığı

Proje ilerledikçe pazarlık gücü satıcıya geçer: kaynak kod satıcıda, doküman yok, çıkış maddesi sözleşmede yok. İlişki bozulduğunda sistem başka bir ekibe devredilemez; şirket ya kötü ilişkiyi sürdürür ya sıfırdan başlar.

Önlem imza gününde alınır: kaynak kod teslimi, dokümantasyon, veri dışa aktarım formatı ve üçüncü bir ekibin devralmasının engellenmeyeceği maddesi. Bağımlılığın nasıl oluştuğu kod sahipliği ve lock-in yazısında.

Sürüklenen projeyi kurtarmak

1. Kapsamı durdurun. Açık talep listesini kapatın, en çok acıtan tek süreci seçin.
2. O süreç için kabul kriterini kullanıcıya yazdırın. Ölçülebilir cümle, üç tekrar, hata yok.
3. İki haftalık çift kayıt dönemiyle canlıya alın. Eski tablo açık kalır, haftalık mutabakat tutunca yazmaya kapatılır.

Üç adım bir ayda bir süreci gerçekten çalışır hâle getirir; geri kalan modüller aynı sırayla eklenir. Kaynak kod ve veri sizdeyse bu adımları başka bir ekiple de atabilirsiniz.

Bütçe ve süre

Tek süreçle başlayan kurgu 2-4 haftada, 80.000 - 150.000 ₺ bandında canlıya alınır; 4-6 modüllü kurumsal sistem 4-8 haftada, 200.000 - 400.000 ₺ bandındadır. Her fazın kapsamı, çıktısı ve bedeli önceden yazılır, bir sonraki faza siz karar verirsiniz. Lisans ömür boyudur, kullanıcı sayısı sınırsızdır, kaynak kod teslim edilir. Bantlar fiyat sayfasında; süreyi uzatan faktörler ERP kurulumu ne kadar sürer yazısında.

---

İlgili Bütçe Araçları ve Karşılaştırma Rehberleri

• Paket vs Özel 5 Yıllık TCO Hesaplayıcı — Kiralık SaaS lisansı ile özel yazılımın 5 yıllık maliyetini kıyaslayın.
• Yazılım Bütçe ve Süre Tahmincisi — İhtiyacınız olan modülleri seçerek bütçe ve teslim bandınızı görün.
• ERP Fiyat Listesi 2026 Karşılaştırması — Türkiye kurumsal ERP lisans ve bakım bedelleri.
• Özel Yazılım Teknik Şartnamesi (RFP) Rehberi — Bütçe aşımını önleyen şartname hazırlama kılavuzu.

Sıkça sorulan sorular

ERP projesinin başarısız olduğunu nasıl anlarım?

Üç belirtiyle: canlıya geçişten üç hafta sonra sistemin yanında yaşayan Excel dosyası sayısı artıyorsa, yönetim raporu hâlâ eski tablodan alınıyorsa ve satıcıyla yazışmaların çoğu 'bu kapsamda değildi' cümlesini içeriyorsa proje sürükleniyordur. Yazılımın açılması başarı değildir; kaydın sistemde doğması başarıdır.

En sık görülen başarısızlık sebebi hangisi?

Belirsiz kapsam. Modül adıyla yazılmış teklif, ekran ve işlem listesi olmadan başlayan proje üçüncü ayda ek talep listesine dönüşür. Kapsamı ekran ve işlem düzeyinde yazmak, kabul kriterini kullanıcıya yazdırmak ve ilk fazı dar tutmak bu sebebi büyük ölçüde ortadan kaldırır.

Tüm modülleri aynı anda açmak neden sorun?

Ekip altı yeni alışkanlığı aynı hafta öğrenemez, veri göçü altı tabloda aynı anda temizlenemez, hata çıktığında hangi modülden geldiği anlaşılmaz. Tek süreç, tek ekip ile başlayıp iki hafta sorunsuz çalıştıktan sonra ikinci modüle geçmek daha yavaş görünür ama daha erken biter.

Veri göçü projeyi nasıl batırır?

Mükerrer cari, eksik stok kartı ve tutarsız bakiye yeni sisteme taşındığında sistem ilk günden yanlış rapor üretir ve ekip güvenini kaybeder. Açık kayıtları taşıyıp kapanmış geçmişi arşivde bırakmak ve göç öncesi mükerrerleri temizlemek bu riski küçültür.

Başarısız bir ERP projesi kurtarılabilir mi?

Çoğu zaman evet, üç adımla: kapsamı durdurup en çok acıtan tek süreci seçmek, o süreç için kabul kriterini kullanıcıya yazdırmak ve iki haftalık çift kayıt dönemiyle o süreci canlıya almak. Kaynak kod ve veri sizdeyse başka bir ekiple devam etmek de mümkündür.

Paket ERP mi özel sistem mi daha çok başarısız olur?

Sebepler ikisinde de aynıdır; fark, sebebin nerede ortaya çıktığıdır. Pakette süreç sisteme zorlanır ve aşırı özelleştirme sürüm yükseltmesini kırar; özel sistemde kapsam belirsizliği ve kabul kriteri yokluğu projeyi uzatır. Her iki durumda da ilk fazı dar tutmak ve kabul kriterini yazmak riski düşürür.

İlgili rehberler

• Excel'den kurumsal yazılıma geçiş: Tablo karmaşasından güvenli kurtulma rehberi
• Hibrit model: paketi bırakmadan özel sisteme geçiş
• Excel'den sisteme geçiş: nereden başlanır?

Hizmet sayfası: Paketten özel sisteme geçiş