ERP Seçimi: İhtiyaç Analizinden Sözleşmeye Rehber

ERP seçimi, bir şirketin yalnızca yeni yazılım satın alması değil; finans, satın alma, stok, üretim ve operasyon süreçlerini nasıl yöneteceğine karar vermesidir. Yanlış sistem tercihi beklenmeyen maliyetlere, entegrasyon sorunlarına ve çalışanların yeni yazılımı benimsemekte zorlanmasına neden olabilir.

2026 yılında bulut tabanlı çözümler, yapay zekâ destekli özellikler ve API entegrasyonları ERP değerlendirmelerini daha kapsamlı hale getiriyor. Ancak başarılı bir kararın temelinde teknoloji trendleri değil, işletmenin gerçek ihtiyaçları bulunur.

Bu rehberde ERP ihtiyaç analizinden tedarikçi değerlendirmesine, ürün demolarından toplam sahip olma maliyetine ve sözleşme müzakerelerine kadar izlenmesi gereken adımları ele alıyoruz. Amaç, karar vericilerin karşılaştırılabilir verilerle ilerlemesini ve uzun vadeli riskleri satın alma öncesinde belirlemesini sağlamaktır.

1. ERP Seçimi Öncesinde İşletme İhtiyaçları Nasıl Belirlenir?

ERP projelerinde en kritik aşama, hangi yazılımın satın alınacağını araştırmadan önce işletmenin hangi problemleri çözmek istediğini belirlemektir. Mevcut iş süreçleri anlaşılmadan hazırlanan gereksinim listeleri, gerçek ihtiyaçlar yerine departmanların alışkanlıklarını yansıtabilir.

Örneğin bir dağıtım şirketinde stok tutarsızlıkları yaşanıyorsa sorun yalnızca mevcut yazılımın yetersizliği olmayabilir. Depolar arasındaki transferlerin geç kaydedilmesi, ürün kodlarının standart olmaması veya manuel veri girişleri de aynı sonucu oluşturabilir.

Mevcut Süreçlerin Haritalanması

İlk adım, işletmenin mevcut durumunu (As-Is) belgelemek ve hedeflenen süreçleri (To-Be) tanımlamaktır. Bu çalışma yalnızca IT ekibiyle değil, süreçleri günlük olarak kullanan çalışanlarla gerçekleştirilmelidir.

• Finans: Muhasebe, bütçe yönetimi, tahsilat, ödeme ve finansal raporlama süreçleri.
• Satın alma: Talep, teklif toplama, sipariş, teslimat ve tedarikçi değerlendirme adımları.
• Stok ve lojistik: Depo hareketleri, lot ve seri numarası takibi, sevkiyat ve envanter doğruluğu.
• Satış: Teklif, sipariş, fiyatlandırma, müşteri hesapları ve faturalama.
• Üretim: Malzeme ihtiyaç planlaması, iş emirleri, kapasite ve kalite yönetimi.
• Yönetim: Raporlama, onay mekanizmaları, denetim izleri ve performans göstergeleri.

Departmanlar arasındaki veri akışı da incelenmelidir. Sipariş bilgisinin satıştan muhasebeye aktarılması sırasında manuel işlemler yapılıyorsa bu durum hem hata riski hem de operasyonel yük oluşturur.

Süreçlerin yeniden tasarlanması gereken işletmelerde BPM ve süreç danışmanlığı yaklaşımı, yazılım gereksinimlerini belirlemeden önce darboğazların ve gereksiz onay adımlarının tespit edilmesini kolaylaştırır.

Gereksinimleri Önceliklendirme

Her talebi zorunlu özellik olarak tanımlamak, aday sistemlerin gereksiz yere elenmesine veya maliyetli özelleştirmelere yol açabilir. Gereksinimleri dört kategoride değerlendirmek daha sağlıklı bir yaklaşım sunar.

