Why ERP Implementations Fail - and Why an API Changes the Odds

Seven failure patterns that recur across ERP projects, the countermeasure for each, and a factual account of which of them an API-first accounting core takes off the table.

ERP projelerinin başarısız olmasının nedeni projeden projeye tekrarlanan kısa bir listeden ibarettir: sürekli büyüyen kapsam, standart süreci ortadan kaldıran özelleştirmeler, kimsenin temizlemediği veriler, karar verme yetkisine sahip kimsenin bulunmaması, geri alınamayan tek bir canlıya geçiş (cutover) hafta sonu, tek bir sağlayıcının yol haritasına bağımlılık ve canlıya geçiş sonrasında fark edilen vergi ya da beyanname gereklilikleri. Bunların hiçbiri dar anlamda bir teknoloji sorunu değildir. Her biri, ilk ekran yapılandırılmadan önce alınan veya alınmayan birer karardır.

Bu makale, bu nedenleri ve bunların yerine ne yapılması gerektiğini tek tek ele almaktadır. Ardından spesifik ve sınırlı bir sav ortaya koymaktadır: Sistemin muhasebe çekirdeği, kendi yazılımınızın entegre olduğu bir API olduğunda, bu nedenlerin birçoğu riskleri hafifletilmekle kalmaz, projeden tamamen çıkarılır çünkü ait oldukları iş artık var olmamaktadır.

Tekrarlanan nedenler

1. Kararlaştırılmaktan ziyade sonradan keşfedilen kapsam

"Finans ve stok yönetimi" için imzalanan bir proje; satın alma onayları, proje maliyetlendirmesi, bir müşteri portalı ve bir raporlama katmanını bünyesine katar çünkü bunların her biri "neredeyse aynı şeydir". Bütçe ve tarih ise orijinal kapsama göre belirlenmiştir.

Bunun yerine: Kabul kriterleri listesini önce yazın. Kapanmış bir ay için yeni sistemden doğru şekilde alınması gereken belgeler, raporlar ve beyannameler listesi projenin kapsamıdır. Bu listede yer almayan her şey ikinci bir projedir.

2. Eski sistemi yeniden yaratan özelleştirmeler

Bir ERP projesindeki en pahalı cümle "yeni sistem bunu şu anda yaptığımız şekilde yapmak zorunda" cümlesidir. Her özelleştirmenin tanımlanması, geliştirilmesi, test edilmesi, belgelendirilmesi ve her yükseltmede (upgrade) yeniden test edilmesi gerekir. Eski ekranları kopyalayarak başlayan projeler, kopyalama işlemini genellikle asla bitiremez.

Bunun yerine: İşletmenin gerçekten farklı olmadığı her akış için sağlayıcının standart sürecini kabul edin ve her birinin gerekçesiyle birlikte istisnaların yazılı bir listesini tutun. Liste uzunsa, yapılandırma değil ürün yanlıştır.

3. Kimsenin temizlemediği veriler

Mükerrer iş ortakları, birimsiz kalemler, kullanılmayan yüzlerce koda sahip bir hesap planı, yıllar önce kapatılmış ancak mutabakatı yapılmamış açık faturalar. Veri aktarımı (migration) temizlik çalışmalarından daha hızlı gerçekleşemez ve bu temizlik aynı zamanda ay sonu kapanışı yapmak zorunda olan kişiler tarafından yürütülür.

Bunun yerine: Proje başlamadan önce temizliği yapın. Tam geçmişi mi yoksa açılış bakiyeleri artı açık kalemleri mi taşıyacağınıza karar verin. Yeni sisteme tek bir satır bile yazmadan önce, veri aktarım paketini hatasız çalışana kadar doğrulayın.

4. Süreç sahibinin olmaması

Her karar bir yönlendirme komitesine gittiğinde, kararlar haftalar sürer. Satıştan tahsile sürecinin uçtan uca sahibi kimse almadığında, satış modülü ve alacaklar modülü farklı varsayımlara sahip farklı kişiler tarafından yapılandırılır.

