ERP Uygulaması Ne Kadar Sürer? Gerçekçi Süreç Takvimi

Bir ERP projesinin ne kadar sürdüğüne, süre uzatan etkenlere ve bir API aracılığıyla entegre ettiğiniz bir muhasebe çekirdeği kullandığınızda karşılaşacağınız farklı takvime aşama aşama bir bakış.

Standart modüllere sahip bir bulut ERP sistemine geçen küçük bir şirket, sözleşme imzasından canlıya geçişe (go-live) kadar genellikle üç ila altı aya ihtiyaç duyar. Birden fazla tüzel kişiliğe (entity), özel iş akışlarına ve entegrasyonlara sahip orta ölçekli bir şirket genellikle altı ila on iki aya ihtiyaç duyar. Büyük bir çokuluslu şirket kurulumu ise bir ila üç yıl sürer; bu genellikle bölgeye veya iş birimine göre dalgalar halinde gerçekleştirilir. Bu aralıklar, uygulama iş ortaklarının yayınladığı veriler ve finans ekiplerinin bildirdikleriyle uyumludur; bunlar bir anketin sonucu değildir ve belirli bir proje her iki yönde de bu aralıkların dışında kalabilir.

İnsanların aradığı tek bir sayı mevcut değildir, çünkü "uygulama" dokuz ayrı iş parçasından oluşur ve her birinin süresi, alıcının proje başlamadan önce aldığı kararlara bağlıdır. Bu makale, takvimi bu parçalara ayırmakta, her birini nelerin uzattığını göstermekte ve ardından farklı bir takvimi, yani muhasebe çekirdeği yapılandırdığınız bir sistem yerine kendi yazılımınızın iletişim kurduğu bir API olduğunda elde edeceğiniz takvimi açıklamaktadır.

Dokuz aşama ve her birini yönlendiren faktörler

Aşama	Tipik süre	Süreyi belirleyen etkenler
Seçim (Selection)	1–3 ay	Kısa listeye alınan tedarikçi sayısı, demo turları, referans görüşmeleri, tedarik kuralları
Tasarım (Design)	2–8 hafta	Kaç sürecin haritalandırılması gerektiği, ekibin bunlar üzerinde anlaşmaya varıp varmadığı, tedarikçinin standart akışının olduğu gibi ne kadar kabul edildiği
Veri aktarımı (Data migration)	4–16 hafta	Ana veri kalitesi, kaç yıllık geçmişin taşınacağı, kaynak sistemlerin sayısı
Yapılandırma (Configuration)	4–12 hafta	Tüzel kişilik (entity) sayısı, hesap planları (charts of accounts), ülkeler, vergi rejimleri, onay akışları
Entegrasyon (Integration)	4–20 hafta	Bağlanacak sistem sayısı (banka, bordro, e-ticaret, CRM, depo), her iki tarafın API kalitesi
Test etme (Testing)	3–8 hafta	Uçtan uca senaryo sayısı, test verilerinin gerçekçi olup olmadığı, ilk turda kaç kusur (defect) bulunduğu
Eğitim (Training)	2–6 hafta	Personel sayısı, rol çeşitliliği, yeni sürecin eskisinden ne kadar farklı olduğu
Canlıya geçiş (Go-live)	1–2 hafta	Geçiş yöntemi (big-bang veya aşamalı), dönem sonuna göre zamanlama
Ek destek (Hypercare)	4–12 hafta	Canlıya geçişteki açık kusur sayısı, ilk ay sonu kapanışı, yeni sistemden verilen ilk KDV beyannamesi

Aşamalar uygulamada birbiriyle örtüşür. Yapılandırma devam ederken entegrasyon başlar; eğitim genellikle test aşamasıyla çakışır. Gerçekçi bir plan, sütunlardaki sürelerin toplamı değildir; ancak kritik yol (critical path) genellikle veri aktarımı ve entegrasyon üzerinden geçer ve çoğu aksama bu iki aşamada yaşanır.

Projeyi ne uzatır?