• Olmazsa olmaz: Sistem canlıya alınmadan karşılanması gereken kritik ihtiyaçlar.
• Önemli: Operasyonel verimliliği artıran ancak alternatif yöntemlerle yönetilebilen ihtiyaçlar.
• Tercih edilen: Kullanım kolaylığı veya ek verimlilik sağlayan özellikler.
• Kapsam dışı: İlk uygulama aşamasında ihtiyaç duyulmayan fonksiyonlar.

Her gereksinim için bir iş sahibi, kabul kriteri ve mümkünse ölçülebilir başarı göstergesi belirlenmelidir. Böylece değerlendirme toplantılarında kişisel tercihler yerine doğrulanabilir sonuçlar konuşulabilir.

2. ERP Yazılımı Türleri ve Dağıtım Modellerinin Karşılaştırılması

İhtiyaç analizi tamamlandığında ikinci karar, işletmeye uygun çözüm yaklaşımını belirlemektir. Hazır ERP ürünleri, sektörel çözümler ve işletmeye özel geliştirilen sistemler farklı avantajlar sunar.

Tek bir yaklaşım bütün şirketler için ideal değildir. Seçim; süreç karmaşıklığına, mevcut teknoloji altyapısına, mevzuat gereksinimlerine ve işletmenin değişim kapasitesine bağlıdır.

Hazır ERP ve Özel Geliştirme Karşılaştırması

Hazır çözümler yaygın iş süreçlerini standartlaştırmak isteyen işletmeler için avantaj sağlayabilir. Ancak çok sayıda özel iş kuralı bulunan şirketlerde uyarlama maliyetlerinin önceden hesaplanması gerekir.

Özel geliştirme değerlendirmelerinde ise kaynak kodu sahipliği, test otomasyonu, sürdürülebilir mimari ve geliştirici bağımlılığı mutlaka sorgulanmalıdır. Bu yaklaşım hakkında ERP yazılım geliştirme kapsamının incelenmesi, hazır ürünle özel çözüm arasındaki teknik farkların değerlendirilmesine yardımcı olabilir.

Bulut, Şirket İçi ve Hibrit ERP

Bulut ERP çözümlerinde altyapı işletimi büyük ölçüde hizmet sağlayıcının sorumluluğunda olabilir. Şirket içi kurulumlarda ise altyapı yönetimi, güncelleme ve kapasite planlaması için daha fazla kurum içi kaynak gerekebilir.

Hibrit mimariler, belirli sistemlerin şirket ortamında kalmasını ve diğer bileşenlerin bulut servisleriyle çalışmasını sağlayabilir. Ancak farklı ortamlar arasındaki bağlantı, erişim yönetimi ve veri tutarlılığı ayrıca değerlendirilmelidir.

Bulut modelinin otomatik olarak daha güvenli veya daha ekonomik olduğu varsayılmamalıdır. Veri yerleşimi, sözleşmesel yükümlülükler, hizmet sürekliliği ve toplam işletme maliyeti birlikte incelenmelidir.

3. ERP Tedarikçisi Nasıl Seçilir ve Teklifler Nasıl Değerlendirilir?

ERP tedarikçisi değerlendirmesi yalnızca ürün özellikleriyle sınırlı tutulmamalıdır. Uygulama ekibinin deneyimi, destek yaklaşımı, geliştirme politikası ve finansal sürdürülebilirlik de karar üzerinde etkilidir.

İlk aşamada kısa bir aday listesi oluşturulmalı ve bütün adaylara aynı gereksinim dokümanı gönderilmelidir. Böylece tekliflerin karşılaştırılabilir olması sağlanır.

RFI ve RFP Dokümanlarının Hazırlanması

RFI (Request for Information), potansiyel tedarikçiler hakkında ön bilgi toplamak için kullanılır. RFP (Request for Proposal) ise belirlenmiş gereksinimlere karşılık kapsamlı teknik ve ticari teklif alınmasını amaçlar.

İyi hazırlanmış bir RFP aşağıdaki bilgileri içermelidir:

