ERP Geçişinde Yapılan 7 Hata ve Nasıl Önlenir?

ERP geçişlerini raydan çıkaran şey nadiren yazılımın kendisidir; 30+ ERP dönüşümünde gördüğümüz başarısızlıkların neredeyse tamamı yedi tekrar eden yönetim hatasından çıkar: kapsam şişmesi, kirli veriyle göç, eğitimsiz canlı geçiş, sahipsiz proje, eski süreci yeni sisteme kopyalamak, test fazını kısaltmak ve canlı sonrası desteği plansız bırakmak. Yedisi de öngörülebilir ve önlenebilirdir — bedelini ödemeden önce tanımak şartıyla.

Bu yazı bir korku listesi değil, saha rehberi: her hatayı belirtisiyle, kök nedeniyle ve projelerimizde uyguladığımız önlemiyle anlatıyoruz. Hedef okur, önümüzdeki bir yıl içinde ERP geçişi planlayan KOBİ karar vericisi.

1. Kapsam şişmesi: "Hazır geçmişken şunu da yapalım"

Belirti: Proje ilerledikçe kapsam listesi büyür; "hazır geçmişken bütçe modülü de girsin, bir de sahaya tablet verelim" cümleleri toplantılarda çoğalır. Takvim kayar, ekip yorulur, canlı geçiş tarihi sürekli ötelenir.

Kök neden: Kapsamın proje başında yazılı, önceliklendirilmiş ve imzalı olmaması. Kapsam belgesi yoksa her yeni fikir meşrudur ve hayır demenin dayanağı yoktur.

Önlem: Faz 1'i "işi bugün döndüren çekirdek süreçler" ile sınırlarız: satış, satın alma, stok, finans ve zorunlu e-Dönüşüm belgeleri. Geri kalan her iyi fikir Faz 2 listesine yazılır — reddedilmez, ertelenir. Sahada gördüğümüz desen net: canlıya erken çıkıp Faz 2'yi gerçek kullanım verisiyle şekillendiren şirketler, her şeyi tek fazda isteyenlerden önce bitiriyor. Dar kapsamlı bir KOBİ geçişinin 2-8 haftada canlıya çıkabildiği yerde, şişmiş kapsam aynı şirketi aylarca proje modunda tutar.

2. Veri temizliğini göçün içine saklamak

Belirti: Teklifte "veri göçü" tek satırdır. Proje ortasında stok kartlarının mükerrer, cari bakiyelerin mutabakatsız, birimlerin tutarsız olduğu ortaya çıkar; göç, projenin en uzun kalemine dönüşür.

Kök neden: Veri temizliğinin teknik iş sanılması. Mükerrer stok kartının hangisinin yaşayacağına danışman karar veremez; bu, işletmenin kararıdır ve zaman ister.

Önlem: Veri temizliğini ayrı bir iş paketi olarak, işletme tarafında bir sorumluyla planlarız. İlk adım envanterdir: kaç stok kartı, kaç cari, ne kadar açık belge var, hangi alanlar zorunlu. Kural olarak hareket geçmişinin tamamını değil, bakiyeleri ve açık kalemleri taşırız; eski sisteme salt okunur erişim bir süre korunur. Temiz veri, yeni sistemin ilk gününde güven yaratır — kirli veri ise kullanıcının "eski sistemde doğruydu" diyerek ERP'ye küsmesinin bir numaralı sebebidir.

3. Eğitimsiz (veya yanlış eğitimli) canlı geçiş

Belirti: Canlı geçiş sabahı depo personeli irsaliye kesemez, muhasebe fatura bulamaz; telefonlar danışmana döner, ilk hafta kaosa yazılır.

Kök neden: Eğitimin tek seferlik, sınıf ortamında ve genel müfredatla verilmesi. Ekran başında hiç deneme yapmamış kullanıcı, eğitim almış sayılmaz.

Önlem: Eğitimi role göre böleriz: depocu kendi el terminali akışını, satışçı kendi sipariş ekranını, muhasebe kendi kayıt düzenini çalışır — herkesin her şeyi öğrendiği genel turlar zaman israfıdır. İkinci kural: eğitim gerçek şirket verisiyle, test ortamında yapılır ve sonunda kullanıcı kendi işini baştan sona tek başına yürütür. Üçüncüsü: her departmandan bir anahtar kullanıcı, projenin başından itibaren testin içindedir; canlı geçiş günü ilk soru danışmana değil ona gelir.

4. Sahipsiz proje: "Danışman zaten yapıyor"

Belirti: Toplantılara işletme tarafından her hafta farklı kişiler girer, kararlar askıda kalır, danışmanın soruları günlerce cevapsız bekler. Proje teknik olarak ilerler ama şirket sahiplenmez.

Kök neden: ERP'nin BT projesi sanılması. ERP bir iş projesidir; kararların çoğu (maliyetlendirme yöntemi, onay akışı, iskonto yapısı) iş kararıdır ve danışman bunları şirket adına veremez.

