ERP projesine başlamadan önce süreç analizi neden gerekli?

ERP demosunda her şey düzgün çalışır; sorun, demodaki firmanın sizin firmanız olmamasıdır. Süreç analizi, bir yazılıma geçmeden önce siparişten tahsilata işlerin gerçekte nasıl yürüdüğünü adım adım çıkaran çalışmadır. ERP projesinin sağlıklı ilerleyip ilerlemeyeceği, çoğu zaman bu çalışmanın kalitesine bağlıdır.

Bu yazıda analizin neden atlanmaması gerektiğini, içinde neler çıkarıldığını ve sonunda elinizde hangi belgelerin olması gerektiğini anlatıyoruz. Yaklaşımı, işletmeye uyarlanan bir mimari olarak kurduğumuz YazSis ERP ilkeleri üzerinden ele alıyoruz.

Analiz atlanırsa ne olur?

Yazılım kurulur, ekranlar açılır, herkes giriş yapar. Birkaç hafta sonra ise çalışanların bir kısmı eski alışkanlığına döner. Çünkü yazılım, işin gerçekte yürüdüğü şekle değil, kâğıt üzerinde anlatılan şekle göre kurulmuştur. Aşağıdaki dört sorun bu durumun en sık görülen sonuçlarıdır.

• Kapsam kayar: “Bunu da ekleyelim” talepleri proje ortasında birikir, takvim uzar ve hangi işin ilk fazda olduğu tartışma konusu olur.
• Çift kayıt başlar: Sistemde karşılığı olmayan iş yine Excel’de yapılır; iki kayıt zamanla birbirinden uzaklaşır ve hangisinin doğru olduğu belirsizleşir.
• Kullanıcı direnir: Ekran, kullanıcının işini kolaylaştırmak yerine fazladan alan doldurtur. Bu durumda yazılım, ek bir yük olarak algılanır.
• Sorumluluk belirsiz kalır: Onayı kimin verdiği, istisnayı kimin karara bağladığı sorusu canlıya geçince tartışılır; oysa bu karar projenin başında verilebilirdi.

Süreç analizinde beş adım

1. Akışı olduğu gibi çizin. Siparişin, satın almanın ve stok hareketinin bugün hangi kişiden hangi kişiye, hangi araçla gittiğini yazın. Olması gereken değil, gerçekte olan akış önemlidir.
2. İstisnaları toplayın. İade, kısmi sevkiyat, fiyat farkı, acil sipariş gibi “normal olmayan” durumlar günlük işin büyük bir bölümünü oluşturabilir. Yazılım en çok bu durumlarda zorlanır; bu yüzden ayrı bir liste tutulmalıdır.
3. Onay ve yetkileri netleştirin. Hangi tutarın üstünde kim onaylıyor, iskontoyu kim verebiliyor, stok düzeltmesini kim yapabiliyor? Bu cevaplar kişiye değil role bağlanmalıdır.
4. Veri kaynaklarını listeleyin. Müşteri listesi, ürün kartı, fiyat listesi nerede tutuluyor? Hangisi güncel, hangisini kim güncelliyor? Aynı bilginin birden fazla yerde yaşadığı noktalar, sistemde tek kayda indirilecek yerlerdir.
5. Neyi ölçeceğinize karar verin. Yönetimin her hafta görmek istediği birkaç gösterge baştan seçilirse, ekranlar ve raporlar ona göre kurulur; sonradan rapor eklemek her zaman daha zordur.

Küçük bir örnek: iskonto onayı

Bir müşteri indirim ister. Satış temsilcisi yöneticiye WhatsApp’tan yazar, yönetici “tamam” der ve temsilci teklifi hazırlar. Kimse bunu süreç olarak tanımlamamıştır, ama her gün işler. ERP’ye geçerken bu akış yazılmazsa sistemde ya hiç onay adımı olmaz ya da kimsenin kullanmadığı bir onay adımı olur. Analiz, bu görünmez kuralı kâğıda döker ve yazılımın içine yerleştirilebilir hale getirir. Aynı yöntem stok düzeltmesi, tedarikçi seçimi, iade kabulü gibi diğer sessiz kurallar için de geçerlidir: önce kim neye göre karar veriyor sorusu cevaplanır, sonra bu karar sisteme bir adım olarak yazılır.

Yazılıma anlatamadığınız süreç, yazılımda çalışmaz.

Analize kimler katılmalı?

Süreci en yakından, o işi her gün yapan kişiler tanır. Bu yüzden analiz yalnızca yönetim ve bilgi işlem düzeyinde kalmamalı; satış temsilcisi, depocu, satın almacı ve muhasebeci de sürece katılmalıdır. Yönetim işin nasıl yürümesi gerektiğini, çalışan ise nasıl yürüdüğünü anlatır. İkisi arasındaki fark, projenin asıl iş listesidir. Bazen bu fark bir yazılım ihtiyacı değil, sadece eksik bir kural ya da gereksiz bir onay adımıdır; bunu analiz sırasında görmek, kurulumdan sonra fark etmekten çok daha az zahmetlidir.

Analizin sonunda elinizde ne olmalı?

İyi bir analiz sözlü toplantılarla bitmez, somut belgelerle biter. Bu belgeler hem ERP kurulumunun hem de sonraki değişikliklerin dayanağı olur; yeni bir çalışan ya da yeni bir yönetici geldiğinde sistemin neden böyle kurulduğunu da bu belgeler anlatır:

• Satıştan tahsilata, satın almadan teslime uzanan süreç haritaları.
• İstisna ve özel durum listesi; her biri için kimin karar verdiği.
• Rol ve yetki tablosu: kim neyi görür, kim neyi onaylar.
• Veri kaynaklarını ve bunların birbirine nasıl bağlanacağını gösteren entegrasyon haritası.
• İlk fazın kapsamı ve sonraki fazlarda eklenecek alanların sırası.

Yaklaşımımız: ERP işletmeye uysun

YazSis ERP’yi dört ilkeye göre kuruyoruz. Bu ilkeler, süreç analizinin sonunda neyin kararlaştırılacağını da belirler:

• Mevcut sistemi koru: Çalışan bir ERP varsa sökülmez; eksik kalan süreçler tamamlanır.
• Özel modülle genişlet: Standart ürünün karşılamadığı iş akışı, kuruma göre geliştirilir.
• Veriyi birleştir: Ortak bilgi akışı, API ve veri tabanı entegrasyonlarıyla kurulur.
• Ölç ve iyileştir: Yönetim raporları darboğazı ve sonucu görünür kılar.

Süreçlerinizi birlikte haritalamak ve ilk fazın kapsamını belirlemek isterseniz YazSis ERP sayfasından bize ulaşabilirsiniz.