Özelleştirme (Customisation). Tedarikçinin standart davranışında yapılan her değişikliğin şartnamesi yazılmalı, geliştirilmeli, test edilmeli, belgelendirilmeli ve ardından gelecekteki her yükseltmede (upgrade) yeniden test edilmelidir. Akışların %90'ı için standart süreci kabul edip geri kalanını özelleştiren bir proje tamamlama eğilimindeyken; işe eski sistemin ekranlarını kopyalayarak başlayan bir proje genellikle tamamlanamaz.

Kirli ana veriler. Yinelenen müşteriler, üç farklı şekilde yazılmış tedarikçiler, ölçü birimi olmayan kalemler, on yıldır büyüme yoluyla şişmiş bir hesap planı. Veri aktarımı, temizlik işleminden daha hızlı olamaz ve temizlik, halihazırda günlük işleri olan insanlar tarafından yapılır. Bu, ertelenen canlıya geçiş tarihlerinin en yaygın nedeni olup orijinal planda en az görünen kısımdır.

Birden fazla tüzel kişilik. Her yasal birimin kendi hesabına, numaralandırmasına, KDV kaydına, banka hesaplarına ve dönem kapanışına ihtiyacı vardır. Bunlar arasındaki şirket içi akışların (intercompany flows) ayrıca tasarlanması gerekir. Yapılandırma aşamasını tüzel kişilik sayısıyla çarpın, ardından konsolidasyon tasarımını da üstüne ekleyin.

Çok ülkeli vergi yapıları. Birkaç AB üye devletine satış yapan bir şirket; ilk beyanname dönemi gelmeden yeni sistemde teslim yeri (place of supply) kurallarını, tevkifatı (reverse charge), OSS raporlamasını ve yerel beyanname formatlarını doğru ayarlamak zorundadır. Tedarikçinin bir ülke için yerelleştirmesi (localisation) yerel veya orijinal olmak yerine bir iş ortağı tarafından yapıldıysa, o iş ortağının uygunluk durumu kritik yolun bir parçası haline gelir.

Zayıf API'lere sahip entegrasyonlar. Yalnızca dosya tabanlı içe aktarmaları destekleyen bir ERP, bağlı her sistemi toplu iş (batch) düzenine zorlar ve her toplu iş düzeni, birinin yazıp test etmesi gereken mutabakat mantığına (reconciliation logic) ihtiyaç duyar.

Kapsamdan önce belirlenen canlıya geçiş tarihi. Tarih siyasi nedenlerle belirlenip kapsam daha sonra ortaya çıktığında, proje ya test sürecini kısaltır ya da tarihi erteler. Her iki seçenek de maliyetlidir.

Projeyi ne kısaltır?

İş süreçlerinin fiilen farklı olmadığı durumlarda tedarikçinin standart süreçlerini kabul etmek.
Ana verileri proje sırasında değil, proje başlamadan önce temizlemek.
Tüm geçmişi taşımak yerine açılış bakiyelerini ve açık kalemleri (open items) aktarmak, eski sistemi sorgulamalar için okunabilir durumda tutmak.
Geçiş tarihini, kilitlenmiş ve mutabakatı yapılmış kapanış mizanı ile birlikte bir dönem sınırına denk getirmek.
Karar verme yetkisine sahip her modül için tek bir süreç sahibi (process owner) atamak.
Uydurma örneklerle değil, son on iki aya ait gerçek belgelerle test yapmak.
Entegrasyonların yapılandırmadan sonra değil, yapılandırmayla paralel olarak oluşturulup test edilmesine olanak tanıyan bir API'ye sahip sistem seçmek.

Farklı bir takvim: API odaklı muhasebe çekirdeği

Yukarıdaki süreler, insanların ekranlar aracılığıyla yapılandırdığı ve ardından yine ekranlar aracılığıyla kullandığı bir sistemi tanımlamaktadır. Başka türde bir proje yapısı daha vardır ve bunun çalışma temposu farklıdır. Muhasebe çekirdeği bir muhasebe API'siyse, entegrasyon çalışmaları öne çekilir ve yapılandırma aşamasının büyük kısmı ortadan kalkar, çünkü yapılandırılacak daha az şey vardır: hesap planı, vergi kuralları ve beyanname formatları ürünle birlikte hazır gelir.