Önlem: Sözleşme aşamasında işletmeden iki rol isteriz: karar verme yetkisi olan bir proje sponsoru (ideali genel müdür veya ortak) ve haftada belirli gününü projeye ayırabilen bir proje sorumlusu. Bu iki isim yoksa projeye başlamayız; çünkü sonun nasıl biteceğini biliyoruz. Kendi ekibinizin mesaisi, hiçbir teklifte satır olarak görünmeyen ama her projede ödenen gerçek bir maliyettir — bunu fiyat yazımızda gizli maliyetler başlığında açtık.

5. Eski süreci yeni sisteme kopyalamak

Belirti: "Eski programda bu ekran şöyleydi, aynısını istiyoruz" cümlesi proje boyunca tekrarlanır; özelleştirme listesi kabarır, standart ürün tanınmaz hale gelir.

Kök neden: ERP geçişinin amaç değil araç olduğunun unutulması. Amaç eski sistemi taklit etmek değil, süreci daha iyi yürütmektir.

Önlem: Her özelleştirme talebine tek soru sorarız: "Bu, iş kuralı mı, alışkanlık mı?" İş kuralıysa (mevzuat, müşteri şartı, gerçek operasyon kısıtı) yapılır. Alışkanlıksa önce standart akış denenir. Yazdığımız her özel kod, sürüm geçişlerinde test edilecek bir bakiye bıraktığından, özelleştirmeyi maliyetli bir istisna gibi yönetiriz — cömert bir vaat gibi değil. SAP Business One gibi olgun bir ürünün standardı, çoğu KOBİ sürecini uyarlamasız karşılar; sahada asıl katma değer, standarda sığmayan yüzde birkaçı doğru seçmektedir.

6. Test fazını takvim baskısıyla kısaltmak

Belirti: Proje gecikmiştir, canlı geçiş tarihi sabittir; makas test fazından çıkar. "Zaten eğitimde denedik" denir, uçtan uca senaryo testi atlanır.

Kök neden: Testin "yazılım hatası arama" sanılması. ERP testinin asıl amacı yazılımı değil, kurgu ve veriyi doğrulamaktır: KDV oranı doğru mu, maliyet doğru hesaplanıyor mu, onay akışı doğru kişiye gidiyor mu.

Önlem: Canlı geçiş öncesi asgari bir uçtan uca senaryo seti koşulur: sipariş→irsaliye→fatura→tahsilat, satın alma→mal kabul→ödeme, üretim varsa reçete→iş emri→maliyet. Her senaryonun beklenen sonucu yazılıdır ve muhasebe kayıtları örneklemle kontrol edilir. Bir gün süren bu disiplin, canlı ilk ayında haftalarca sürecek düzeltmeyi önler. Takvim sıkıştığında test kısaltılmaz; kapsam küçültülür.

7. Canlı geçiş sonrası desteği plansız bırakmak

Belirti: Canlı geçiş "proje bitti" sanılır; danışman ekip çekilir, ilk ay sonu kapanışında sorular birikir, kullanıcılar çözümü kendi geliştirdikleri Excel'lere dönmekte bulur.

Kök neden: Bütçe ve sözleşmenin canlı geçiş gününde bitmesi. Oysa öğrenmenin en yoğun dönemi, gerçek verinin aktığı ilk aylardır.

Önlem: Projeyi ilk ay sonu kapanışı yapılmadan kapatmayız; hiper-bakım dönemi (yakın destek) proje planının parçasıdır. Sonrasında tanımlı müdahale süreli bir teknik destek sözleşmesine geçilir. Excel'e kaçış sinyalini de ciddiye alırız: bir kullanıcı işini sistem dışında görmeye başladıysa sorun kullanıcıda değil, kurguda veya eğitimdedir — erken yakalanırsa yarım günlük düzeltmedir, geç kalınırsa sistemin itibarı gider.

Yedi hatanın ortak paydası

Listeye yukarıdan bakınca desen net: hataların hiçbiri teknik değil, tamamı yönetsel. Yazılım seçimi önemlidir ama belirleyici değildir; aynı ürünle hem takvimi tutturan hem de rafa kaldırılan projeler gördük. Farkı yaratan üç şey — yazılı ve savunulan kapsam, sahiplenilmiş veri ve gerçek yetkili bir proje sponsoru — sözleşme imzalanmadan önce kurulur. Geçiş planlıyorsanız bu üçünü partnerinizle ilk toplantıda konuşun; nasıl bir yol izlediğimizi görmek için danışmanlık yaklaşımımıza bakabilirsiniz.

Hatalar birbirini nasıl tetikler

Bu yedi hata bağımsız değildir; sahada genellikle zincir halinde görülür ve zincirin ilk halkası çoğu zaman dördüncü hatadır. Sahipsiz projede kapsamı savunacak kimse yoktur, kapsam şişer (1). Şişen kapsam takvimi sıkıştırır, makas test fazından çıkar (6). Test edilmeyen kurguyla eğitim yüzeyselleşir (3) ve canlı geçiş sancılı olur. Sancılı geçişin ardından destek bütçesi de bitmiştir (7); kullanıcı Excel'e döner ve proje kâğıt üstünde "tamamlanmış", fiilen terk edilmiş olur.

