ERP İhtiyaç Analizi: İş Akışından Gereksinim Dosyasına

1. Modül listesinden önce bir işlemin yolunu izleyin

İlk toplantıya uzun bir özellik listesiyle gitmek yerine yakın zamanda tamamlanmış bir işi seçin. Talebin kimden geldiğini, hangi bilgiyle başladığını, kimlerin elinden geçtiğini ve ne zaman tamamlandığını sorun. Aynı bilgiyi ikinci kez yazan kişi, eksik bilgi nedeniyle bekleyen adım ve sistem dışında tutulan dosya özellikle kaydedilsin.

Microsoft'un süreç odaklı uygulama rehberi, iş süreçlerinin gereksinimleri ve çözüm kapsamını yönlendirmesini önerir. Mevcut işleyişi anlamak ile gelecekte istenen işleyişi tanımlamak birlikte ele alınır. Bu yaklaşımı kullanmak, belirli bir ERP markasını seçmeyi gerektirmez. [1]

Örnek gözlem kaydı: “Sipariş e-postayla geliyor; operasyon ürün kodunu başka dosyada arıyor; stok bilgisi telefonla doğrulanıyor; sevkiyat listesi yeniden yazılıyor.” Bu tamamen örnek bir akıştır. Henüz “entegrasyon şart” sonucuna atlamayın; önce tekrarın nedenini ve kullanılan kaynakların neden ayrıldığını araştırın.

Kaynaklar: [1]

2. Görüşmelerde son yaşanan istisnayı sorun

Normal işlemin yanında son iptali, eksik teslimatı veya yanlış ürün kodunu konuşun. “Sistem nasıl olmalı?” sorusundan sonra “Bu durum en son olduğunda ne yaptınız?” diye sorun. Kişinin görmek istediği ekran ile tamamlamak zorunda olduğu iş farklı olabilir. İşin sonucunu, beklemeyi ve düzeltme biçimini ayrı kaydedin.

Satış, operasyon, finans ve yönetim aynı kelimeye farklı anlam verebilir. “Tamamlandı” satış için siparişin onaylanması, depo için sevk edilmesi olabilir. Çelişkiyi bir tarafın hatası gibi çözmeyin; iki durumu ayrı adlandırıp aralarındaki geçişi yazın. Belirsiz süreç kararının yazılım ekibine sessizce devredilmesini böyle önleyebilirsiniz.

Görüşme notunda doğrudan gözlenen bilgi, çalışanın tahmini ve henüz doğrulanmamış yorum ayrılmalı. Örneğin “her gün çok zaman gidiyor” ifadesini ölçülmüş süreye çevirmeyin. Belirlenen birkaç iş günü boyunca başlangıç ve bitiş anlarını kaydetmeyi önerin; ölçüm dönemi ile örnek sayısını dosyada belirtin.

3. Her ihtiyacı tek bir gereksinim kartına dönüştürün

Önerdiğimiz kart altı alan içerir: iş sorunu, kullanıcı rolü, tetikleyici, beklenen davranış, istisna ve doğrulama yöntemi. Her karta sabit bir kimlik verin. Böylece toplantıda söylenen ihtiyaç, ileride çözüm tasarımı veya kapsam değişikliğiyle ilişkilendirilebilir. Aynı isteğin farklı adlarla tekrar açılmasını da daha kolay fark edersiniz.

Varsayımsal G-012 kartı şöyle olabilir: “Operasyon sorumlusu, onaylanmış siparişte teslim tarihi değiştiğinde eski ve yeni tarihi görebilmeli; değişiklik nedeni kaydedilmeli; yetkisiz kullanıcı tarihi düzenleyememeli.” Doğrulama için iki rol ve örnek sipariş kullanılır. Bu, mevcut bir ürünün özellik iddiası veya yapılmış bir test değildir.

Kartın çözüm alanını başlangıçta boş bırakın. İhtiyaç bazen mevcut yazılımın ayarıyla, bazen görev dağılımını değiştirerek, bazen yeni bir entegrasyonla karşılanabilir. Her talebi otomatik olarak yeni ekran geliştirmesine çevirmek, kapsamın gereksiz büyümesine neden olur.