Bunun yerine: Karar verme yetkisine sahip, süreç başına bir yetkili belirleyin ve hem sağlayıcının hem de ekibin üzerinde çalıştığı haftalık bir karar günlüğü tutun.

5. Geri dönüşü olmayan büyük patlama tarzı canlıya geçiş (Big-bang cutover)

Her varlığın ve her modülün tek bir hafta sonu devreye alınması, tüm riskleri tek bir noktada toplar. İlk ay sonu kapanışı başarısız olursa, geri dönülecek eski bir sistem veya ders çıkarılacak kısmi bir pilot uygulama yoktur.

Bunun yerine: Mutabakatı yapılmış kapanış mizanı ile bir dönem sınırında canlıya geçin, eski sistemi okunabilir tutun ve birden fazla şirket/kurum varsa önce biriyle canlıya geçin.

6. Üçüncü yılda ortaya çıkan sağlayıcı bağımlılığı (Vendor lock-in)

Profesyonel hizmetler alınmasını gerektiren veri dışarı aktarımları, yalnızca sağlayıcının kendi ara yazılımı (middleware) üzerinden çalışan entegrasyonlar, yapılan iş yerine çalışan sayısına göre artan kullanıcı başı fiyatlandırma ve etki edemediğiniz bir yol haritası. Bunların hiçbirisi sözleşme imzalarken görünmez; yenileme zamanı geldiğinde ise hepsi aşikardır.

Bunun yerine: İmza atmadan önce bir deneme ortamından (sandbox) her şeyi dışarı aktarın ve nelerin çıktığını kontrol edin. API'nin ekranların yaptığı her işlemi mi yoksa yalnızca bir alt kümesini mi kapsadığını doğrulayın. Yalnızca satın aldığınız katmanın değil, bir sonraki katmanın fiyat listesini de okuyun.

7. Canlıya geçiş sonrasında keşfedilen mevzuat uyumluluğu

Başka bir üye devlette yeni bir KDV tescili, önümüzdeki ocak ayında başlayacak bir e-fatura zorunluluğu, yerel vergi dairesinin değiştirdiği bir beyanname formatı. Geleneksel bir projede bunların her biri ya bir iş ortağı katılımı ya da bir özelleştirmedir ve her biri kendi takvimine göre karşınıza çıkar.

Bunun yerine: Seçim yapmadan önce, şirketin tabi olduğu her ülkeye göre her beyannameyi ve her KDV rejimini listeleyin ve sağlayıcıdan bir demo ortamında her biri için çıktı dosyasını göstermesini isteyin. "X ülkesini destekler" bir pazarlama söylemidir; üretilen bir beyanname ise kanıttır.

Bir API neleri değiştirir?

Buradaki argüman sınırlıdır. API öncelikli (API-first) bir muhasebe çekirdeği bir ERP projesini tek başına başarılı kılmaz. Projeden belirli iş parçalarını çıkarır ve bu parçalara bağlı olan başarısızlık nedenleri de onlarla birlikte ortadan kalkar. Aşağıdakiler, Nordlet'in vadettiği sonuçlar olarak değil, ürünün bugün nasıl davrandığı şeklinde açıklanmıştır.

Entegrasyon siz imzalamadan önce test edilir. Tek bir çağrıyla gerçek bir şirketle aynı modüllere ve uç noktalara (endpoints) sahip, gerçek bir şirket gibi davranan bir sandbox şirketi oluşturulur ve bu işlem gerçek kullanım ile aynı ölçüm tarifesinden ücretlendirilir. Üretim öncesi test planı, bir demo değil, tekrarlanabilir bir testtir. Entegrasyon sandbox ortamında çalışmıyorsa, bunu herhangi bir taahhütte bulunmadan önce öğrenmiş olursunuz ki bu durum, entegrasyonun sondan bir önceki aşama olduğu geleneksel bir uygulamanın tam tersidir.

