Bir teklif toplantısında sıkça duyulan cümle şudur: “Bize hangi modülleriniz uyar, bir demo gösterin.” Soru anlaşılırdır ama sırası yanlıştır. Demoya oturmadan önce cevaplanması gereken başka bir soru var: işletmenin bugünkü süreçleri gerçekte nasıl işliyor, hangi noktada tıkanıyor ve yeni sistemden ne bekleniyor?
Bu sorunun cevabı olmadan seçilen yazılım, mevcut karmaşıklığı ekrana taşımaktan öteye gitmez. Gereksinim analizi ve süreç haritalama, ERP projesinin en az heyecan verici ama en belirleyici adımıdır — ve genellikle en çok atlanan adımdır.
Neden yazılım seçiminden önce gelir
Satın alma ekibi çoğu zaman doğrudan tedarikçi karşılaştırmasına geçer: kaç modül var, fiyat ne, referans kim. Bu bilgiler gereklidir ama tek başına yeterli değildir. Bir yazılımın “iyi” olup olmadığı, kurumun kendi süreçleriyle ne kadar örtüştüğüne bağlıdır. Aynı ERP, bir işletmede sorunsuz çalışırken başka birinde sürekli özel geliştirme talep eder — fark çoğu zaman yazılımda değil, baştaki analizin derinliğindedir. Bu konuyu ERP projelerinin neden başarısız olduğu yazısında daha geniş ele almıştık; burada odak, o başarısızlığı önleyen ilk adıma: doğru gereksinim analizine.
Gereksinim analizinin işi basit görünür ama zordur: “Bugün ne yapıyoruz, nerede zaman kaybediyoruz, yeni sistemde ne olsun istiyoruz” sorularını yazılı, ölçülebilir ve departmanlar arası tutarlı bir dokümana dönüştürmek. Bu doküman olmadan başlayan bir proje, ilerledikçe her toplantıda yeniden tanımlanır; kapsam kayar, takvim uzar.
Mevcut durum ve hedef durum: AS-IS / TO-BE haritalama
Süreç haritalamada kullanılan temel çerçeve iki aşamalıdır: önce mevcut durum (AS-IS) net biçimde çıkarılır, sonra hedef durum (TO-BE) tasarlanır. Sıralama önemlidir — hedefi tarif etmeden önce bugünü doğru görmek gerekir, aksi halde “olması gereken” ile “gerçekte olan” arasındaki fark gözden kaçar.
Mevcut durum çalışmasında sorulan sorular şunlardır:
- Bu süreç şu anda hangi adımlardan geçiyor, kim hangi adımı yapıyor?
- Hangi bilgi Excel’de, hangisi e-postada, hangisi kâğıtta tutuluyor?
- Bir siparişin girişten faturaya kadar geçen süresi ortalama ne kadar?
- Aynı veri kaç kez, kaç farklı yerde elle giriliyor?
- Hangi adımda hata en sık oluyor, kim fark ediyor, nasıl düzeltiliyor?
Bu sorular yanıtlandıktan sonra hedef durum tasarlanır: aynı süreç, gereksiz tekrarlar ve elle giriş noktaları çıkarılmış hâliyle nasıl işlemeli? Aradaki fark, projenin gerçek kapsamını oluşturur.
| Boyut | Mevcut durum (AS-IS) | Hedef durum (TO-BE) |
|---|---|---|
| Sipariş girişi | Satış Excel’e yazar, muhasebe ayrıca sisteme girer | Tek girişle sipariş, stok ve fatura otomatik bağlanır |
| Stok görünürlüğü | Depo sorumlusu telefonla teyit eder | Gerçek zamanlı stok ekranı, tüm ekipler aynı veriyi görür |
| Onay süreci | E-posta zinciri, kim onayladı belirsiz | Sistem içi onay adımı, kayıt altında iz bırakır |
| Raporlama | Ay sonunda elle birleştirilen tablolar | Canlı gösterge paneli, güncel veri |
Bu tablo bir şablon değil; her kurumun kendi süreçleri için benzer bir çalışmayı çıkarması gerekir. Genel geçer bir “TO-BE” yoktur — her işletmenin hedef akışı, kendi operasyonel gerçekliğine göre şekillenir.
Süreç haritalama atölyeleri: kimler katılmalı
Gereksinim analizi masa başında, tek kişinin tahminiyle yapılamaz. En sağlıklı yöntem, departman bazlı kısa atölyeler düzenlemektir — genellikle her biri birkaç saat süren, ilgili sürecin fiilen içinde çalışan kişilerin katıldığı oturumlar.
Katılımcı seçiminde sık yapılan hata, yalnızca yöneticileri masaya çağırmaktır. Yönetici süreci genel hatlarıyla bilir; süreci fiilen yürüten kişi ise günlük aksaklığı, istisna durumları ve “aslında böyle yapıyoruz ama kimseye söylemedik” ayrıntılarını bilir. İkisi de atölyede olmalı.
Rol dağılımı netleştirilmezse atölyeler dağınık ilerler. Sorumlu-onaylayan-danışılan-bilgilendirilen (RACI) mantığıyla basit bir dağılım işe yarar:
- Süreç sahibi (departman yöneticisi): Hedefi onaylar, çelişen talepleri çözer.
- Anahtar kullanıcı: Günlük süreci fiilen bilen kişi; atölyenin ana bilgi kaynağı.
- Proje koordinatörü: Atölyeleri planlar, notları dokümana dönüştürür, departmanlar arası çelişkileri işaretler.
- Danışman/uygulayıcı ekip: Sorular sorar, benzer kurumlardan görülen desenleri paylaşır, teknik olarak nelerin mümkün olduğunu netleştirir.
Atölye sonunda her departman kendi haritasını görmeli ve “evet, süreç gerçekten böyle işliyor” diyebilmelidir. Onaylanmamış bir harita, canlıya geçişte sürpriz çıkarır.
Gereksinim dokümanı neyi içermeli
Atölyelerin çıktısı tek bir dokümanda toplanır. Bu doküman proje boyunca referans noktasıdır — kapsam tartışması çıktığında “dokümanda ne yazıyor” sorusuyla çözülür, hafızaya veya “sanırım öyle konuşmuştuk”a değil.
Eksiksiz bir gereksinim dokümanında şunlar bulunur:
- Süreç haritaları — her ana süreç için mevcut ve hedef akış, adım adım.
- Fonksiyonel gereksinimler — sistemin yapması gereken somut işler (örn. “sipariş onaylandığında stok otomatik rezerve edilsin”).
- Veri gereksinimleri — hangi veri nereden geliyor, hangi alanlar zorunlu, eski sistemden ne taşınacak. Bu kalemi ayrı bir iş paketi olarak planlamak gerektiğini veri taşıma sürecini planlama yazısında ayrıntılı anlattık.
- Entegrasyon ihtiyaçları — e-ticaret, banka, kargo veya başka bir yazılımla bağlantı gerekiyor mu.
- Raporlama beklentileri — kim, hangi raporu, ne sıklıkta görmek istiyor.
- Kapsam dışı bırakılanlar — ilk fazda ele alınmayacak konuların açık listesi. Bu liste, kapsamın sessizce büyümesini önler.
- Öncelik sıralaması — “olmazsa olmaz” ile “olsa iyi olur” ayrımı; bütçe veya takvim kısıtında hangi maddenin ertelenebileceğini gösterir.
Doküman hazır olduğunda tedarikçi karşılaştırması çok daha isabetli yürür: soyut bir “iyi ERP” tanımı yerine, kurumun kendi listesine göre “bu ihtiyacı karşılıyor mu, karşılamıyor mu” sorusuna somut cevap alınır. Doğru soruları sıralamak için en iyi ERP yazılımı nasıl seçilir yazısındaki çerçeve bu dokümanla birlikte kullanılabilir.
KOSGEB’in aradığı analiz raporu ile örtüşen kısım
Gereksinim analizinin önemi yalnızca proje disiplininden gelmiyor; kamu desteği tarafında da doğrudan karşılığı var. KOSGEB’in KOBİ Dijital Dönüşüm Destek Programı’na yönelik 11 Mayıs 2026 tarihli güncel yönergesine göre, program kapsamında banka kredisi faiz desteğinden yararlanmak isteyen işletmelerin, yetkili danışmanlardan alınmış onaylı bir Dijital Dönüşüm Değerlendirme Analizi ve Yol Haritası Raporuna sahip olması ve başvurusunu bu raporun onay tarihinden itibaren bir yıl içinde yapması gerekiyor.
Bu rapor, esasında yukarıda anlatılan mevcut durum–hedef durum çalışmasının resmî bir versiyonudur: işletmenin dijitalleşme olgunluğu değerlendirilir, süreçler haritalanır ve bir yol haritası çıkarılır. Yani düzgün yürütülen bir ERP gereksinim analizi, hem projeyi hem de destek başvurusunu aynı anda besleyebilir. Programın kapsadığı yatırım kalemleri arasında ERP, MRP ve üretim dijitalizasyonu yazılımları yer alıyor; kredi faiz giderinin yönergede belirtilen puana kadar olan kısmı geri ödemesiz karşılanıyor. Finansman tarafını, KOSGEB üzerinden ERP yatırımını nasıl planlayabileceğinizi anlattığımız bu yazıda ayrıca ele aldık.
Destek oranları, süre sınırları ve başvuru şartları yönergeyle güncellenebilir. Kesin ve güncel rakamlar için KOSGEB’in resmî duyurularını veya yetkili danışmanınızı kontrol etmenizi öneririz.
Qera’da keşif süreci nasıl işler
Qera’nın uygulama yaklaşımı, satış görüşmesinden önce değil, satış görüşmesinin bir parçası olarak keşif atölyesiyle başlar. Amaç, demoyu genel bir tanıtımdan çıkarıp işletmenin kendi süreciyle konuşan bir gösterime dönüştürmek.
Pratikte bu şöyle ilerler:
- İlgili departmanlarla kısa keşif görüşmeleri yapılır; mevcut akış ve en çok zaman kaybedilen nokta belirlenir.
- Öne çıkan ihtiyaçlar, demo senaryosuna yansıtılır — jenerik bir ekran turu yerine, işletmenin kendi sipariş, stok veya üretim akışına yakın bir gösterim hazırlanır.
- Low-code (az kodla yapılandırılabilir) mimari sayesinde süreç uyarlamaları için aylar süren özel geliştirmeye gerek kalmaz; standart yapı, işletmenin akışına göre şekillenir.
- Tek platform mantığı; satış, stok, üretim, finans ve CRM’in aynı veride çalışması demektir. Bu da gereksinim dokümanındaki “entegrasyon ihtiyaçları” bölümünü büyük ölçüde sadeleştirir, çünkü modüller arasında ayrı bir bağlantı projesi gerekmez.
- Anahtar teslim kurgu; kurulum, veri aktarımı ve eğitim aynı ekipten yürür, sürpriz maliyet çıkmaz ve 100 kullanıcıya kadar ek kullanıcı ücreti yoktur.
- Altyapı Microsoft Azure üzerinde çalışır; güvenlik ve yedekleme kurumsal standarda göre baştan kurulu gelir.
Keşif atölyesinin çıktısı, projenin resmî gereksinim dokümanının ilk taslağı olarak kullanılabilir — sıfırdan başlamak yerine, satış aşamasında toplanan bilgi doğrudan uygulama planına aktarılır.
Sıkça Sorulan Sorular
Gereksinim analizi ne kadar sürer?
İşletmenin büyüklüğüne ve süreç sayısına göre değişir; küçük ve orta ölçekli bir işletmede birkaç haftalık atölye programıyla tamamlanabilir. Çok şubeli veya çok departmanlı yapılarda süre uzar. Süreyi kısaltan en önemli etken, doğru kişilerin atölyelere zamanında katılmasıdır.
AS-IS analizi yapılmadan doğrudan TO-BE tasarlanabilir mi?
Teknik olarak mümkündür ama önerilmez. Mevcut durum net görülmeden tasarlanan hedef akış, gerçek operasyonel kısıtları (örneğin belirli bir onay adımının neden var olduğunu) gözden kaçırabilir. Kısa bir AS-IS çalışması bile, sonraki tasarımı büyük ölçüde sağlamlaştırır.
Gereksinim dokümanını kim hazırlamalı — işletme mi, tedarikçi mi?
İkisi birlikte hazırlamalı. İşletme süreç bilgisini ve önceliklerini verir; tedarikçi/danışman bunu yapılandırılmış bir dokümana dönüştürür ve teknik olarak nelerin mümkün olduğunu netleştirir. Tek taraflı hazırlanan dokümanlar genellikle eksik veya gerçekçi olmayan beklentiler içerir.
Küçük bir işletme için bu süreç gereksiz ağır mı kaçar?
Kapsam işletme büyüklüğüne göre ölçeklenebilir. Az sayıda süreç ve departmanı olan bir işletmede atölyeler daha kısa ve sayıca az olur; yine de en az temel bir mevcut durum–hedef durum çalışması ve kısa bir gereksinim dokümanı, sonradan yaşanacak kapsam tartışmalarını önler.
KOSGEB desteğinden yararlanmak için ayrı bir analiz mi yaptırmak gerekir?
KOSGEB’in aradığı Dijital Dönüşüm Değerlendirme Analizi ve Yol Haritası Raporu, yetkili bir danışman tarafından hazırlanıp onaylanmalıdır; ERP projeniz için yapılan gereksinim analizi bu raporla örtüşen bir çalışmadır ama resmî başvuru için yönergede tanımlanan formatta ve yetkili danışman onayıyla hazırlanması gerekir. Güncel şartlar için KOSGEB’in resmî duyurularına bakılmalıdır.
Değerlendirme sürecinin sonraki adımları
Gereksinim analizi, ERP projesinin en görünmez ama en pahalıya patlayan eksikliğidir — atlandığında etkisi aylar sonra, canlıya geçişte ortaya çıkar. Birkaç haftalık bir atölye programı ve net bir doküman, sonraki tüm kararların (yazılım seçimi, bütçe, takvim) üzerine oturacağı zemini kurar.
Kendi süreçlerinizi Qera’nın keşif yaklaşımıyla değerlendirmek isterseniz ücretsiz demo talep edebilir, tek platform mantığının işletmenize nasıl oturduğunu Qera ERP sayfasından inceleyebilirsiniz. Kapsamı doğru belirledikten sonra pilot bir uygulamayla başlamanın yollarını başarılı bir pilot proje kurulumu yazısında bulabilirsiniz.
Kaynaklar:
- KOSGEB — KOBİ Dijital Dönüşüm Destek Programı Yönergesi (11.05.2026 güncel): webdosya.kosgeb.gov.tr
Yukarıdaki destek oranı, süre ve başvuru şartlarına ilişkin bilgiler yönergenin güncel sürümünden alınmıştır; program koşulları zaman içinde değişebilir. Başvuru öncesi güncel şartları KOSGEB’in resmî kaynaklarından veya yetkili danışmanınızdan teyit etmeniz önerilir.
