ERP'de özelleştirme riski: ne zaman standart kalın, ne zaman uyarlama yapın

2011 yılında Lidl, Almanya merkezli SAP ile birlikte kendi mağaza ve depo ağı için yeni bir stok ve satış yönetim sistemi kurmaya başladı. Proje, SAP'nin perakende sektörüne özel hazır ürünü üzerine inşa edildi ama Lidl bir noktada standart akıştan vazgeçti: kendi kullandığı, sektörde pek yaygın olmayan bir stok değerleme yöntemini sistemin merkezine oturtmak istedi. Yıllar içinde bu tek talep, onlarca ek özelleştirmeye dönüştü. 2018 yazında Lidl projeyi tamamen durdurdu, eski kendi geliştirdiği sisteme geri döndü ve toplam maliyetin yaklaşık 500 milyon euroya ulaştığı kamuoyuna yansıdı.

Vaka çarpıcı ama istisna değil. ERP projelerinde özelleştirme talebi hemen her uygulamada bir noktada masaya geliyor; sorun özelleştirmenin kendisi değil, hangi taleplerin gerçekten gerekli olduğuna karar verirken izlenen (ya da izlenmeyen) disiplin.

Özelleştirme neden bu kadar cazip gelir

Bir ekip yıllardır belirli bir rapor formatına, belirli bir onay sırasına veya kendi geliştirdiği bir hesaplama mantığına alışkın olduğunda, yeni ERP'nin standart akışı "eksik" ya da "yanlış" gibi görünür. Danışman veya vendor ekibi de genelde "yaparız" der; teknik olarak neredeyse her şey mümkündür, soru hep "yapılmalı mı" değil "yapılabilir mi" olarak sorulur. Tek bir talep başlı başına küçük ve makul görünür. Riski büyüten, onlarca küçük talebin birikip sistemi vendor'ın desteklediği standart yoldan çıkarması.

Yapılandırma ile kod düzeyinde özelleştirme farklı şeyler

İki kavram sık karıştırılıyor ama sonuçları çok farklı. Yapılandırma, vendor'ın zaten sunduğu ayarlar içinde kalmaktır: bir alanı zorunlu yapmak, bir onay adımını açıp kapatmak, rapor şablonunu mevcut seçeneklerden birine göre düzenlemek. Bu değişiklikler vendor'ın test ettiği kombinasyonlar içinde kalır, yeni sürüm güncellemesi geldiğinde genelde sorunsuz çalışır.

Kod düzeyinde özelleştirme ise vendor'ın standart ürününe yeni kod eklemek, veritabanı şemasını değiştirmek ya da vendor'ın desteklemediği bir entegrasyon kurmaktır. Bu değişiklikler her yeni sürümde yeniden test edilmeli, bazen yeniden yazılmalıdır; vendor'ın kendi yükseltme testleri bu özel kodu kapsamaz. Lidl vakasında sorunun büyümesinin bir nedeni tam olarak buydu: standart üründen uzaklaştıkça sistem hem daha kırılgan hem de yükseltmesi neredeyse imkânsız hale geldi.

Özelleştirmenin görünmeyen maliyeti

Bir özelleştirme talebi onaylandığında görünen maliyet genelde geliştirme saatidir; asıl fatura daha sonra, farklı kalemlerde gelir. Destek sözleşmesi kapsamı bunlardan biri: vendor, "bu hata sizin özel kodunuzdan kaynaklanıyor, standart destek kapsamımızda değil" dediğinde, sorunu çözmek işletmenin veya danışmanlık firmasının sırtına kalır. Bilgi kaybı bir diğeri — özelleştirmeyi tasarlayan danışman ya da geliştirici kurumdan ayrıldığında, kodun neden o şekilde yazıldığını bilen kimse kalmayabilir. Her yeni sürüm güncellemesinde bu özel kodun yeniden test edilmesi gerektiği için, vendor standart bir güncellemeyi bir haftada yayarken, özelleştirilmiş kurulum aynı güncellemeyi aylarca erteleyebilir; bu da işletmeyi güvenlik yamalarından ve yeni özelliklerden geride bırakır.

Ne zaman standart süreçte kalınmalı

• Süreç sektör genelinde zaten benzer şekilde işliyorsa (genel muhasebe, standart satın alma onay sırası gibi) — burada özgünlük aramanın bir değeri yok
• Talep "biz hep böyle yaptık" alışkanlığından geliyorsa, gerçek bir iş zorunluluğundan değil
• Vendor'ın yerleşik akışı, mevcut süreçten daha az hataya açık ve daha hızlıysa — eski alışkanlık genelde daha iyi olduğu için değil, öyle öğrenildiği için sürdürülür
• Değişiklik tek bir kişinin ya da tek bir departmanın tercihine dayanıyorsa, kurum genelinde ortak bir ihtiyaca değil
• Aynı sonucu, ek kod yazmadan bir rapor veya panel ayarıyla almak mümkünse

Ne zaman gerçek uyarlama gerekir