• İşletmenin organizasyon yapısı ve proje hedefleri.
• Kullanıcı sayıları, roller ve lokasyonlar.
• Zorunlu işlevsel ve teknik gereksinimler.
• Mevcut sistemler ve entegrasyon beklentileri.
• Aktarılacak verilerin kapsamı ve niteliği.
• Bilgi güvenliği ve mevzuat yükümlülükleri.
• Test, eğitim, canlı geçiş ve destek beklentileri.
• Teklifin hangi maliyet kalemlerini kapsaması gerektiği.

Tedarikçilerden her gereksinimi standart özellik, yapılandırma, özel geliştirme, üçüncü taraf çözüm veya karşılanamıyor şeklinde sınıflandırmaları istenmelidir. Böylece ürünün mevcut yetenekleriyle henüz geliştirilmesi gereken işlevler ayrıştırılabilir.

Ağırlıklı Tedarikçi Puanlama Modeli

Karar sürecinde kullanılabilecek örnek bir değerlendirme modeli aşağıdaki gibidir. Ağırlıklar işletmenin önceliklerine göre değiştirilmelidir.

Her kriter 1 ile 5 arasında puanlanabilir. Ağırlıklı toplam, kriter puanının ilgili ağırlıkla çarpılması ve sonuçların toplanmasıyla hesaplanır.

Ancak kritik güvenlik veya mevzuat gereksinimlerini karşılamayan bir aday, toplam puanı yüksek olsa bile uygun kabul edilmemelidir. Zorunlu koşullar puanlamadan önce eleme kriteri olarak değerlendirilmelidir.

4. ERP Demo ve Pilot Uygulamalarında Nelere Dikkat Edilmeli?

Tedarikçi sunumları genellikle ürünün güçlü yönlerini gösterecek şekilde hazırlanır. Gerçek değerlendirme ise işletmenin kendi süreçlerini temsil eden senaryolarla yapılmalıdır.

Örneğin siparişten tahsilata uzanan bir senaryo hazırlanabilir. Bu senaryoda satış siparişinin oluşturulması, stok kontrolü, sevkiyat, faturalama ve muhasebe kaydı aynı süreç üzerinde gösterilmelidir.

Senaryo Tabanlı Demo Kontrol Listesi

1. İşlemi standart yetkilere sahip bir kullanıcı gerçekleştirebiliyor mu?
2. Departmanlar arasındaki veri aktarımı manuel müdahale gerektiriyor mu?
3. Hatalı veya eksik veri girildiğinde sistem nasıl davranıyor?
4. Onay süreçleri kurumun yetki yapısına uyarlanabiliyor mu?
5. Değişiklik geçmişi ve denetim kayıtları görüntülenebiliyor mu?
6. Raporlar ek geliştirme olmadan hazırlanabiliyor mu?
7. Mobil cihazlarda veya farklı lokasyonlarda kullanım yeterli mi?
8. Yüksek işlem hacmi altında performans nasıl doğrulanacak?

Demolara yalnızca yöneticilerin değil, sistemi günlük kullanacak çalışanların da katılması önemlidir. Kullanıcıların geri bildirimleri ekran tasarımı, işlem adımları ve eğitim ihtiyacı hakkında erken uyarılar sağlayabilir.

Proof of Concept (PoC) Ne Zaman Gereklidir?

PoC, belirli bir teknik veya işlevsel gereksinimin uygulanabilirliğini sınırlı kapsamda doğrulayan çalışmadır. Özellikle karmaşık entegrasyonlar, özel fiyatlandırma kuralları veya yüksek hacimli işlemler söz konusuysa faydalıdır.

Örneğin ERP sisteminin mevcut e-ticaret platformuyla anlık stok senkronizasyonu yapması gerekiyorsa yalnızca API dokümantasyonunu incelemek yeterli olmayabilir. Gerçekçi test verileriyle gecikme, hata yönetimi ve yeniden deneme davranışları doğrulanmalıdır.

Bu aşamada sistem entegrasyonu gereksinimlerinin ayrıca analiz edilmesi, canlıya geçiş sonrasında oluşabilecek veri tutarsızlıklarını azaltabilir.

PoC için başarı kriterleri, süre, kapsam ve kullanılacak test ortamı önceden yazılı olarak belirlenmelidir. Başarısız bir testin hangi koşullarda tekrar edileceği de netleştirilmelidir.