Yeniden denemeler mükerrer kayıt oluşturamaz. Değişiklik yaratan her çağrı bir Idempotency-Key başlığı alır. Aynı yük (payload) ile gönderilen aynı anahtar saklanan yanıtı yeniden oynatır (replay); farklı bir yük ile gönderilen aynı anahtar ise idempotency_key_reuse hatasıyla reddedilir. Ağ zaman aşımı sonrasında çift fatura kesilmesi gibi tüm bir entegrasyon kusurları sınıfı oluşamaz ve bu nedenle operasyon sonrası destek (hypercare) aşamasında da bulunamaz. İdempotensi sözlük girdisi işin mekaniğini kapsamaktadır.

Olaylar toplu senkronizasyonların (batch syncs) yerini alır. Webhook'lar, değişiklik ile aynı veritabanı işleminde (transaction) işlemsel bir outbox tablosuna yazılır; böylece geri alınan (rolled-back) bir belge asla bir olay (event) yaymaz ve hiçbir olay kaybolmaz. Sisteminiz sale_invoice.paid olayına gerçekleştiği anda tepki verir; mutabakatı yapılacak gece yarısı dosyası ve yazılıp test edilecek mutabakat mantığı kalmaz.

Defter, entegrasyon hatalarını sizin için yakalar. Veritabanı dengeli olmayan bir yevmiye kaydını reddeder. Gönderilmiş bir kayıt üzerinde değişiklik yapılamaz; düzeltmeler orijinal kayda bağlı ters kayıtlardır. Kilitli bir döneme tarihlenen bir kayıt 409 hatasıyla reddedilir. Bu kısıtlamalar değiştirilemez defterin pratikte ne anlama geldiğini gösterir ve sessiz veri sorunlarını geliştirme sırasında yüksek sesli API hatalarına dönüştürür.

KDV kuralları ve beyanname formatları sizin özelleştirmeniz değil, sağlayıcının bakım sorumluluğudur. AB KDV motoru ifa yerini (place of supply), tevkifatı, OSS, IOSS ve varsayılan tedarikçi kuralını çözer ve her yanıtla birlikte yasal dayanağı döndürür. 30 ülkeye ait beyanname formatları üründe kayıtlıdır; beyanname destek tablosu, her son tarih için Nordlet'in dosyayı gönderip göndermediğini, yükleme için oluşturup oluşturmadığını veya rakamları elle girmek üzere gösterip göstermediğini belirtir. Bir format değiştiğinde, değişiklik her şirket için bir ürün güncellemesi olarak yayınlanır ve ürün değişiklikleri sürüm notlarında (changelog) listelenir. Canlıya geçiş sonrasında keşfedilen uyumluluk (7. neden) seçim yapmadan önce halka açık bir sayfadan yanıtlayabileceğiniz bir soru haline gelir.

Fiyatlandırma koltuk (kullanıcı) sayısına bağlı değildir. Planlar istek başına ölçülür; her planda her modül, tam API ile sınırsız kullanıcı ve şirket yer alır. Maliyet, sisteme giriş yapan kişi sayısına göre değil, sistemin yaptığı işe göre artar ve daha sonra geçiş yapılması gereken bir özellik katmanı (feature tier) bulunmaz. Bu durum sağlayıcı bağımlılığının bir bileşenini ele alır (6. neden); diğerlerini ele almaz, sonraki bölümün var olma nedeni de budur.

Veri içeri girdiği gibi dışarı çıkar. Raporlar XLSX, PDF veya JSON olarak üretilir. Defter dışarı aktarımları, kullanan ülkeler için DATEV, FEC ve SIE formatlarında mevcuttur. Web uygulamasının gizli uç noktaları yoktur; bu nedenle ekranda görebileceğiniz her şeyi API aracılığıyla alabilirsiniz. 6. nedendeki dışarı aktarma testi, birinci gün sandbox ortamında çalıştırılabilir.

Bir API'nin değiştirmedikleri

