Выбор ERP: готовый пакет или заказная система? 12 вопросов перед решением

Bir işletme "ERP'ye geçmeliyiz" dediğinde aslında iki ayrı karar verir: hangi süreçlerin dijitalleşeceği ve bu süreçlerin hangi yazılım modeliyle yönetileceği. İlk karar iş analizidir; ikincisi ise hazır bir paket ile özel geliştirilmiş bir sistem arasındaki seçimdir. Bu yazıda ikinci karara odaklanıyor ve her iki yolun gerçek maliyetlerini, risklerini ve avantajlarını yan yana koyuyoruz.

Önce süreç, sonra yazılım

ERP seçiminde en sık yapılan hata, yazılım demolarına süreçler netleşmeden başlamaktır. Demo ekranları etkileyicidir; ancak sizin satın alma onay zinciriniz, şube yapınız veya döviz bazlı fiyatlandırmanız o ekranlarda yoksa, uyarlama maliyeti teklifin görünmeyen kısmında saklanır. Bu nedenle keşif aşamasında şu üç belgeyi hazırlamanızı öneririz:

• Süreç haritası: Talepten faturaya, işe alımdan bordroya uçtan uca akışlar ve her adımdaki onay yetkisi.
• Veri envanteri: Hangi veriler nerede tutuluyor (muhasebe programı, Excel, e-posta), hangileri "tek doğru kaynak" olmalı.
• Entegrasyon listesi: Bankalar, e-fatura sağlayıcıları, muhasebe yazılımı, e-ticaret kanalları ve SMS/e-posta servisleri.

Hazır paketin güçlü ve zayıf yanları

Hazır ERP paketleri, standart süreçleri olan işletmeler için hızlı bir başlangıç sunar. Muhasebe, stok ve temel satın alma modülleri olgunlaşmıştır; yasal raporlama gereksinimleri çoğunlukla üretici tarafından güncellenir. Zayıf yanı, işletmenin kendine özgü süreçlerinin pakete uydurulmak zorunda kalmasıdır. "Paket böyle çalışıyor" cümlesi, bir süre sonra süreçlerin yazılıma göre şekillendiği bir yapıya dönüşebilir.

Özel sistemin güçlü ve zayıf yanları

Özel geliştirilen bir sistem, süreçleri olduğu gibi modellemenize ve veri modelinin tamamen size ait olmasına imkân verir. Çok şirketli organizasyonlar, şantiye veya şube bazlı yetkilendirme, sektöre özel iş emri akışları gibi ihtiyaçlar burada daha doğal karşılanır. Zayıf yanı ise disiplin gerektirmesidir: analiz, mimari, test ve bakım süreçleri sahiplenilmezse "sürekli geliştirilen ama hiç bitmeyen" bir projeye dönüşebilir.

Doğru soru "hangisi daha iyi" değil; "hangi süreçlerim standart, hangileri bizi farklılaştırıyor" sorusudur. Standart olanı paketten, farklılaştıranı özel geliştirmeden almak çoğu zaman en dengeli yoldur.

Karar vermeden önce sorulacak 12 soru

1. Süreçlerimizin yüzde kaçı sektör standardı, yüzde kaçı bize özgü?
2. Birden fazla şirket, şube veya para birimiyle çalışıyor muyuz?
3. Onay zincirlerimiz rol bazlı mı, kişi bazlı mı?
4. Verinin sahibi kim olacak; sözleşme bittiğinde veritabanını alabiliyor muyuz?
5. Yasal raporlama (e-fatura, e-defter, bordro mevzuatı) kim tarafından güncellenecek?
6. Mevcut muhasebe programıyla entegrasyon zorunlu mu, yoksa yerine mi geçecek?
7. Saha ekipleri (şantiye, depo, servis) sisteme mobil cihazdan erişecek mi?
8. Yetkilendirme veritabanı seviyesinde mi uygulanıyor, yoksa yalnızca arayüzde mi?
9. Denetim kaydı (kim, ne zaman, neyi değiştirdi) tutuluyor mu?
10. Yedekleme ve geri yükleme sorumluluğu kimde?
11. Lisans ve bakım maliyeti üç yıl sonra ne olacak?
12. Yazılımı geliştiren ekip değişirse sistem belgelenmiş durumda mı?

Toplam sahip olma maliyetini doğru hesaplamak

Her iki modelde de ilk teklif, toplam maliyetin yalnızca bir kısmıdır. Hazır paketlerde kullanıcı başı lisans, modül ekleme ve uyarlama danışmanlığı; özel sistemlerde ise bakım, sunucu altyapısı ve yeni özellik geliştirme bütçesi hesaba katılmalıdır. Karşılaştırmayı aynı zaman ufku (örneğin üç veya beş yıl) üzerinden yapmak, yanıltıcı sonuçları önler. Burada verebileceğimiz tek genel kural şudur: hangi yolu seçerseniz seçin, veri taşıma ve eğitim maliyetini küçümsemeyin.

