ERP projelerinde en pahalı kararlar genellikle ilk demoların hemen ardından, “bizde şöyle çalışır, sistem de aynen böyle yapsın” cümlesiyle alınır. O cümlenin arkasında bazen gerçek bir iş gereksinimi, bazen de sadece yıllardır öyle alışılmış bir Excel makrosu vardır. İkisini birbirinden ayırmak, bir ERP projesinin bütçesini, süresini ve sonraki beş yılını belirleyen asıl iştir.
Özelleştirme kötü bir şey değildir; kontrolsüz özelleştirme kötüdür. Standart süreç de her zaman doğru değildir; körü körüne standarda uymak da işletmeyi rakiplerinden farklı kılan asıl gücü silebilir. Doğru cevap her ikisinin arasında, disiplinli bir eleme sürecinde saklıdır. Bu yazıda o eleme sürecini — fit-gap analizini — ve onu ayakta tutan kapsam yönetimini adım adım ele alıyoruz.
Özelleştirme ile Konfigürasyon Aynı Şey Değil
Konuşmaya başlamadan önce iki kelimeyi ayırmak gerekir, çünkü çoğu tartışma bu ikisi karıştırıldığı için uzar.
Konfigürasyon, yazılımın kendi içinde sunduğu ayarlarla süreci şekillendirmektir: onay basamaklarını tanımlamak, iskonto yetkisini role bağlamak, depo tiplerini belirlemek, fatura şablonunu düzenlemek, yeni bir masraf merkezi açmak. Kod yazılmaz, sadece hazır kutular işaretlenir. Konfigürasyon güncellemelerden etkilenmez, taşınabilir ve geri alınabilir.
Özelleştirme (customization) ise yazılımın standart davranışını kod düzeyinde değiştirmek ya da ona yeni bir işlev eklemektir: standart olmayan bir hesaplama motoru, sıfırdan yazılmış bir ekran, dış bir sisteme özel bir arayüz. Özelleştirme güçlüdür ama bedeli vardır: yazıldığı andan itibaren bakımı, test edilmesi ve her sürüm yükseltmesinde yeniden doğrulanması gerekir.
Pratik kural şudur: bir ihtiyacı önce konfigürasyonla karşılayabiliyorsanız, orada durun. Talep listenizin büyük bölümünün aslında konfigürasyonla çözülebildiğini görmek, çoğu projede ilk büyük rahatlamadır. QERA gibi tek platform üzerinde kurgulanmış sistemlerde bu ayarların çoğu arayüzden yapılabildiği için “özelleştirme” sanılan isteklerin bir kısmı hiç kod gerektirmeden kapanır.
Fit-Gap Analizi Nedir?
Fit-gap analizi, işletmenizin çalışma biçimi ile ERP’nin standart yetenekleri arasındaki örtüşmeyi ve boşlukları sistematik biçimde çıkaran bir yöntemdir. Her önemli süreç tek tek masaya yatırılır ve üç kovadan birine atılır:
- Fit (örtüşme): Süreç ERP’nin standart akışıyla, en fazla konfigürasyonla karşılanıyor. Buraya düşen her madde, projenin en ucuz ve en güvenli parçasıdır.
- Gap (boşluk): Standart akış ihtiyacı karşılamıyor. Burada karar verilmesi gerekir — süreci sisteme mi uyduracaksınız, sistemi sürece mi?
- Kısmi örtüşme: Standart akış işin çoğunu görüyor ama bir adım eksik. Genellikle küçük bir konfigürasyon ya da ara çözümle kapanır.
Analizin değeri, “boşluk” kovasına düşen maddeleri görünür kılmasında ve her birine bir maliyet–değer etiketi yapıştırmasında yatar. Bir gap’i kapatmanın kararını duyguyla değil, o etiketle verirsiniz.
Her boşluğu kapatmak zorunda değilsiniz
Fit-gap tablosundaki her satır için sorulacak dört soru vardır:
- Bu farklılık müşteriye, mevzuata ya da gelire dokunuyor mu, yoksa sadece bir alışkanlık mı?
- Standart süreci benimsersek ne kaybederiz? Gerçekten bir şey kaybeder miyiz?
- Bu boşluğu kapatmanın kod maliyeti, sağlayacağı faydaya değer mi?
- Aynı sonuca konfigürasyon, bir rapor ya da küçük bir süreç değişikliğiyle ulaşabilir miyiz?
Bu dört soruyu geçebilen boşluklar gerçek özelleştirme adaylarıdır. Geçemeyenler ise çoğu zaman “standart sürece uyalım” kararıyla kapanır — ve bu, taviz değil, kazançtır.
Ne Zaman Özelleştirmeli, Ne Zaman Standarda Uymalı?
Kesin bir formül yok; ama pratikte tekrar eden bir ayrım var.
Özelleştirmenin haklı olduğu yerler, işletmeyi rakibinden ayıran, pazarda fark yaratan süreçlerdir. Kendine özgü bir fiyatlandırma mantığınız, sektörünüze özel bir izlenebilirlik zorunluluğunuz ya da müşteri deneyiminizi belirleyen bir akışınız varsa, bunu standarda feda etmek stratejik bir hatadır. Burada özelleştirme bir maliyet değil, yatırımdır.
Standarda uymanın daha akıllıca olduğu yerler ise arka ofisin sıradan, herkeste benzer işleyen süreçleridir: genel muhasebe kayıtları, standart satınalma onayları, temel stok hareketleri, İK’nın rutin işlemleri. Bu alanlarda “biz farklı yaparız” iddiası, çoğu zaman sadece eski sistemin kısıtlarından doğmuş bir alışkanlıktır. Standart akış, yıllarca binlerce işletmede olgunlaşmış bir en iyi uygulamayı hazır sunar; onu benimsemek hem hızlı hem güvenlidir.
Özelleştirmeye “evet” demeden önce, sık atlanan gizli maliyetlerini hatırlamakta fayda var. Bu kalemler ERP’nin toplam sahip olma maliyetini doğrudan büyütür:
- Her özel geliştirme, her sürüm yükseltmesinde yeniden test edilmesi gereken bir yüktür.
- Özelleştirmeler dokümante edilmezse, onu yazan kişi ayrıldığında “kimse dokunmaya cesaret edemeyen” bir kara kutuya dönüşür.
- Standart akıştan uzaklaştıkça, sağlayıcının hazır iyileştirmelerinden ve yeni özelliklerinden yararlanmak zorlaşır.
- Aşırı özelleştirilmiş bir sistem, zamanla bakımı pahalı, göçü zor bir yapıya dönüşür.
Kapsam Kayması (Scope Creep) Nasıl Önlenir?
Fit-gap analizi projenin başında ne yapılacağını belirler; kapsam yönetimi ise o kararı proje boyunca ayakta tutar. Kapsam kayması, tek tek bakıldığında hepsi makul görünen küçük eklerin toplamda projeyi süre ve bütçe olarak taşırmasıdır. “Küçük bir şey daha” cümlesi, ERP projelerinin en sinsi bütçe düşmanıdır.
Kaymayı önleyen birkaç somut alışkanlık:
- Yazılı kapsam ve imzalı gereksinim listesi. Neyin dahil, neyin hariç olduğunu baştan yazın. Sözlü mutabakat, ay sonunda herkesin farklı hatırladığı bir tartışmaya dönüşür.
- Değişiklik talep süreci. Her yeni istek, etkisi (süre, maliyet, risk) değerlendirilmeden sisteme girmesin. Talep reddedilmek zorunda değil; ama bilinçli bir kararla, görünür bir bedelle kabul edilmeli.
- Faz ayrımı. “Olmazsa olmaz” ile “iyi olur”u ayırın. İkincil istekleri ikinci faza taşımak, canlıya çıkışı geciktirmemenin en etkili yoludur.
- Tek bir kapsam sahibi. Her talebi kimin önceliklendireceği belli olsun. Herkesin bir şey ekleyebildiği projede kimse “hayır” diyemez.
Kapsamı dar ve net tutmanın en büyük ödülü, canlıya erken çıkmaktır. Erken çıkan bir sistem gerçek kullanımla test edilir; ikinci faz istekleri de artık varsayımlara değil, sahadan gelen gerçek geri bildirime dayanır.
MVP Yaklaşımı: Önce Çalışsın, Sonra Zenginleşsin
Deneyimli uygulama ekipleri, ilk canlıya çıkışı mümkün olan en yalın haliyle kurgular. Amaç, işletmenin uçtan uca çalışabildiği asgari bütünlüğü (bir tür minimum uygulanabilir kurulum) en kısa sürede devreye almaktır. Süslü ekranlar, ileri seviye özel raporlar ve “keşke şu da olsa” istekleri bilinçli olarak sonraya bırakılır.
Bu yaklaşımın mantığı basittir: bir süreci gerçekten kullanmadan, o sürecin nasıl özelleştirilmesi gerektiğini kimse tam olarak bilemez. Projenin başında masabaşında yazılan pek çok özelleştirme isteği, sistem üç ay kullanıldıktan sonra ya gereksiz çıkar ya da bambaşka bir biçim alır. Önce standartla başlamak, bu boşa gidecek geliştirmelerden korur.
QERA’nın anahtar teslim kurulum modeli tam da bu felsefeyle örtüşür: standart, hazır çalışan süreçlerle hızlıca canlıya alınır; gerçek özelleştirme ihtiyaçları ise sistem çalışırken, somut kullanım verisiyle netleştikçe ele alınır. Kullanıcı sayısındaki büyümenin sürpriz maliyet çıkarmaması da (belirli bir kullanıcı bandına kadar ek kullanıcı maliyeti olmaması) kapsamı büyüme baskısı olmadan planlamayı kolaylaştırır.
Fit-Gap Analizini Kim, Nasıl Yürütmeli?
İyi bir fit-gap çalışması masabaşında değil, işin yapıldığı yerde ortaya çıkar. Sağlıklı bir çalışmanın bileşenleri:
- Süreç sahipleri masada olmalı. Satınalmayı fiilen yapan, depoda sayımı yürüten, faturayı kesen kişiler; yönetici tahmini değil, gerçek akış anlatılmalı.
- Mevcut süreç dürüstçe çıkarılmalı. “Kâğıt üstünde şöyle olması gerekir” değil, “gerçekte şöyle oluyor” haritalanmalı. İstisnalar ve arka kapılar genellikle en çok özelleştirme talebi doğuran yerlerdir.
- Her boşluğa bir sahip ve karar atanmalı. Açık kalan hiçbir gap, “sonra bakarız” diye bekletilmemeli; bekleyen boşluklar canlıya çıkışta panik özelleştirmelerine dönüşür.
- Kararlar belgelenmeli. Hangi boşluğun neden standarda uydurulduğu, hangisinin neden özelleştirildiği yazılı kalmalı. Bu belge, bir yıl sonra “bunu neden böyle yapmıştık?” sorusunun cevabıdır.
Bu çalışmayı, ürünün standart yeteneklerini gerçekten bilen bir danışmanla yürütmek kritik. Standardı bilmeyen bir ekip, aslında hazır gelen bir özelliği “boşluk” sanıp gereksiz yere özelleştirebilir. Sağlam bir ana veri temeli ve gerçekçi bir kurulum planı da fit-gap kararlarının sağlıklı uygulanmasının ön koşuludur; nitekim ERP projelerinin başarısız olma nedenlerinin başında belirsiz kapsam ve kontrolsüz özelleştirme gelir.
Sıkça Sorulan Sorular
Hiç özelleştirme yapmadan ERP kurmak mümkün mü?
Küçük ve süreçleri standarda yakın işletmelerde büyük ölçüde mümkündür; konfigürasyonla şaşırtıcı kadar çok ihtiyaç karşılanır. Ancak sektöre özgü zorunlulukları ya da farklılaştırıcı süreçleri olan işletmelerde sınırlı, iyi gerekçelendirilmiş özelleştirmeler genellikle kaçınılmazdır. Hedef “sıfır özelleştirme” değil, “yalnızca gerçekten değer katan özelleştirme” olmalıdır.
Özelleştirme sürüm güncellemelerini gerçekten engeller mi?
İyi tasarlanmış, sağlayıcının önerdiği yöntemlerle yapılmış özelleştirmeler güncellemeyi tümüyle engellemez ama her yükseltmede yeniden test yükü getirir. Standart çekirdeğe dokunmadan, ayrık ve dokümante edilmiş biçimde yapılan özelleştirmeler bu yükü en aza indirir. Bulut tabanlı, güncellemeleri merkezî yürüyen sistemlerde standarda yakın kalmak bu açıdan ek avantaj sağlar.
Fit-gap analizi ne kadar sürer?
İşletmenin büyüklüğüne ve süreç sayısına göre değişir; birkaç günlük yoğun atölye çalışmalarından birkaç haftaya kadar uzayabilir. Süreyi belirleyen asıl etken, süreç sahiplerinin çalışmaya ayırabildiği zaman ve mevcut süreçlerin ne kadar net tanımlı olduğudur. Aceleye getirilen bir fit-gap, projenin ilerleyen aylarında çok daha pahalı sürprizlere yol açar.
Kapsamı dar tutarsak eksik bir sistemle mi kalırız?
Hayır. Dar kapsam, “eksik sistem” değil, “önce en kritik işi eksiksiz yapan sistem” demektir. İkincil ihtiyaçlar ortadan kalkmaz; yalnızca ikinci faza taşınır ve orada gerçek kullanım verisiyle, çoğu zaman ilk düşünülenden daha isabetli biçimde ele alınır.
Standart süreç bizim çalışma biçimimize uymuyorsa ne yapmalı?
Önce şu soruyu net yanıtlayın: bu farklılık gerçek bir iş gereksinimi mi, yoksa eski sistemin dayattığı bir alışkanlık mı? Gerçek bir gereksinimse özelleştirme haklıdır. Alışkanlıksa, standart akışı denemek çoğu zaman süreci sadeleştirir. Kararı, fit-gap tablosundaki maliyet–değer etiketine bakarak verin.
Özelleştirme Kararlarınızı Sağlam Zemine Oturtun
Bir ERP projesinin uzun vadeli maliyetini ve esnekliğini belirleyen, hangi menünün nerede olduğu değil; hangi isteğin özelleştirileceğine, hangisinin standarda uydurulacağına nasıl karar verdiğinizdir. Fit-gap analizi bu kararı duygudan çıkarıp veriye bağlar; kapsam yönetimi ise o kararı proje bitene kadar korur.
QERA’yı işletmenizin gerçek süreçleri üzerinde görmek, standardın nerede yettiğini ve nerede gerçekten özelleştirme gerektiğini birlikte netleştirmek isterseniz, QERA ERP çözümünü inceleyebilir ya da doğrudan ücretsiz demo talep ederek kendi fit-gap sorularınızı ekranda test edebilirsiniz.