• Sektöre özgü ya da mevzuata dayalı bir hesaplama yöntemi standart modülde hiç yoksa
• İşin rekabet avantajı yarattığı, gerçekten özgün bir süreç söz konusuysa — herkesin aynı şekilde yaptığı bir süreç değil
• Vendor'ın kendi arayüzü (API) üzerinden desteklenen, yükseltme testine dahil edilen bir entegrasyon ihtiyacı varsa
• Standart paket, çok şirketli veya çok para birimli konsolidasyon gibi yapısal bir ihtiyacı hiç karşılamıyorsa
• Değişiklik yapılmazsa süreç fiilen elle, Excel'e dökülerek yürütülmeye devam edecekse — bu durumda "özelleştirme yapmamak" aslında ERP'nin dışında ikinci, gölge bir sistem yaratmak anlamına gelir

Karar çerçevesi

Tek bir satırın "uyarlama" yönünde çıkması yeterli değil; birkaç kriterin birlikte aynı yöne işaret etmesi beklenir. Tersi de geçerli: tüm kriterler standart yönü gösteriyorsa, "biz farklıyız" hissine rağmen standart süreçte kalmak genelde daha ucuza ve daha az riske mal olur.

Bu tabloyu kurumsal bir kurul gibi işletmek gerekmiyor; asıl amaç, özelleştirme talebini ilk isteyen kişiden (genelde bir departman müdürü) bağımsız bir gözle bir kez daha sorgulatmak. Talebi ilk yapan kişi neredeyse her zaman haklı olduğuna inanır — kendi sürecini en iyi o bilir. Ama proje ekibinin görevi süreci değil, projenin toplam riskini ve maliyetini yönetmektir; bu yüzden karar tek kişiye değil, yukarıdaki kriterleri birlikte değerlendiren küçük bir gruba bırakılmalı.

Sözleşmede özelleştirme maddesi neden gözden kaçırılmamalı

Özelleştirme kararı verildiğinde asıl risk genelde teknik değil, sözleşmeseldir: kodun kaynağına kim sahip, yükseltme sırasında bu kodu kim test edip taşıyacak, vendor değişirse bu özel kod başka bir sisteme nasıl aktarılacak? Bu sorular ERP sözleşmesi imzalamadan önce kontrol listesinde ele aldığımız maddelerin arasında yer almalı; özelleştirme kapsamı net yazılmadığında, projenin ilerleyen aşamalarında "bu bizim taahhüdümüzde yoktu" tartışması sıkça yaşanıyor.

Kurulum modeli özelleştirme kapasitesini belirliyor

Bulut üzerinde çalışan, aynı yazılımı çok sayıda müşterinin ortak kullandığı kiralık modeldeki ERP'ler, mimarileri gereği kod düzeyinde özelleştirmeye daha kapalıdır; buna karşılık yapılandırma seçenekleri genelde geniştir. Bu bir eksiklik değil, koruma: vendor tüm müşterilerine aynı anda güncelleme yaptığı için, tek bir müşteriye özel kod tüm sistemin kararlılığını tehdit eder. Şirket içi kurulan ya da tek müşteriye özel çalışan sistemlerde kod düzeyinde özelleştirme daha kolay yapılır, ama bakım yükü de o oranda müşteriye kalır. Bu dengeyi bulut ve şirket içi ERP karşılaştırmamızda daha ayrıntılı ele alıyoruz.

Türkiye'deki işletmeler için pratik çıkarım

Sektöre göre özelleştirme ihtiyacı gerçekten farklılaşıyor. Üretim yapan firmalarda parti bazlı maliyetlendirme veya çok aşamalı iş emri takibi gibi ihtiyaçlar standart pakette bazen eksik kalabiliyor; inşaat ve proje bazlı işlerde hakediş ve maliyet dağıtım mantığı da benzer şekilde sektöre özel kalabiliyor. Bu tür ihtiyaçlar varsa, seçim aşamasında vendor'a "bu süreç sizin standart ürününüzde nasıl karşılanıyor" diye doğrudan sormak, sonradan özelleştirme faturasıyla karşılaşmaktan daha ucuza gelir. Yerli bulut tabanlı ERP'lerde (Qera ERP gibi) bu ihtiyaçların bir kısmı zaten modül olarak hazır gelebilir; daha büyük ölçekli ve derin özelleştirme isteyen kurulumlarda ise Canias gibi kod düzeyinde genişletmeye daha açık mimarilere sahip ürünler tercih ediliyor.

Karar tek bir kişiye bırakılmamalı; satın alma, BT ve sürecin sahibi olan departman birlikte hangi taleplerin gerçekten gerekli olduğunu netleştirmeli. Bu değerlendirmeyi kendi başınıza yapmak zorsa, bağımsız bir keşif görüşmesi talep edilebilir ya da uygun ERP bul aracıyla ölçeğe ve sektöre uygun seçenekler karşılaştırılabilir.

Özelleştirme talebini elemeden geçirecek sorular

• Bu talep olmadan iş süreci gerçekten durur mu, yoksa alışkanlık mı konuşuyor?
• Aynı sonucu ek kod yazmadan, mevcut ayarlarla almak mümkün mü?
• Bu özelleştirme vendor'ın desteklediği bir genişletme noktasından mı geçiyor, yoksa tamamen dışarıda mı kalıyor?
• Yükseltme geldiğinde bu kodu kim test edecek, kim bakımını üstlenecek?
• Vendor değişirse bu özel süreç yeni sisteme nasıl taşınacak?

Kaynaklar

• The Lidl SAP ERP System Project Failure Case Study — Panorama Consulting
• Lidl dumps €500m SAP project — Computer Weekly
• ERP sözleşmesi imzalamadan önce kontrol listesi
• Bulut mu, şirket içi mi? ERP karar rehberi