- Mevcut işleyiş
- Kontrol noktaları
- Uygun çözüm
Sipariş müşteriden e-postayla geliyor. Satış ekibi bilgileri Excel’e yazıyor, yöneticiye onaya gönderiyor. Onay geldiğinde başka bir çalışan aynı siparişi ERP’ye tekrar giriyor.
Sonra müşteri miktarı değiştiriyor.
Excel güncellendi mi? Yönetici hangi miktarı onayladı? ERP’deki kayıt son haliyle aynı mı?
İşletmenizde benzer sorular sık soruluyorsa çözüm arayışına başlamış olabilirsiniz. Ancak ihtiyacınızı “Yeni bir program istiyoruz” diye anlatmak zorunda değilsiniz. Önce günlük işleyişte nerede zorlandığınızı ortaya koymak, uygun çözümü belirlemek için daha iyi bir başlangıçtır.
Bu rehberde, temsili bir sipariş süreci üzerinden ERP entegrasyonu veya özel yazılım öncesinde netleştirilebilecek yedi soruyu ele alıyoruz. Örnek, gerçek bir müşteri projesini veya ölçülmüş kazancı temsil etmez.
1. Sipariş bugün hangi adımlardan geçiyor?
İlk olarak mevcut işleyişi, olması gerektiğini düşündüğünüz şekliyle değil, bugün gerçekten uygulandığı haliyle anlatın.
Sipariş nereden geliyor? Bilgiyi ilk kim kaydediyor? Kim kontrol ediyor, kim onaylıyor? ERP kaydını kim oluşturuyor? Sonraki ekip siparişten nasıl haberdar oluyor?
Temsili işletmemizde süreç şöyle ilerliyor:
Müşteri e-postası → Satış ekibinin Excel kaydı → Yönetici onayı → Ofis ekibinin ERP kaydı
Bu akışta e-posta, Excel ve ERP birlikte kullanılıyor. Birden fazla araç kullanılması tek başına sorun değildir. İncelenmesi gereken, bu araçlar arasındaki geçişlerin nasıl yürütüldüğüdür.
Örneğin onay yalnızca e-postada kalıyorsa, ERP’ye kayıt yapan kişinin doğru onay ve sipariş sürümünü nasıl bulduğu önem kazanır.
- Müşteri e-postası
- Excel kaydı
- Yönetici onayı
- ERP’ye yeniden giriş
2. En çok nerede tekrar, hata veya gecikme yaşanıyor?
“İşler çok zaman alıyor” ifadesi başlangıç için değerlidir. Sorunu somut bir işlemle anlatmak ise çözümün kapsamını belirlemeyi kolaylaştırır.
Temsili siparişimizde müşteri, ürün ve miktar bilgileri önce Excel’e, ardından ERP’ye giriliyor. Müşteri değişiklik istediğinde iki kaydın da güncellenmesi gerekiyor. Çalışanlar bazen son onaylı miktarı bulmak için eski e-postaları kontrol ediyor.
Burada birbirinden farklı üç ihtiyaç olabilir:
- Aynı bilgiyi yeniden yazmayı azaltmak.
- Siparişin güncel sürümünü ayırt etmek.
- İşlemin kimde ve hangi aşamada beklediğini görmek.
İlk görüşme öncesinde birkaç gerçek işlem örneği hazırlamak faydalıdır. Günlük sipariş adedi, yeniden giriş yapılan alanlar ve karşılaşılan hata türleri not edilebilir.
Henüz ölçüm yapılmadıysa bir süre veya tasarruf oranı tahmin etmek gerekmez. Önce mevcut durum anlaşılır; iyileşmenin nasıl değerlendirileceği bundan sonra belirlenir.
3. Yeni yazılım mı gerekiyor, mevcut sistem yeterli olabilir mi?
Tekrar eden bir iş görüldüğünde ilk kararın yeni uygulama geliştirmek olması gerekmez.
Önce kullanılan ERP’nin mevcut özellikleri, ayarları, yetkileri ve çalışma biçimi incelenmelidir. İhtiyaç, mevcut bir özelliğin doğru kullanılması veya kullanıcı eğitimiyle karşılanabilir.
Sorunun niteliğine göre farklı yollar değerlendirilebilir:
| Yaşanan ihtiyaç | Önce değerlendirilecek yaklaşım |
|---|---|
| Siparişin ERP’de nasıl takip edileceği bilinmiyor. | Mevcut özellikler, kullanım düzeni ve eğitim |
| Kayıtlar mevcut, ancak bekleyen siparişler topluca görülemiyor. | Standart rapor veya ihtiyaca uygun raporlama |
| Sipariş ayrı bir uygulamada oluşuyor ve ERP’ye yeniden yazılıyor. | Sistemler arasında entegrasyon |
| Mevcut araçlar gerekli giriş, kontrol veya onay akışını karşılamıyor. | Uygun hazır çözüm veya özel uygulama |
Bu seçenekler birlikte de kullanılabilir. Örneğin bir sipariş ekranı ERP ile entegre çalışırken, yönetici bekleyen işlemleri ayrı bir rapordan izleyebilir.
Hangi yaklaşımın uygun olduğu, kullanılan ERP sürümü, lisans kapsamı, mevcut altyapı ve iş kuralları incelendikten sonra netleşir.
4. Hangi bilgi, hangi sistemden alınacak?
“Programlar birbirine bağlansın” demek, veri akışını tarif etmek için yeterli değildir.
Her bilginin kaynağı, gideceği yer ve aktarılacağı an belirlenmelidir. Aynı müşteri veya ürün farklı sistemlerde farklı kodlarla tutuluyorsa eşleştirme ihtiyacı da ortaya çıkar.
Temsili sipariş sürecimiz için başlangıç tablosu şöyle olabilir:
| Bilgi | Önerilen kaynak | Kullanılacağı yer / aktarım anı |
|---|---|---|
| Müşteri ve ürün kartları | ERP | Sipariş girişinde seçilebilmesi için uygulamada gösterilir. |
| Sipariş miktarı ve müşteri talebi | Sipariş giriş ekranı | Kontrol ve onay sürecinde kullanılır. |
| Onaylanan sipariş | Sipariş uygulaması | Gerekli kontrollerden sonra ERP’ye aktarılır. |
| ERP sipariş numarası ve aktarım sonucu | ERP / entegrasyon sonucu | İşlemin durumunu göstermek için uygulamaya geri alınır. |
Fiyat, iskonto, depo ve teslim tarihi gibi alanların kaynağı ayrıca belirlenmelidir. Örneğin fiyatı kimin değiştirebileceği veya farklı depo seçiminin ek onay gerektirip gerektirmediği iş kuralıdır.
Aktarımın anlık mı, belirli aralıklarla mı yapılacağı da gerçek kullanım ihtiyacına göre değerlendirilir.
- Sipariş girişi
- Bilgi kontrolü
- Yetkili onayı
- ERP aktarımı ve sonuç
5. İşlem her zaman normal ilerlemezse ne olacak?
Bir çözümü değerlendirirken yalnızca başarılı sipariş örneğini konuşmak eksik kalır. Günlük çalışmada değişiklikler, eksik bilgiler ve bağlantı sorunları da yaşanabilir.
Temsili sürecimizde şu durumların karşılığı belirlenmelidir:
Yönetici siparişi reddederse: Sipariş ERP’ye aktarılmamalı; ret durumu ve gerekiyorsa açıklaması ilgili kullanıcı tarafından görülebilmelidir.
Müşteri onaydan sonra miktarı değiştirirse: Değişikliğin yeniden onay gerektirip gerektirmediği net olmalıdır. Önceki onayın hangi sipariş sürümüne ait olduğu anlaşılmalıdır.
ERP’ye aktarım başarısız olursa: Kullanıcı siparişin aktarıldığını sanmamalıdır. Başarısız işlem görünür olmalı ve kim tarafından ele alınacağı belirlenmelidir.
Aktarım tekrar denenirse: Aynı siparişin ikinci kez oluşmasını önleyecek kontrol tasarlanmalıdır. Özellikle bağlantı kesildiğinde işlemin ERP’de oluşup oluşmadığı kontrol edilmeden körlemesine yeniden gönderilmemelidir.
ERP’ye aktarılmış sipariş iptal edilirse: İptalin hangi sistemde başlatılacağı, kim tarafından onaylanacağı ve diğer sisteme nasıl yansıyacağı kararlaştırılmalıdır.
Bu sorular, çözümün günlük çalışmada nasıl kullanılacağını ortaya çıkarır.
6. İlk aşamada neler yapılacak?
Sipariş süreci konuşulurken tahsilat, sevkiyat, stok rezervasyonu ve müşteri portalı gibi başka ihtiyaçlar da gündeme gelebilir.
Bunlar değerli başlıklardır. Ancak hepsini ilk aşamaya almak, öncelikli sorunun çözümünü zorlaştırabilir.
Temsili örneğimizde ilk kapsam şöyle sınırlandırılabilir:
İlk aşamaya dahil:
- Siparişin uygulamada kaydedilmesi.
- Yetkili kişinin kontrol ve onayı.
- Onaylanan siparişin ERP’ye aktarılması.
- Aktarım sonucunun ve ERP sipariş numarasının gösterilmesi.
- Başarısız işlemlerin izlenmesi.
Sonraki değerlendirmeye bırakılanlar:
- Tahsilat takibi.
- Sevkiyat planlama.
- Müşterinin kendi siparişini gireceği portal.
- Gelişmiş yönetim raporları.
Kapsam dışında bırakmak, bu işlerin yapılmayacağı anlamına gelmez. İlk aşamada hangi sorunun çözüleceğini açık hale getirir.
- İlk kapsam
- Örnek işlemler
- Kabul kontrolleri
7. Çözümün doğru çalıştığını nasıl kontrol edeceğiz?
Ekranın açılması veya siparişin bir kez aktarılması, bütün sürecin doğru çalıştığını göstermez.
Başlangıçta, kontrol edilecek örnek işlemler ve beklenen sonuçlar belirlenmelidir.
Temsili sipariş akışımızda şu kontroller kullanılabilir:
| Kontrol senaryosu | Beklenen sonuç |
|---|---|
| Onaylı sipariş aktarılır. | Doğru müşteri, ürün, miktar ve kararlaştırılan diğer alanlarla ERP’de tek kayıt oluşur. |
| Sipariş reddedilir. | ERP’de sipariş oluşmaz; ret durumu görünür. |
| Zorunlu bilgi eksiktir. | İşlem uygun aşamada durdurulur ve eksiklik kullanıcıya açıklanır. |
| Aktarım sırasında bağlantı kesilir. | İşlemin sonucu kontrol edilebilir; belirsiz durum başarılı gösterilmez. |
| Aynı işlem yeniden denenir. | Mükerrer sipariş oluşmaz. |
| Yetkisiz kullanıcı onay vermeye çalışır. | İşlem yetki kurallarına göre engellenir. |
Bu kontroller, işletmenin süreci bilen kullanıcılarıyla birlikte yapılmalıdır. Beklenen davranışlar netleştiğinde hem geliştirme hem de teslim değerlendirmesi daha anlaşılır olur.
İhtiyacınızı tek paragrafta anlatabilirsiniz
PROIT ile ilk görüşme için uzun bir teknik doküman hazırlamanız gerekmez. Aşağıdaki şablonu kendi işleyişinize göre doldurabilirsiniz:
Bugün [işlemi], [kişiler veya bölümler] tarafından [kullanılan sistemlerde] yürütüyoruz. En çok [tekrar, hata veya gecikme] noktasında zorlanıyoruz. İlk aşamada [beklenen işleyişi] istiyoruz. [Diğer işler] bu aşamanın dışında kalabilir. Sonucu [örnek işlemler ve kontrol koşullarıyla] doğrulamak istiyoruz.
Sipariş örneğimizin kısa ihtiyaç tanımı şöyle olur:
Siparişleri satış ekibi e-postadan alıp Excel’e yazıyor; yönetici onayından sonra ofis ekibi ERP’ye tekrar giriyor. Aynı bilgilerin yeniden yazılması ve onaylanan sürümün takibi konusunda zorlanıyoruz. Önce mevcut ERP olanaklarının yeterli olup olmadığını değerlendirmek istiyoruz. Ek çözüm gerekirse ilk kapsamımız sipariş girişi, onay, ERP aktarımı ve durum takibi olacak. Tahsilat ve sevkiyat planlaması bu aşamanın dışında kalabilir. Doğru veriyle tek kayıt oluşmasını ve başarısız işlemlerin izlenebilmesini örnek siparişlerle kontrol edeceğiz.
İşleminizi anlatın, uygun çözümü birlikte değerlendirelim
İhtiyacınızın adını önceden koymanız gerekmez. “Entegrasyon mu, özel yazılım mı?” sorusunu, mevcut sistemlerinizi ve zorlandığınız işlemi inceledikten sonra birlikte yanıtlayabiliriz.
PROIT olarak Mikro ERP danışmanlığı, ERP entegrasyonu, özel yazılım ve raporlama çalışmalarında önce işletmenin mevcut işleyişini anlamaya odaklanıyoruz.
Bugün tekrar tekrar yaptığınız veya takibinde zorlandığınız bir işlemi bizimle paylaşın. İlk adımı, o süreci birlikte netleştirerek atalım.