5. ERP Toplam Sahip Olma Maliyeti ve Proje Riskleri

ERP yatırımlarında yalnızca başlangıç teklifine odaklanmak yanıltıcı olabilir. Toplam sahip olma maliyeti (TCO), sistemin belirlenen değerlendirme dönemi boyunca oluşturacağı doğrudan ve dolaylı giderleri kapsar.

Karşılaştırma için bütün adaylarda aynı zaman aralığı kullanılmalıdır. Örneğin beş yıllık değerlendirmede tek seferlik giderlerle yıllık tekrarlayan maliyetler ayrı hesaplanmalıdır.

Toplam Maliyete Dahil Edilmesi Gereken Kalemler

• Lisans ve abonelik: Kullanıcı, modül, işlem hacmi veya tüketim esaslı ücretlendirme.
• Uygulama hizmetleri: Analiz, yapılandırma, proje yönetimi ve danışmanlık.
• Özelleştirme: Standart ürün dışında geliştirilecek iş kuralları ve ekranlar.
• Veri taşıma: Temizleme, eşleştirme, dönüştürme ve doğrulama.
• Entegrasyon: Harici yazılımlar, API servisleri ve veri alışverişi altyapısı.
• Eğitim: Son kullanıcı, yönetici ve teknik ekip eğitimleri.
• Altyapı: Sunucu, depolama, yedekleme, ağ ve güvenlik hizmetleri.
• Bakım ve destek: Güncellemeler, destek paketleri ve olası ek hizmetler.
• İç kaynak maliyeti: Projede görev alan çalışanların ayıracağı zaman.
• Çıkış maliyeti: Veri dışa aktarımı, arşivleme ve başka sisteme geçiş gereksinimleri.

Maliyet analizinde kullanıcı sayısındaki artış, yeni şube açılması ve ek modül ihtiyaçları için alternatif senaryolar hazırlanmalıdır. Böylece büyümenin bütçe üzerindeki etkisi görülebilir.

Veri Kalitesi ve Değişim Yönetimi Riskleri

ERP geçişlerinde eski sistemden taşınan hatalı veriler yeni yazılımın güvenilirliğini doğrudan etkileyebilir. Mükerrer müşteri kayıtları, farklı ürün kodları ve eksik cari hesap bilgileri aktarım öncesinde temizlenmelidir.

Ayrıca çalışanların yeni süreçlere uyum sağlaması için eğitim planı hazırlanmalıdır. Proje başarısı yalnızca teknik kurulumla değil, kullanıcıların kritik işlemleri doğru gerçekleştirebilmesiyle değerlendirilmelidir.

Risk kayıtlarında her konu için olasılık, etki, sorumlu kişi ve azaltıcı aksiyon tanımlanmalıdır. Bu kayıtların proje boyunca düzenli güncellenmesi, yönetim ekibinin sorunları erken görmesine yardımcı olur.

6. ERP Sözleşmesi İmzalanmadan Önce Kontrol Edilecek Maddeler

Teknik değerlendirmede başarılı bulunan bir çözüm, sözleşme koşulları nedeniyle işletme için önemli riskler oluşturabilir. Bu nedenle satın alma, hukuk, bilgi güvenliği ve IT ekipleri sözleşmeyi birlikte incelemelidir.

Sözleşmenin temel amacı yalnızca teslimatın tanımlanması değil, tarafların sorumluluklarının ve olası anlaşmazlıkların nasıl yönetileceğinin açıkça belirlenmesidir.

Kapsam, Teslimat ve Kabul Kriterleri

Teklifte belirtilen özelliklerin sözleşmeye veya bağlayıcı eklerine aktarılması gerekir. Hangi gereksinimlerin standart ürünle, hangilerinin özel geliştirmeyle karşılanacağı açık olmalıdır.

Proje kilometre taşları, kabul testleri ve teslimat belgeleri tanımlanmalıdır. Ödemelerin yalnızca takvim tarihlerine değil, uygun olduğunda doğrulanabilir teslimatlara bağlanması değerlendirilebilir.

