Burada
Tüm yazılar
Rehber8 dakika okuma

ERP İhtiyaç Analizi: Gereksinim Listesi Nasıl Hazırlanır?

ERP seçimi demo salonunda değil, kâğıt üzerindeki gereksinim listesinde kazanılır ya da kaybedilir. Zorunlu, gerekli ve istenen ayrımını, süreç haritasını ve satıcıya verilecek formatı adım adım anlatıyoruz.

EB
Erp Burada Ekibi
Erp Burada Editörlüğü
Paylaş

Çoğu ERP seçimi bir ürün listesiyle başlar: hangi yazılımlar var, hangisi tanıdık, hangisi ucuz. Oysa doğru sıra tersidir. Önce kendi işinizin neye ihtiyaç duyduğunu yazıya dökersiniz, sonra o listeye uyan ürünleri ararsınız. İhtiyaç listesi olmadan yapılan seçimde karar, demoyu en iyi sunan satıcının lehine verilir.

Bu yazı, orta ölçekli bir işletmenin yazılım kısa listesine geçmeden önce yapması gereken ihtiyaç analizini anlatıyor. Amaç yüzlerce satırlık bir Excel üretmek değil; karar verirken elinizde ölçülebilir bir ölçüt olması.

Neden önce ihtiyaç, sonra ürün

Gereksinimi yazılı olmayan bir proje üç yerde kaybeder. Birincisi satıcı karşılaştırmasında: her firma kendi güçlü olduğu modülü anlatır, siz de hangisinin eksik olduğunu fark etmezsiniz. İkincisi sözleşmede: "standart kapsam" ifadesinin içinde ne olduğu belirsiz kalır. Üçüncüsü uygulamada: sonradan ortaya çıkan her ihtiyaç ek özelleştirme ve ek bütçe demektir. Özelleştirmenin riskini standart mı uyarlama mı yazımızda ayrıca ele aldık.

İyi hazırlanmış bir gereksinim listesi aynı zamanda iç uzlaşma aracıdır. Satış, depo, muhasebe ve üretim aynı masada oturup "bizim için olmazsa olmaz ne" sorusunu cevaplamak zorunda kalır. Bu tartışma projenin en ucuz yapılabileceği andır.

Adım 1: Kapsamı ve sahipleri belirleyin

Önce hangi süreçlerin ERP'ye girdiğini yazın. Tipik başlıklar:

  • Satış, sipariş ve sevkiyat
  • Satın alma ve tedarikçi yönetimi
  • Stok ve depo
  • Üretim ve reçete yönetimi (varsa)
  • Finans, muhasebe, cari hesaplar
  • e-Fatura, e-Arşiv, e-İrsaliye ve diğer e-belge süreçleri
  • İnsan kaynakları ve bordro (ayrı bir sistemde kalacaksa bunu da yazın)
  • Raporlama ve yönetim panoları

Her başlığa bir süreç sahibi atayın. Süreç sahibi, o alandaki gereksinimlerin doğruluğundan sorumlu olan kişidir; genelde bölüm yöneticisi ya da sahada işi en iyi bilen kıdemli çalışan. Proje liderliğini iç ekibin mi yoksa dış danışmanın mı yürüteceği ayrı bir karardır; bunu iç ekip mi dış danışman mı yazısında tartıştık.

Adım 2: Mevcut süreçleri olduğu gibi çizin

Gereksinim yazmadan önce işin bugün nasıl yürüdüğünü çıkarın. "Olması gereken" değil, "olan". Bir siparişin teklif aşamasından tahsilata kadar hangi ellerden geçtiğini, hangi Excel dosyalarında bekletildiğini, hangi onayların e-postayla alındığını not edin.

Bu çalışma iki şey ortaya çıkarır. Birincisi, ERP'nin otomatikleştireceği gerçek manuel işler. İkincisi, kimsenin yazıya dökmediği ama günlük işin parçası olan istisnalar: belirli bir müşteriye özel iskonto yapısı, mevsimsel kampanya fiyatı, sevkiyat öncesi kalite onayı gibi. Satıcı demosunda en çok bu istisnalar yara alır.

Çizim için pahalı araç gerekmez. Beyaz tahta, her süreç için bir sayfa ve iki-üç saatlik bir atölye çoğu zaman yeterlidir.

Adım 3: Kullanıcılarla konuşun, ama yönetin