4. Veri sözlüğünde sahiplik ve anlamı birlikte tanımlayın

Microsoft'un veri yönetimi rehberi, ortak iş terimlerinin tanımını ve veri sorumluluğunu veri yönetişiminin parçası olarak ele alır. Veri kalitesi yalnız araç seçimine bırakılmaz; veriyi tanıyan kişilerin sorumluluğu da önemlidir. [2]

Kendi dosyanızda ürün kodu, müşteri kodu, sipariş durumu ve tarih gibi kritik alanlar için tanım, kaynak sistem, düzenleme yetkisi ve boş değer davranışı yazın. Örneğin ürün kodunun başındaki sıfırlar anlamlıysa bunu açıkça belirtin. Bir alanın Excel'de sayı görünmesi, iş açısından sayı olduğu anlamına gelmeyebilir.

Örnek sözlük kaydı: “planlanan_teslim_tarihi | müşteriye bildirilen son plan | sahibi: operasyon | değişiklik nedeni zorunlu | boşsa planlama bekliyor.” Bu öneriyi işletmenizdeki kuralla değiştirin. Geçmiş veride aynı alan farklı anlamlarda kullanılmışsa taşıma öncesinde ayrıştırma veya işaretleme kararı alın; belirsizliği yeni sisteme görünmez biçimde taşımayın.

Kaynaklar: [2]

5. Entegrasyon ihtiyacını bağlantı adından daha açık yazın

Microsoft'un entegrasyon rehberi, iş hedeflerinin sistemler arası gereksinimlerle ilişkilendirilmesini; tasarım ve yöntem seçiminin buna göre yapılmasını önerir. İki sistemin adını yan yana yazmak, aktarımın yönünü ve beklenen davranışını tanımlamaz. [3]

Her aktarım için hangi olayın süreci başlatacağını, hangi kaydın gönderileceğini, alıcı sistemi ve kabul edilebilir gecikmeyi belirtin. “Stok anlık olsun” yerine, kararın ne kadar güncel bilgi gerektirdiğini süreç sahibine sorun. Yanıt bilinmiyorsa dosyaya tahmini bir teknik süre koymayın.

Hata yolunu da kaydedin: bağlantı kesilirse işlem bekleyecek mi, yeniden denenecek mi, kim haberdar olacak? Aynı kayıt iki kez gelirse hangi kimlikle tanınacak? Entegrasyon kaydına başarısız aktarımın nasıl fark edileceğini eklemek, ilk ihtiyaç toplantısında çözülemeyen teknik soruları görünür bir inceleme listesine dönüştürür.

Kaynaklar: [3]

6. İlk aşamanın sınırını ve açık soruları belirleyin

Gereksinimleri “ilk aşamada gerekli”, “sonraki aşamada değerlendirilecek” ve “henüz doğrulanmadı” olarak ayırın. Her kararın gerekçesini yazın. İşlem tamamlanmasını engelleyen bir eksik, seyrek kullanılan görsel bir tercihten önce gelebilir. Önceliği yalnız talebi söyleyen kişinin unvanına göre vermeyin.

Analiz sonunda tek bir dosyada süreç krokisi, gereksinim kartları, veri sözlüğü, entegrasyon listesi ve açık kararlar bulunmalı. Açık sorulara cevap verecek kişiler ile kontrol tarihlerini ekleyin. ERP İhtiyaç Haritası gibi bir başlangıç aracı hazırlığı kolaylaştırabilir; işin gerçek akışını ekiplerle doğrulamak yine analizin parçasıdır.

Bu dosya hazır olduğunda ERP seçim kontrol listesine geçebilirsiniz. Böylece adaylardan ne göstereceklerini talep etmek kolaylaşır. İhtiyaç analizi tamamlandı demek için her konunun çözülmesi gerekmez; kapsamı etkileyen belirsizliklerin görünür, sahiplerinin belli ve sonraki adımlarının yazılı olması gerekir.