SLA, Veri Sahipliği ve Çıkış Planı

Hizmet Seviyesi Anlaşması (SLA), özellikle bulut tabanlı çözümlerde kritik önem taşır. Erişilebilirlik hedefleri, destek yanıt süreleri, olay öncelikleri ve hizmet kesintilerinde uygulanacak süreçler netleştirilmelidir.

İmzadan önce aşağıdaki konular yazılı olarak doğrulanmalıdır:

• Verilerin mülkiyeti, erişim hakları ve kullanım sınırları.
• Veri işleme rolleri, KVKK yükümlülükleri ve gerekli güvenlik tedbirleri.
• Yedekleme sıklığı, kurtarma noktası hedefi (RPO) ve kurtarma süresi hedefi (RTO).
• Planlı bakım ve beklenmeyen kesintilerde bildirim prosedürleri.
• Yazılım güncellemeleri ve sürüm değişikliklerinin özel geliştirmelere etkisi.
• Fiyat güncelleme yöntemi, yenileme ve fesih koşulları.
• Sözleşme sonunda verilerin hangi formatta ve sürede teslim edileceği.
• Veri silme, geçiş desteği ve üçüncü taraf bağımlılıklarının yönetimi.
• Destek kapsamı, eskalasyon prosedürü ve ek hizmet ücretlendirmesi.

Özellikle veri çıkış planının satın alma aşamasında hazırlanması önemlidir. Sistem değiştirmek gerektiğinde verilerin erişilebilir ve belgelenmiş formatlarda alınabilmesi, uzun vadeli tedarikçi bağımlılığını azaltır.

Sözleşmede belirsiz bırakılan sorumluluklar sonradan kapsam değişikliği ve ek maliyet tartışmalarına dönüşebilir. Bu nedenle teknik şartname ile ticari sözleşme arasında tutarlılık kontrolü yapılmalıdır.

7. ERP Projesi İçin Karar ve Canlıya Geçiş Planı

ERP seçimi tamamlandığında proje henüz başarılı sayılmaz. Seçilen çözümün işletmeye kontrollü şekilde aktarılabilmesi için uygulama yönetişimi ve canlıya geçiş planı hazırlanmalıdır.

Proje sponsoru, proje yöneticisi, süreç sahipleri ve teknik sorumluların karar yetkileri netleştirilmelidir. Kritik değişiklikler için onay mekanizması oluşturulmalı ve kapsam dışı taleplerin bütçe ile takvim üzerindeki etkisi değerlendirilmelidir.

Canlıya Geçiş Stratejileri

Tek seferde geçiş: Birden fazla modülün veya iş biriminin aynı dönemde yeni sisteme geçmesidir. Süreçler arası bütünlük avantajı sağlayabilir ancak operasyonel kesinti riski daha yüksek olabilir.

Aşamalı geçiş: Modüllerin, şirketlerin veya lokasyonların belirli sırayla devreye alınmasıdır. Riskin kontrollü dağıtılmasını sağlayabilir fakat geçici entegrasyon ve çift sistem yönetimi gerektirebilir.

Paralel çalışma: Eski ve yeni sistemlerin belirli süre birlikte çalıştırılmasıdır. Sonuçları karşılaştırma imkânı sunar ancak veri tutarlılığı ve operasyonel iş yükü dikkatle yönetilmelidir.

Hangi strateji seçilirse seçilsin, geri dönüş koşulları, kritik işlem testleri ve canlıya geçiş sonrasındaki yoğun destek dönemi önceden planlanmalıdır.

Yönetim İçin Son Karar Kontrol Listesi

1. İş hedefleri ve başarı göstergeleri yazılı olarak belirlendi mi?
2. Departmanların kritik gereksinimleri doğrulandı mı?
3. Aday sistemler aynı senaryolarla değerlendirildi mi?
4. Teknik entegrasyonlar ve veri aktarımı test edildi mi?
5. Toplam maliyet, büyüme senaryolarıyla karşılaştırıldı mı?
6. Güvenlik ve mevzuat gereksinimleri doğrulandı mı?
7. Sözleşme, SLA ve veri çıkış şartları incelendi mi?
8. Proje sorumluları, eğitim ve geçiş planı onaylandı mı?