Süreç sahiplerinin yanında günlük işi yapan kişilerle de görüşün: depo çalışanı, satış temsilcisi, muhasebe uzmanı. Onlara "ne istersiniz" diye sormak taleplerin kontrolsüz büyümesine yol açar. Bunun yerine şunu sorun:

  • Bugün en çok zaman kaybettiğiniz üç iş hangisi?
  • Hangi işi yaparken hata çıkma riski en yüksek?
  • Mevcut sistemde sizi en çok yoran ekran ya da rapor hangisi?
  • Hangi bilgiyi bulmak için başka birine sormak zorunda kalıyorsunuz?

Bu sorular, özellik isteklerini sorun cümlelerine çevirir. "Mobil uygulama olsun" yerine "saha satışçısı sipariş girmek için ofise dönmek zorunda" cümlesi çok daha değerli bir gereksinimdir, çünkü çözümü satıcıya bırakır. Kullanıcı benimsemesi ayrı bir konu; ayrıntısı ERP kullanıcı benimsemesi rehberinde var.

Adım 4: Gereksinimleri üç sınıfa ayırın

Her gereksinimi yazarken bir öncelik etiketi koyun. Üç seviye çoğu proje için yeterlidir:

SınıfAnlamıKarar etkisi
ZorunluOlmazsa sistem canlıya alınamaz (ör. yasal e-belge uyumu, çok depolu stok)Karşılamayan ürün elenir
Gerekliİş yürür ama manuel çözüm gerekir (ör. belirli bir rapor)Puanlamada ağırlık taşır
İstenenOlursa iyi olur, bütçeyi belirlemezEşitlik bozucu olarak kullanılır

Zorunlu sınıfı kısa tutun. Listenin yarısı "zorunlu" ise hiçbir ürün geçemez ya da her ürün ağır özelleştirmeyle geçer. Pratik bir sınama: "Bu madde olmasaydı projeyi başlatmaz mıydık?" Cevap hayırsa madde zorunlu değildir.

Yasal gereksinimler ayrı bir kategoridir. e-Fatura, e-Defter ve benzeri yükümlülüklerin güncel kapsamı için GİB'in resmi duyurularına bakın; bu konuyu ERP açısından e-Belge için yerleşik modül mü özel entegratör mü yazımızda işledik.

Adım 5: Her gereksinimi sınanabilir yazın

Kötü gereksinim: "Sistem kullanıcı dostu olmalı." İyi gereksinim: "Satış temsilcisi, mevcut müşteri için sipariş girişini ek eğitim almadan tamamlayabilmeli." Birincisi her satıcıdan "evet" alır, ikincisi demoda sınanabilir.

Her satır için şu alanları doldurun:

  • Gereksinim numarası ve kısa başlık
  • Süreç ve sahip
  • Öncelik sınıfı
  • Sınama yöntemi (demoda canlı gösterim, belge, referans müşteri)
  • Mevcut durumdaki karşılığı (hangi Excel ya da program yapıyor)

"Sınama yöntemi" sütunu, listeyi satıcı demosuna bağlayan halkadır. Demoyu bu senaryolarla yürütme yöntemini ERP demo değerlendirme rehberinde anlattık.

Adım 6: Teknik ve ticari çerçeveyi ekleyin

İşlevsel gereksinimlerin yanında karar sürecini belirleyen birkaç başlık daha vardır:

  • Dağıtım modeli: bulut, kurulum ya da hibrit. Bu karşılaştırma için bulut ERP ile yerinde kurulumu ele alan yazımız yardımcı olur.
  • Mevcut sistemlerle entegrasyon: banka, e-belge entegratörü, e-ticaret, üretim cihazları
  • Veri taşıma kapsamı: kaç yıllık veri taşınacak, hangi kayıtlar arşivde kalacak (veri taşıma rehberimiz)
  • Kullanıcı sayısı ve büyüme beklentisi
  • Bütçe aralığı ve toplam sahip olma maliyeti (gizli kalemler rehberi)
  • Yedekleme, erişim yetkisi ve denetim izi beklentileri

Bütçeyi satıcıdan önce kendiniz belirleyin, ama listeye kesin rakam yerine aralık yazın. Fiyatlar kullanıcı sayısı, modül ve sözleşme süresine göre değiştiği için satıcıdan güncel ve yazılı teklif almak gerekir.

Adım 7: Listeyi satıcıya doğru formatta verin