Nordlet ile bunun nasıl göründüğü, bir vaat olarak değil bugün ürünün yaptığı işler temel alınarak aşağıda özetlenmiştir:

Birinci gün: bir sandbox şirketi. Sandbox ortamında bir şirket, uygulamadan veya tek bir API çağrısıyla oluşturulur. Aynı modüllere ve aynı uç noktalara (endpoints) sahip gerçek bir şirket gibi çalışır ve ihtiyacınız kadar çok sayıda oluşturabilirsiniz. Başlangıç kılavuzu ilk çağrıları adım adım açıklar.

Birinci ila beşinci günler: ilk çalışan akış. Bir iş ortağı (partner) oluşturun, bir fatura oluşturun, faturayı kesin, ödeme alın, faturanın ürettiği yevmiye kaydını okuyun. Her işlem, JSON gövdesine sahip bir POST /v1/{module}/{resource}/{action} çağrısıdır ve dokuz dil için yazılı SDK'lar mevcuttur, bu nedenle ilk akış birkaç düzine satırlık koddan ibarettir. Idempotency-Key üst bilgisi (header), ikinci bir fatura oluşturmak yerine saklanan yanıtı yeniden oynattığı için yeniden denemeler güvenlidir.

İkinci hafta: geçmiş veriler. Geçiş içe aktarıcısı (migration importer); hesap planını, iş ortaklarını, kalemleri, açılış bakiyelerini veya tam yevmiye geçmişini, açık müşteri ve tedarikçi faturalarını, bugüne kadarki amortismanıyla birlikte duran varlıkları ve elde bulunan stokları alır, bunları tek bir veritabanı işleminde (transaction) yazar. Yalnızca kontrol uç noktası (migration/books/validate) tüm doğrulamaları çalıştırır ancak hiçbir şey yazmaz, bu nedenle paket hata bildirmeyene kadar üzerinde yineleme yaparsınız ve ardından migration/books/import komutunu bir kez çalıştırırsınız. Herhangi bir satır başarısız olursa hiçbir şey saklanmaz.

İkinci ila dördüncü haftalar: entegrasyonun geri kalanı. PSD2 bağlantıları üzerinden banka hareketleri, camt.053 ekstre içe aktarımı, Stripe dışa aktarımları ve sisteminizin yoklama (polling) yapmak yerine olaylara tepki vermesini sağlayan sale_invoice.paid gibi web kancaları (webhooks). Her parça ayrı bir uç noktadır ve farklı bir geliştirici tarafından paralel olarak oluşturulabilir.

Mevzuata uyum: halihazırda kayıtlı. Sınır ötesi bir satışın KDV muamelesi AB KDV motoru tarafından çözülür ve şirketin bulunduğu ülkenin beyanname takvimi yerleşik kurallardan doldurulur. Beyanname destek tablosu, 30 ülkenin tümü için Nordlet'in hangilerini kendisinin beyan ettiğini, hangileri için bir dosya oluşturduğunu ve hangilerinin elle girildiğini listeler. Bunların hiçbirisi proje işi değildir.

Test olarak dönem kapanışı. İlk ay sonu kapanışı, bir ERP projesinin çalışıp çalışmadığını anladığı yerdir. Değiştirilemez bir defter (immutable ledger) ve dönem kilitleme özelliği sayesinde, kilitli bir aya ait bir mahsup kaydı 409 hatasıyla reddedilir; böylece kapanış, disiplin yerine sistem tarafından zorunlu kılınır ve normalde ek destek (hypercare) aşamasında bulunacak entegrasyon hataları bunun yerine sandbox ortamında ortaya çıkar.

Bu takvimin dürüstçe kabul edilen sınırları: Muhasebe, vergi ve beyanname çekirdeğini kapsar. Projenizin ayrıca depo yönetimine, üretim planlamasına veya bir CRM'e ihtiyacı varsa, bunlar ya aynı şekilde entegre edeceğiniz Nordlet modülleridir (envanter, üretim, e-ticaret siparişleri, potansiyel müşteriler) ya da yan tarafta duran sistemlerdir ve ikincisi için entegrasyon çalışmaları yine size aittir. Nordlet ayrıca 2026 yılında erken erişimde olan ve tasarım ortaklarını bünyesine katan genç bir üründür; bu da her tedarikçi kararında göz önünde bulundurulması gereken bir faktördür.

