Her özelleştirme talebi maliyet ve güncelleme riski demektir. Ne zaman gerçekten gerektiğini anlatıyoruz.
ERP projelerinde en sık duyulan cümle şudur: "Ama biz böyle çalışıyoruz." Bu cümlenin arkasından gelen her talep, bir özelleştirme isteğidir.
Bazıları haklıdır; çoğu değildir. Ayrımı yapmak, projenin maliyetini ve geleceğini belirler.
Yapılandırma ile özelleştirme farkı
| Yapılandırma | Özelleştirme | |
|---|---|---|
| Ne yapılır | Ayarlarla uyarlama | Kod değişikliği/geliştirme |
| Maliyet | Düşük | Yüksek |
| Süre | Kısa | Uzun |
| Güncelleme etkisi | Yok | Her güncellemede test/uyarlama |
| Bakım | Standart | Ek bakım maliyeti |
| Bağımlılık | Düşük | Geliştirene bağımlılık |
Kural: yapılandırmayla çözülebilen hiçbir şey özelleştirilmemelidir.
Özelleştirmenin gerçek maliyeti
Teklifte görünen geliştirme bedeli, toplam maliyetin yalnız bir parçasıdır:
- Analiz ve tasarım
- Geliştirme
- Test
- Her sürüm yükseltmesinde yeniden test ve uyarlama
- Dokümantasyon
- Geliştiren kişi/firma değişirse devir maliyeti
- Hata durumunda sorumluluk belirsizliği
Dördüncü madde en pahalı olanıdır ve yıllara yayılır. Aşırı özelleştirilmiş sistemler zamanla güncellenemez hâle gelir; güvenlik açıkları birikir ve yeni özelliklerden yararlanılamaz.
Karar filtresi
Her özelleştirme talebini şu sorulardan geçirin:
- Bu bir yasal zorunluluk mu? (Evet ise yapılır.)
- Rekabet avantajımızın kaynağı mı? (Evet ise değerlendirilir.)
- Yapılandırmayla çözülebilir mi? (Evet ise özelleştirme yapılmaz.)
- Standart süreçle çalışmanın maliyeti ne? (Ölçün.)
- Bu süreç gerçekten en iyi hâli mi? (Genelde değildir.)
- Rapor ya da ek alanla çözülebilir mi?
- Faz 2'ye ertelenebilir mi?
Beşinci soru en değerlisidir: ERP, sürecin gözden geçirilmesi için bir fırsattır. "Biz böyle çalışıyoruz" cümlesinin arkasında çoğu zaman "eski sistemimiz bunu yapamadığı için böyle çalışıyoruz" gerçeği vardır.
Özelleştirmenin haklı olduğu durumlar
- Yasal ve sektörel zorunluluklar
- Rekabet avantajı yaratan gerçekten özgün süreçler
- Müşteriye özel raporlama ve belge formatları
- Kritik entegrasyonlar
- Standart çözümün ciddi verimlilik kaybı yaratacağı durumlar
Özelleştirme yerine alternatifler
| Talep | Alternatif |
|---|---|
| "Bu alan da olsun" | Özel alan tanımı (yapılandırma) |
| "Bu rapor farklı olsun" | Rapor tasarımcısı ya da dışa aktarım |
| "Bu onay akışı özel" | İş akışı motoruyla yapılandırma |
| "Belge formatı farklı" | Şablon düzenleme |
| "Bu hesaplama bize özel" | Formül alanı ya da harici hesaplama |
| "Şu sistemle konuşsun" | Standart API/entegrasyon aracı |
Özelleştirme yapılacaksa
- Standart alanların üzerine yazmayın; ayrı yapıda tutun.
- Belgeleyin (ne, neden, nasıl).
- Kaynak kod ve dokümantasyonu teslim alın.
- Sürüm yükseltmelerinde ne olacağını sözleşmede netleştirin.
- Test senaryolarını yazın.
- Mümkünse standart genişletme noktalarını kullanın.
- Özelleştirme envanteri tutun.
Son madde uzun vadede kurtarıcıdır: hangi özelleştirmelerin var olduğunu bilmeyen kurumlar, sürüm yükseltmesinde felç olur.
Özelleştirme envanteri
Her kayıt için tutulacaklar:
- Ne yapıyor
- Neden yapıldı (iş gerekçesi)
- Ne zaman ve kim yaptı
- Hangi modülleri etkiliyor
- Test senaryosu
- Hâlâ kullanılıyor mu
Son madde için yılda bir gözden geçirme yapın: kullanılmayan özelleştirmeler kaldırıldığında güncelleme yükü azalır.
Yaygın hata: standart süreci hiç denememek
Birçok özelleştirme, standart çözüm denenmeden talep edilir. Pratik yöntem:
- Önce standart süreçle çalışın.
- Gerçek zorluğu ölçün (kaç dakika, kaç kişi, kaç kez).
- Maliyeti hesaplayın.
- Özelleştirme maliyetiyle karşılaştırın.
- Sonra karar verin.
Bu yöntem, talep listesini genelde belirgin biçimde kısaltır.
Özet
Yapılandırmayla çözülebilen hiçbir şeyi özelleştirmeyin. Her talebi yasal zorunluluk, rekabet avantajı ve alternatif çözüm filtresinden geçirin. Özelleştirme yapacaksanız belgeleyin, envanter tutun ve sürüm yükseltmesinde ne olacağını sözleşmede netleştirin. Standart süreci denemeden özelleştirme talep etmeyin.
Yorumlar (0)
Henüz yorum yok — ilk yorumu siz yazın.
Yorum yaz