ERP entegrasyon süresi neredeyse her projede baştaki tahmini aşar. Sebep genellikle teknik zorluk değildir; bağlantının kendisi çoğu zaman işin en kısa parçasıdır. Süre, hesaba katılmayan dört katmanda büyür: verinin gerçek hâli, iki sistemin farklı iş kuralları, yetki ve onay zinciri, bir de kimin neye karar vereceğinin belirsizliği. "İki hafta" denen iş üç aya çıktığında, aradaki farkın büyük bölümü kod yazılan saatlerde değil, cevap beklenen günlerde geçer. Bu yüzden gerçekçi bir süre tahmini, API dokümanına bakarak değil, veriye ve karar mekanizmasına bakarak yapılır.
ERP entegrasyon süresinin büyük kısmı bağlantıda geçmez
Modern ERP'lerin çoğunda bir API, en azından bir veri aktarım yöntemi vardır. İki sistemi konuşturmak, deneyimli bir ekip için günler mertebesinde bir iştir.
Teklif aşamasında konuşulan da genelde budur: "API var mı? Var. O zaman iki hafta." Bu cümle teknik olarak yanlış değildir. Eksik olan, bağlantının kurulmasıyla entegrasyonun çalışması arasındaki mesafedir.
Bağlantı, iki sistemin veri alışverişi yapabilmesidir. Entegrasyon, bu alışverişin iş kurallarına uygun ve güvenilir olmasıdır. Aradaki fark, sürenin de büyük bölümünü açıklar. Bir ERP entegrasyon süresi tahmini yapılırken bağlantı kalemi genellikle doğru hesaplanır; yanlış hesaplanan, o bağlantının üzerine kurulacak kurallardır. Hangi kayıt gönderilecek, hangisi atlanacak, hangi durumda güncelleme yapılacak, çakışma olursa hangisi kazanacak. Bunların hiçbiri API dokümanında yazmaz çünkü hiçbiri teknik soru değildir. Her biri işletmenin kendi işleyişine bağlıdır ve cevabı ancak o işleyişi bilen kişi verebilir. Süre, tam olarak bu cevapların toplanması sırasında büyür.
Verinin gerçek hâli tahminleri bozar
Entegrasyon planları, verinin dokümanda tarif edildiği gibi olduğu varsayımıyla yapılır. Sahada durum genelde farklıdır.
Yıllardır kullanılan bir ERP'de tipik olarak şunlarla karşılaşılır:
- Aynı müşteri birden çok kez, farklı yazımlarla kayıtlıdır.
- Zorunlu olmayan alanlar boştur ve o boşluk bir anlam taşır — ama yazılı değildir.
- Bazı alanlar amacı dışında kullanılmıştır. "Açıklama" alanına yıllarca kod yazılmıştır ve bir rapor buna bağlıdır.
- Terk edilmiş kayıtlar silinmemiş, pasife alınmamış, sadece kullanılmaz olmuştur.
Ancak bunların hiçbiri kötü yönetim işareti değildir; uzun süre kullanılan her sistemde birikir. Ama entegrasyonda her biri bir karar noktasıdır ve kararı yazılımcı veremez. Hangi kaydın geçerli olduğunu bilen kişi işletmenin içindedir ve genelde çok meşguldür.
Dolayısıyla süre burada büyür: teknik iş bir günlüktür, kararı almak bir haftalık.
İki sistemin iş kuralları aynı değildir
Aynı kavram iki sistemde farklı tanımlanır. Bu, entegrasyonun en çok küçümsenen kısmıdır.
Basit görünen bir örnek: "sipariş tamamlandı" ne demek? Bir sistemde sevkiyat çıktığında tamamlanır, ötekinde fatura kesildiğinde. İkisini doğrudan eşlerseniz raporlar tutmaz ve bu tutmama aylar sonra fark edilir.
Aynı sorun şurada da çıkar:
- Zaman. Bir sistem işlem anını, öteki muhasebe dönemini esas alır. Ay sonu ve yıl sonu geçişlerinde iki kayıt farklı döneme düşer.
- Birim ve yuvarlama. Kilogram/ton, adet/koli, KDV dahil/hariç. Yuvarlama kuralı farklıysa toplamlar kuruş kuruş kayar; kayma büyüdükçe mutabakat imkânsızlaşır.
- İptal ve iade. Bir sistem kaydı siler, öteki ters kayıt atar. Silinen kayıt karşı tarafta öksüz kalır.
- Kimlik. İki sistemde aynı ürünün farklı kodu vardır. Eşleme tablosu kurulmazsa her yeni ürün elle müdahale ister.
Görüldüğü gibi bu farklar teknik değil, iş kararlarıdır. Her biri için işletmenin "bizde doğrusu şu" demesi gerekir. O cümle kurulana kadar geliştirme durur.
Yetki ve erişim beklenenden uzun sürer
Entegrasyonun ERP tarafına erişim gerekir. Bu erişim çoğu zaman:
- ERP'yi satan firmadan istenir ve o firmanın kendi iş sırası vardır,
- lisans kapsamına bağlıdır; API modülü ayrı satılıyor olabilir,
- bilgi işlem onayı ister,
- bazen sözleşme değişikliği gerektirir.
Oysa bunların hiçbiri zor değildir. Hepsi yalnızca başkasının takvimine bağlıdır. Proje planı bu bağımlılığı içermiyorsa, ilk gecikme buradan gelir ve genelde iki ile altı hafta arasında bir yer kaplar.
Ayrıca test ortamı ayrı bir başlıktır. Canlı ERP üzerinde test yapılamaz; kopya ortam ya yoktur ya da güncel değildir. Güncel olmayan kopyada geçen testler, canlıda yeni sorunlar çıkarır.
Hata durumunda ne olacağı baştan konuşulmaz
Entegrasyon planları mutlu senaryo üzerine kurulur: veri gider, karşı taraf alır, iş biter. Gerçekte bağlantı kopar, karşı sistem bakıma girer, bir kayıt reddedilir.
Bu durumların her biri bir karar gerektirir:
- Gönderilemeyen kayıt kuyrukta bekleyecek mi, yoksa hata mı verecek?
- Kuyrukta bekleyecekse ne kadar? Kuyruk şişerse kim haberdar olacak?
- Aynı kayıt iki kez giderse karşı taraf iki kayıt mı oluşturur? (Bu, entegrasyonların en sık ve en pahalı hatasıdır.)
- Kısmi başarı olursa — on kalemin yedisi geçtiyse — işlem geri mi alınır?
Bu soruların cevabı baştan verilmezse, sistem canlıya çıkar ve ilk kesintide sessizce yanlış veri üretir. O noktada yapılan iş, geliştirme değil, veri temizliğidir; ve veri temizliği her zaman geliştirmeden uzun sürer.
Süreyi kısaltan üç şey
ERP entegrasyon süresini kısaltan şey daha hızlı yazılım geliştirmek değildir. Üç şey işe yarar.
Kapsamı daraltmak. İlk sürümde tek yönlü ve tek konulu bir akış kurmak — örneğin yalnızca cari kartların ERP'den web'e aktarılması — hem hızlı biter hem de veri sorunlarını erken ortaya çıkarır. Çift yönlü senkronizasyon, tek yönlünün en az iki katı iştir; başlangıç için nadiren gereklidir.
Karar verecek kişiyi baştan belirlemek. Yukarıdaki soruların hepsini cevaplayacak tek bir muhatap yoksa proje, cevap bekleyerek uzar. Bu kişinin teknik olması gerekmez; işi bilmesi ve karar yetkisi olması yeterlidir.
Gerçek veriyle erken denemek. Örnek veriyle yapılan testler işin yalnızca mutlu senaryosunu doğrular. Canlı verinin bir kopyasıyla yapılan ilk deneme, planı bozacak sürprizlerin çoğunu ilk haftada ortaya çıkarır. Sürpriz ne kadar erken çıkarsa o kadar ucuzdur.
Gerçekçi bir ERP entegrasyon süresi nasıl tahmin edilir
Sağlıklı bir tahmin, şu dört sorunun cevabı alındıktan sonra verilir:
1. Hangi veri, hangi yöne, hangi sıklıkla akacak? 2. Bu verinin canlı sistemdeki gerçek hâli ne? (Tahmin değil, örnek dışa aktarım.) 3. Erişim kimden, ne zaman gelecek? Test ortamı var mı? 4. Hata ve çakışma durumunda kural ne?
Bu dört soru cevaplanmadan verilen bir ERP entegrasyon süresi, tahmin değil temennidir. Cevaplandıktan sonra verilen süre genellikle ilk tahminden uzundur — ama tutar. Tutmayan kısa süre, tutan uzun süreden her zaman pahalıya mal olur; çünkü aradaki fark sonradan güven kaybı olarak ödenir.
Sık sorulanlar
ERP entegrasyonu ortalama ne kadar sürer?
ERP entegrasyon süresi için ortalama vermek yanıltıcı olur, çünkü süreyi belirleyen ERP'nin kendisi değil, verinin durumu ve karar hızıdır. Aynı ERP ile iki farklı işletmede süre kat kat farklı çıkabilir. Sağlıklı yaklaşım, yukarıdaki dört soruyu cevaplayıp ondan sonra tahmin istemektir.
ERP firmasının kendi entegrasyonu varsa onu kullanmak daha mı iyi?
Genellikle evet, eğer ihtiyacınızı karşılıyorsa. Hazır entegrasyon, ERP tarafındaki değişikliklerde bakımı üstlenmesi bakımından avantajlıdır. Sınır, kendi iş kurallarınızın devreye girdiği yerdedir; hazır akış onları esnetemiyorsa özel geliştirme kaçınılmaz olur.
Entegrasyon canlıya çıktıktan sonra bakım gerektirir mi?
Evet. ERP sürüm yükselttiğinde, alan eklendiğinde veya iş kuralı değiştiğinde entegrasyonun da güncellenmesi gerekir. Bakımı olmayan entegrasyon, çalışmayı bir gün sessizce bırakır ve bu genelde aylar sonra fark edilir. Sonuç olarak izleme ve uyarı, projenin isteğe bağlı değil zorunlu parçasıdır.
Tek seferlik veri aktarımı da entegrasyon mudur?
Hayır, ve karıştırılması pahalıya mal olur. Tek seferlik aktarım (göç) bir kez yapılır, doğrulanır, biter. Entegrasyon süreklidir ve hata yönetimi, izleme, çakışma kuralı gerektirir. Göç fiyatıyla entegrasyon beklemek, projelerin en sık kırıldığı noktalardan biridir.
---
Mevcut sisteminizle entegrasyon düşünüyorsanız, ilk adım kod değil analizdir: hangi verinin ne durumda olduğunu görmeden verilen süre tutmaz. Süreci birlikte çıkarıp gerçekçi bir plan kuruyoruz.