Kendi projenizi nasıl tahmin edersiniz?

Tüzel kişileri, ülkeleri ve KDV kayıtlarını sayın. Bunların her biri geleneksel bir ERP'de yapılandırma işi, API odaklı bir ERP'de ise bir şirket kaydıdır.
Entegrasyonları sayın ve sözleşme imzalamadan önce her sistemin API'sini kontrol edin. Yalnızca dosya kabul eden bir arayüz, entegrasyon süresi tahminini kabaca iki katına çıkarır.
Ne kadar geçmiş verinin taşınacağına karar verin. Açılış bakiyeleri artı açık kalemler haftalar sürer; tam çok yıllı geçmiş aylar sürer.
Canlıya geçiş tarihini tersinden değil, dönem takviminden belirleyin. Mutabakatı yapılmış bir kapanış bakiyesiyle yıl sonu veya çeyrek sonu sınırı, elde edebileceğiniz en ucuz canlıya geçiş noktasıdır.
İlk kapanışın normal bir kapanıştan iki kat daha uzun süreceğini varsayayın ve yeni sistemden verilecek ilk KDV beyannamesi ile ilk bordro çalışması için ek destek bütçesi ayırın.
Proje başlamadan önce kabul testini yazın: Kapanan ilk ay için yeni sistemden doğru şekilde çıkması gereken belgelerin, raporların ve beyannamelerin listesi. Üretim öncesi test planı, muhasebe kısmı için şablonlardan biridir.

FAQ

Bir ERP uygulaması üç aydan kısa sürebilir mi?

Evet, standart süreçleri kabul eden, yalnızca açılış bakiyelerini aktaran ve bir veya iki entegrasyona sahip tek tüzel kişiliğe sahip bir şirket için mümkündür. API odaklı bir muhasebe çekirdeğinde ilk çalışan akış günlerle ölçülür ve geriye kalan en uzun kalem genellikle veri aktarım paketidir.

En sık hangi aşama aksar?

Veri aktarımı, onu takip eden entegrasyon. Her ikisi de tedarikçinin kontrol etmediği sistemlerin durumuna bağlıdır: mevcut verilerinizin kalitesi ve bağladığınız sistemlerin API'leri.

Tam geçmişi mi yoksa yalnızca açılış bakiyelerini mi taşımalıyız?

Açılış bakiyeleri ve açık kalemler, yeni sistemin canlıya geçiş tarihinden itibaren eksiksiz olması için yeterlidir ve çok daha kısa sürer. Tam geçmiş, yeni sistem içinde karşılaştırmalı verilere ihtiyaç duyduğunuzda veya eski sistem tamamen kapatılacağı zaman anlamlıdır. Nordlet'in içe aktarıcısı her iki seçeneği de kabul eder.

Aşamalı bir geçiş, büyük patlama (big-bang) tarzı canlıya geçişten daha mı hızlıdır?

Aşamalı geçişler toplamda daha uzun sürer ancak her adımda daha az risk taşır ve ekibin bir sonraki birime geçmeden önce ilk birimden ders çıkarmasını sağlar. Organizasyon, tek bir geçiş hafta sonunun her şeyi kapsayabileceği kadar küçükse büyük patlama yöntemi daha kısadır.

API odaklı bir ürün için "uygulama" süreci nasıl farklıdır?

Ekran ekran ilerleyen bir yapılandırma projesi yoktur. Yapılan iş, geliştiriciler tarafından bir sandbox ortamına karşı gerçekleştirilen entegrasyon ve veri aktarımıdır; uyumluluk katmanı (KDV kuralları, beyanname formatları, takvimler) ürünle birlikte gelir. Buradaki ödünleşim (trade-off), sizin tarafınızdan birinin kod yazacak olmasıdır.