Bu sorulardan kritik olanlarına yanıt verilemiyorsa imza öncesinde ek değerlendirme yapılmalıdır. Eksik bilgileri varsayımlarla kapatmak yerine belgelenmiş kararlar oluşturmak daha güvenilir bir yaklaşımdır.

Sık Sorulan Sorular

ERP seçimi ne kadar sürer?

Süre; şirketin büyüklüğüne, süreç karmaşıklığına, değerlendirilecek tedarikçi sayısına ve pilot çalışma gereksinimine bağlıdır. İhtiyaç analizi, teklif değerlendirme ve sözleşme aşamalarının ayrı planlanması gerekir. Yazılım seçimi ile sistemin tamamen devreye alınması farklı proje aşamalarıdır.

ERP seçiminde en önemli kriter nedir?

En önemli kriter, sistemin işletmenin kritik süreçlerini güvenilir ve sürdürülebilir biçimde karşılayabilmesidir. Fonksiyonel uyumun yanında entegrasyon, güvenlik, toplam maliyet ve tedarikçi yetkinliği birlikte değerlendirilmelidir. Tek bir kriter üzerinden karar verilmesi risklidir.

Küçük ve orta ölçekli işletmeler için bulut ERP uygun mudur?

Bulut ERP, altyapı işletim yükünü azaltmak isteyen KOBİ'ler için uygun olabilir. Ancak abonelik modeli, internet bağlantısına bağımlılık, veri işleme koşulları ve özelleştirme sınırları incelenmelidir. Karar, işletmenin operasyonel ihtiyaçlarına göre verilmelidir.

ERP yazılımı satın almak mı, özel geliştirmek mi mantıklı?

Standart süreçlere sahip işletmelerde hazır ERP çözümleri uygulama ve bakım açısından avantaj sunabilir. Çok özel iş kuralları veya benzersiz entegrasyon ihtiyaçları bulunan şirketlerde özel geliştirme değerlendirilebilir. Her iki yaklaşım için uzun vadeli maliyet ve sürdürülebilirlik analizi yapılmalıdır.

ERP sözleşmesinde hangi maddeler mutlaka bulunmalı?

Kapsam, teslimatlar, kabul kriterleri, ödeme koşulları, destek seviyeleri, veri sahipliği ve fesih hükümleri açıkça tanımlanmalıdır. Bulut çözümlerinde erişilebilirlik hedefleri, yedekleme ve veri çıkış şartları ayrıca önemlidir. Sözleşme imzalanmadan önce hukuk ve teknik ekiplerin ortak inceleme yapması önerilir.

Sonuç: Doğru ERP Seçimi Kontrollü Bir Karar Sürecidir

Başarılı bir ERP seçimi, en fazla özelliğe sahip yazılımı bulmaktan çok işletmenin hedeflerine uygun, yönetilebilir ve sürdürülebilir bir çözümü belirlemektir. İhtiyaç analizi, senaryo tabanlı demo, teknik doğrulama, maliyet karşılaştırması ve sözleşme kontrolü birbirini tamamlayan aşamalardır.

2026 yılında ERP sistemlerinin bulut servisleri, otomasyon ve yapay zekâ çözümleriyle daha fazla bütünleşmesi, entegrasyon mimarisi ve veri yönetişiminin önemini artırmaktadır. Bu nedenle yalnızca bugünkü ihtiyaçları değil, gelecekteki büyüme ve değişim senaryolarını da değerlendirmek gerekir.

Tekno Danışman, işletmelerin ERP ihtiyaçlarını teknik ve operasyonel açıdan değerlendirmesine yönelik danışmanlık yaklaşımı sunar. Mevcut süreçlerinizi analiz etmek, çözüm alternatiflerini karşılaştırmak ve teknoloji yatırımınız için uygulanabilir bir yol haritası oluşturmak istiyorsanız Tekno Danışman ile iletişime geçebilirsiniz.