Zinciri kırmanın en ucuz yeri en başıdır: yetkili bir sponsor ve yazılı kapsam, kalan beş hatanın her birine karşı doğal bir fren oluşturur. Bu yüzden proje sağlığını ölçerken ilk baktığımız şey Gantt şeması değil, son üç toplantının katılımcı listesidir.

Geçiş öncesi hazırlık kontrol listesi

Sözleşme imzalamadan önce kendi tarafınızda netleşmesi gerekenler:

1. Proje sponsoru (karar yetkili) ve proje sorumlusu isim olarak belli mi?
2. Faz 1 kapsamı tek sayfada yazılı mı; "Faz 2'ye ertelenenler" listesi var mı?
3. Anahtar kullanıcılar departman bazında seçildi mi; haftalık mesai payı yöneticileriyle konuşuldu mu?
4. Veri envanteri çıktı mı: kaç stok kartı, kaç cari, ne kadar açık belge, hangi kaynaklarda?
5. Veri temizliği için işletme tarafında bir sorumlu ve takvim var mı?
6. Canlı geçiş için dönem tercihi yapıldı mı? (Yoğun sezon ve dönem kapanışından uzak bir tarih.)
7. Uçtan uca test senaryoları — sipariş→tahsilat, satın alma→ödeme, üretim→maliyet — yazılı mı?
8. Canlı sonrası destek modeli (hiper-bakım + destek sözleşmesi) teklifte satır olarak var mı?
9. Özelleştirme talepleri "iş kuralı mı, alışkanlık mı" süzgecinden geçirildi mi?
10. Eski sisteme salt okunur erişimin ne kadar süre korunacağı kararlaştırıldı mı?

Bu listenin amacı bürokrasi değil, pazarlık gücü: on maddesi hazır bir işletme, partner tekliflerini gerçekçi kapsamla karşılaştırabilir ve proje boyunca yönetilen değil yöneten taraf olur.

Kırmızı bayraklar: proje yoldayken nelere bakmalı

Hazırlık iyi yapılmış olsa da proje sırasında sağlığı izlemek gerekir. Yönetici olarak şu sinyalleri gördüğünüzde müdahale zamanı gelmiştir:

• Haftalık proje toplantıları iptal edilmeye ya da vekillerle yapılmaya başladı
• Danışmanın açık soru listesi iki haftadır aynı maddelerle duruyor
• "Onu canlıdan sonra hallederiz" cümlesi test ve veri konularında duyulmaya başladı
• Anahtar kullanıcılar teste zaman ayıramıyor, test tutanakları imzasız birikiyor
• Özelleştirme listesi her toplantıda büyüyor ama hiçbir madde kapanmıyor
• Canlı geçiş tarihi ikinci kez ötelendi ve yeni tarihin gerekçesi yazılı değil

Bu sinyallerin panzehiri aynıdır: sponsorun masaya oturup üç soruyu sorması — neredeyiz, tıkanma nerede, kararı kim bekliyor. Projeler büyük patlamalarla değil, cevapsız kalan küçük soruların birikmesiyle raydan çıkar.

Sık sorulan sorular

ERP geçişi tipik olarak ne kadar sürer?

Dar kapsamlı bir KOBİ devreye alması tipik olarak 2-8 hafta; çok lokasyonlu, geniş kapsamlı kurumsal projeler 8-12 aya uzayabilir. Süreyi en çok oynatan üç değişken kapsam, veri temizliği ve işletme tarafının projeye ayırabildiği mesaidir.

En kritik hata hangisi?

Tek birini seçmek gerekirse sahipsiz proje. Diğer altı hata, yetkili ve ilgili bir proje sponsoru varsa yolda yakalanıp düzeltilebilir; sponsor yoksa hataları görecek göz de, düzeltecek irade de yoktur.

Eski sistemle yeni sistemi bir süre paralel çalıştırmak doğru mu?

Çift veri girişi gerektiren tam paralel kullanım genellikle tavsiye etmediğimiz bir yöntemdir; ekip iki sistemi de yarım besler ve karşılaştırma anlamsızlaşır. Doğru desen, eski sisteme salt okunur erişimi koruyup işlemi tek sistemde — yenisinde — yürütmektir.

Bu hatalar küçük şirketlerde de geçerli mi?

Evet, hatta daha sert yaşanır; çünkü küçük şirkette proje sorumlusu genellikle asıl işinin yanında bu görevi taşır. Kapsamı dar tutmak ve anahtar kullanıcıyı erken belirlemek, küçük yapılarda daha da önemlidir; KOBİ ERP sayfasında bu ölçeğe özel yaklaşımımızı anlattık.

Proje raydan çıktıysa kurtarmak mümkün mü?

Çoğu zaman evet; tıkanmış projeler nadiren teknik olarak ölüdür, genellikle karar ve sahiplik boşluğunda asılı kalmıştır. Kurtarma; mevcut durumun dürüst bir denetimiyle başlar, kapsam yeniden çizilir ve proje küçültülmüş, kazanılabilir bir ilk hedefle yeniden başlatılır — güven, büyük planla değil ilk küçük başarıyla geri gelir.