Hibrit yaklaşım: ikisinin iyi yanlarını birleştirmek

Pratikte en sık karşılaştığımız senaryo hibrit yapıdır. Örnek olarak: resmi muhasebe mevcut muhasebe programında kalır, operasyonel süreçler (satın alma talepleri, zimmet, puantaj, hakediş, iş emirleri) özel geliştirilen sistemde yönetilir ve iki sistem arasında planlı veri aktarımı kurulur. Bu yaklaşım, yasal raporlama yükünü uzman yazılıma bırakırken işletmenin kendine özgü süreçlerini kısıtlamadan modellemeye izin verir.

Cy Logic'in yaklaşımı

Biz her projeye keşif ve analizle başlıyoruz; hazır bir paketin yeterli olacağı durumlarda bunu açıkça söylüyoruz. Özel sistem geliştirdiğimizde ise modüler mimari, PostgreSQL üzerinde satır bazlı yetkilendirme ve denetim kayıtlarını standart bileşen olarak ele alıyoruz. Amaç, işletmenin büyüdükçe yeniden yazılmak zorunda kalmayan bir dijital çatıya sahip olmasıdır.

Sık yapılan üç hata

1. Demo ile karar vermek

Demo ortamları temiz veriyle ve ideal senaryoyla hazırlanır. Sizin gerçek veriniz eksik alanlar, mükerrer cari kartlar ve istisnalarla doludur. Karar vermeden önce, kendi verinizden küçük bir örnekle (örneğin bir aylık satın alma talebi ve bir şantiyenin puantajı) pilot çalışma isteyin. Pilotun amacı yazılımı beğenmek değil, uyarlama ihtiyacının gerçek boyutunu görmektir.

2. Entegrasyonu sona bırakmak

"Önce ERP'yi kuralım, bankayı ve e-faturayı sonra bağlarız" yaklaşımı, canlıya geçişten sonra aylarca süren çift kayıt dönemine yol açar. Entegrasyon listesi ve her entegrasyonun teknik gereksinimi (API erişimi, test ortamı, sözleşme) seçim aşamasında netleşmelidir.

3. Kullanıcıyı sona bırakmak

ERP'yi her gün kullanacak olanlar depo sorumlusu, satın alma uzmanı ve şantiye amiridir; yönetim değil. Seçim sürecine bu kişilerin katılmaması, "sistem var ama Excel'e devam ediyoruz" sonucunu doğurur.

Örnek bir değerlendirme çerçevesi

Aşağıdaki tablo kurgusal bir örnektir; ağırlıklar işletmeye göre değişir. Amaç, kararı duyguyla değil kayıtlı ölçütlerle vermektir.

ÖlçütSoruHazır paketÖzel sistem Süreç uyumuSüreçlerimiz değişmeden modellenebiliyor mu?KısmenEvet Yasal raporlamaMevzuat güncellemelerini kim yapar?ÜreticiEntegre muhasebe programı Veri sahipliğiVeritabanını alabilir miyiz?Sözleşmeye bağlıEvet Başlangıç hızıİlk modül ne zaman kullanılır?HızlıKademeli Uzun vadeli maliyetÜç yıl sonra ne ödüyoruz?Lisans + uyarlamaBakım + geliştirme

Geçiş planı: ne sırayla?

Hangi modeli seçerseniz seçin, geçişin sırası aynıdır: önce ana veriler (cari, stok kartları, personel), sonra günlük işlemlerin en yoğun olduğu tek bir süreç, ardından onay zincirleri, en son raporlama. Ana veri temizliği, projelerin en çok küçümsenen ve en çok zaman alan adımıdır; mükerrer cari kartlar ve tutarsız stok kodları yeni sisteme taşındığında, yeni sistem eski sorunları daha hızlı üretir.

Kıbrıs ve Türkiye bağlamında notlar

Türkiye'de e-fatura, e-arşiv ve e-defter yükümlülükleri, muhasebe tarafının Gelir İdaresi Başkanlığı ile uyumlu bir yazılımda kalmasını neredeyse zorunlu kılar; bu da hibrit modeli öne çıkarır. KKTC'de faaliyet gösteren işletmelerde ise farklı para birimleriyle çalışma ve Türkiye'deki grup şirketleriyle konsolidasyon ihtiyacı sık görülür; özel sistemin çok şirketli ve çok para birimli yapısı burada belirleyici olabilir. Her iki durumda da hukuki ve mali gereksinimleri mali müşavirinizle doğrulayın; yazılım kararı bu gereksinimlerin üzerine kurulur.

ERP kararınızı birlikte değerlendirmek isterseniz, süreç haritanızın taslağıyla bize ulaşabilirsiniz; ilk görüşmede en çok fayda sağlayan belge odur.