Hazırladığınız liste iki amaçla kullanılır: kısa liste oluşturmak ve resmi teklif istemek. Kısa liste aşamasında zorunlu gereksinimleri ve sektör bilgisini kullanarak ürünleri eleyin. Sektörünüze özgü beklentiler için üretim sektörü sayfamıza ya da kendi sektörünüzün sayfasına bakabilir, ürün karşılaştırmaları için Logo ile Mikro karşılaştırması gibi yan yana sayfaları kullanabilirsiniz.

Teklif aşamasında satıcıdan her gereksinim için dört cevaptan birini isteyin: standart olarak karşılıyor, ayar ile karşılıyor, özelleştirme gerektiriyor, karşılamıyor. Özelleştirme gerektiren satırlar için ayrı süre ve bedel yazdırın. Cevapları puanlama matrisine taşımak için tedarikçi puanlama matrisi rehberimizi kullanabilirsiniz.

Sık yapılan hatalar

Bazı hatalar neredeyse her projede tekrar eder:

  • Listeyi yalnızca BT ya da yalnızca finans hazırlar; operasyon sahadaki gerçeği söyleyemez.
  • Eski sistemin her özelliği yeni listeye taşınır; böylece kötü alışkanlıklar da lisanslanır.
  • Gereksinimler çözüm cümlesiyle yazılır ("şu ekran olsun"), sorun cümlesiyle değil.
  • Öncelik sınıfı konmaz, her satır eşit ağırlıkta görünür.
  • Liste bir kez yazılır ve sözleşmeye eklenmez; sonra "kapsam dışı" tartışması çıkar.

Son madde önemli: nihai gereksinim listesi ve satıcının verdiği cevaplar sözleşmenin eki olmalı. Sözleşme tarafındaki kontrol noktaları için imzadan önce kontrol listesine göz atın.

Listeden karara

Listeniz hazırsa, profilinize uyan ürünleri filtrelemek için Uygun ERP bul aracını kullanabilirsiniz. Gereksinimlerinizi birlikte gözden geçirmek isterseniz keşif formuyla bağımsız bir değerlendirme talep etmek de mümkün. Hiçbir satıcıya bağlı olmayan bir ikinci göz, özellikle zorunlu ve gerekli ayrımında işe yarar.

Bu yazıyı paylaş

Sıkça sorulan sorular

ERP ihtiyaç analizi ne kadar sürer?

Süre işletmenin büyüklüğüne ve süreç sayısına bağlıdır. Orta ölçekli bir firmada süreç atölyeleri, kullanıcı görüşmeleri ve listenin netleşmesi tipik olarak birkaç haftayı bulur. Acele edilirse eksik kalan gereksinimler sonradan ek özelleştirme olarak geri döner.

Gereksinim listesinde kaç madde olmalı?

Sabit bir sayı yoktur. Önemli olan her maddenin sınanabilir ve önceliklendirilmiş olması. Yüzlerce maddelik ama öncelik etiketi olmayan bir liste, kırk-elli iyi yazılmış maddeden daha az işe yarar.

İhtiyaç analizini danışmansız yapabilir miyim?

Evet, süreçleri iyi bilen bir iç ekip varsa yapabilirsiniz. Danışman daha çok tarafsız bir bakış ve farklı projelerden gelen deneyim katar. Hangisini seçeceğiniz ekibin zamanına ve proje deneyimine göre değişir.

Zorunlu ve gerekli gereksinim arasındaki fark nedir?

Zorunlu gereksinim karşılanmazsa sistem canlıya alınamaz ve ürün elenir. Gerekli gereksinim karşılanmazsa iş yürür ama manuel çözüm ya da ek maliyet doğar. Ayrım için pratik soru: bu madde olmasa projeyi başlatır mıydık?

Gereksinim listesini satıcılarla paylaşmak doğru mu?

Evet, kısa liste aşamasında paylaşmak karşılaştırmayı adil kılar. Ticari olarak hassas bilgileri (müşteri adları, fiyat politikası, kesin bütçe) çıkarıp süreç ve işlev düzeyinde bir liste vermeniz yeterlidir.

Liste projeden sonra da kullanılır mı?

Kullanılmalı. Kabul testlerinin ve canlıya geçiş kontrol listesinin temeli olur. Sözleşme ekine alınırsa kapsam tartışmalarında referans görevi görür.

Kararınızı netleştirelim

15 dakikalık ücretsiz görüşmede ihtiyacınızı dinler, 2-3 ERP öneririz. Vendor satış görüşmesi değil — bağımsız tavsiye.