Ana veri (master data) temizliği yine size aittir. Veri aktarım aracı hatalı paketleri doğrular ve reddeder; ancak bunları düzeltmez.
Süreç sahipliği hâlâ bir kadro kararıdır. Bir API "kim karar verecek" sorusunu küçültür çünkü yapılandırılacak daha az şey vardır, ancak sorunun kendisini yanıtlamaz.
Biri kod yazmak zorundadır. Yapılandırma projesinin yerini geliştiriciler tarafından yürütülen bir entegrasyon projesi alır. Ekibinizde geliştirici yoksa, bu tür bir ürün işi ortadan kaldırmaktan ziyade başka bir yere taşır.
Muhasebe dışı kapsam yine kapsamdır. Depo planlaması, üretim planlaması ve potansiyel müşterilerin ötesindeki bir CRM, aynı şekilde entegre edeceğiniz ayrı Nordlet modülleri ya da yanındaki ayrı sistemlerdir ve bunlar arasındaki entegrasyon hâlâ sizin projenizdir.
Sağlayıcı olgunluğu. Nordlet 2026 yılında erken erişim aşamasındadır ve tasarım ortaklarını sisteme dahil etmektedir. Genç bir sağlayıcı, sandbox testinin ortadan kaldırmadığı bir risk faktörüdür; test yalnızca ürünün mevcut durumunu ölçülebilir kılar.

İmza atmadan önce kısa bir kontrol listesi

Kabul listesini yazın: Kapanmış bir ay için belgeler, raporlar, beyannameler.
Proje başlamadan önce ana verileri temizleyin ve tarihçe konusuna karar verin.
Süreç başına bir yetkili belirleyin.
Entegrasyonu bir sandbox ortamında çalıştırın ve test paketini saklayın.
Deneme ortamından her şeyi dışarı aktarın ve dosyaları inceleyin.
Özellik listesini değil, her ülke için üretilen beyanname çıktısını görün.
Satın aldığınız katmanın bir üstünün fiyatını ve ayrılma maliyetini okuyun.

FAQ

ERP projelerinin başarısız olmasındaki tek en yaygın neden nedir?

Genellikle eski sistemi yeniden yaratan özelleştirme talepleri yoluyla, bütçe ve tarih belirlendikten sonra büyüyen kapsamdır. Veri kalitesi ise ikinci sırada yer alır ve canlıya geçiş tarihinin sarkmasının en yaygın nedenidir.

Bulut ERP seçmek bu başarısızlıkları önler mi?

Barındırma (hosting), sunucuları kimin çalıştırdığını değiştirir. Kapsamı, özelleştirmeyi, veri kalitesini veya sahipliği değiştirmez. Bulut ürünleri, yükseltmeleri sağlayıcının işi haline getirir; bu da özelleştirmenin uzun vadeli maliyetlerinden birini ortadan kaldırır.

API öncelikli bir sistem uygulama riskini nasıl azaltır?

Entegrasyonu, taahhütte bulunulmadan önce sandbox ortamında test edilebileceği projenin başına taşır, yeniden denemeleri ve olayları yapısal olarak güvenli hale getirir, vergi kurallarını ve beyanname formatlarını proje özelleştirmeleri olarak değil ürün özellikleri olarak sunar. Verilerinizi temizlemez veya süreçlerinize karar vermez.

API öncelikli bir muhasebe çekirdeği bir ERP midir?

Bir ERP'nin finansal çekirdeğidir: defter, belgeler, banka, vergi, beyannameler ve Nordlet durumunda ayrıca stok, üretim, bordro, duran varlıklar ve e-ticaret siparişleridir. SaaS ERP makalesi bu ayrımı ayrıntılı olarak ele almaktadır.

Sandbox ortamında neleri test etmeliyiz?

Bir fatura düzenleyin ve yevmiye kaydını okuyun. Aynı isteği iki kez gönderin ve faturaları sayın. Kilitli bir döneme kayıt atın ve 409 yanıtını onaylayın. Bir alacak dekontu (credit note) düzenleyin ve ters kaydı kontrol edin. Sandbox şirketinin ülkesi için KDV beyannamesini oluşturun. Defteri dışarı aktarın. Bunlar başarılı olursa muhasebe çekirdeği çalışıyor demektir; kalan risk verilerinizde ve diğer sistemlerinizdedir.