Önce Teşhis: ERP'de Yeni Yol Pratikte Neye Benziyor?
Serinin ilk üç yazısı bir mekanizmayı kurdu: adam-gün modeli girdiyi fiyatladığı için teşhisi ucuza satmak zorundaydı; yapay zekâ mekanik işleri ucuzlatınca kararın kalitesi tek gerçek ayrım haline geldi. Geriye tek soru kalıyor: bu mekanizma bir projede nasıl görünür? Bu yazı yeni bir soru sormuyor — sırayı anlatıyor. Önce teşhis diyen bir ERP yolculuğu adım adım nasıl ilerler?
Yeni Yolun Beş Adımı
- Ölç: Demo izlemeden, teklif toplamadan önce mevcut durumu sayıya dökün — süreçlerin ne kadarı yazılı, ana veri ne kadar temiz, kim hangi kararın sahibi. Ölçüm yoksa geri kalan her adım tahmine dayanır.
- Teşhis et: Ölçümü bulguya çevirin. "Stok doğruluğu düşük" bir gözlemdir; "sayım sonrası düzeltme kaydı hangi depoda, hangi ürün grubunda yoğunlaşıyor" teşhistir. Teşhis, hangi sorunun çözülmeye değer olduğunu söyler.
- Ölçütü yaz: Projenin başarı tanımını daha başlamadan, sayıyla ve tarihle yazın. "Canlıya geçiş" bir başarı ölçütü değildir; "ay kapanışı beş iş gününden ikiye iner" ölçüttür. Ölçüt, satıcıdan bağımsız doğrulanabilir olmalı.
- Fazı bağımlılığa göre kur: Faz sırasını modül iştahı değil, teknik bağımlılık belirlesin. Bir faz, kendinden önceki fazın çıktısı olmadan çalışmıyorsa sıra tartışmaya kapalıdır.
- Kabulü kanıta bağla: Her fazın sonunda "çalışıyor" değil, "şu senaryo, şu veriyle, şu kişi tarafından koşuldu ve geçti" yazsın. Kabul kanıta bağlanmadıysa devir toplantısı bir tartışmaya dönüşür.
Eski Yol ile Önce Teşhis Yolunun Farkı
İki yol aynı işleri farklı sırada yapmıyor; farklı kararları farklı bilgi düzeyinde veriyor. Fark, tabloda net görünüyor:
| Karar | Eski yol | Önce teşhis yolu |
|---|---|---|
| Kapsam | Teklif aşamasında, en az bilgiyle | Ölçüm sonrası, bulguya dayanarak |
| Ürün seçimi | İlk soru: hangi marka? | Son soru: hangi yetenek, hangi ölçütle? |
| Faz sırası | Satıcının teslim takvimine göre | Teknik bağımlılığa göre |
| Kabul ölçütü | "Canlıya geçildi" | Yazılı senaryo + kanıt + onaylayan kişi |
| Bütçenin ağırlığı | Kurulum ve mekanik işte | Teşhis ve karar kalitesinde |
| Riskin sahibi | Tümüyle müşteride | Ölçüte bağlı olarak paylaşılır |
Ürün Adı Değil, Yetenek Kategorisi
Önce teşhis yolunun en görünür sonucu, ürün seçiminin sıradaki yerinin değişmesidir. Karar bir marka adıyla değil, üç parçayla verilir: hangi yetenek, hangi ölçütle, hangi ön koşulla. "Ürün ağacı yönetimi" bir yetenek kategorisidir; "çok seviyeli ürün ağacında revizyon geçmişi tutulabiliyor mu" o kategorinin ölçütüdür; "ürün ana verisi tekilleşmiş olmalı" ise ön koşuludur.
Bu üçlü, satıcıya sorulacak soruları da üretir — ve o sorular şartnamenin iskeletine dönüşür. Marka sorusu ortadan kalkmaz; sıralamada sona çekilir. Çünkü bir ürünün doğru seçim olup olmadığı, ancak yetenek ve ölçüt yazıldıktan sonra cevaplanabilir bir sorudur. Tersi sırayla ilerleyen projelerde şartname, seçilmiş ürünün özellik listesinden geriye doğru yazılır.
Faz Sırası Bağımlılıkla Kurulur
Faz planı çoğu projede pazarlık konusudur: hangi modülün önce açılacağı, departmanların iştahına ya da satıcının teslim takvimine göre belirlenir. Önce teşhis yolunda bu sıra teknik bir kısıttır. Birkaç somut örnek:
- Ürün ağacı ve iş emri akışı çalışmadan üretim yürütme kurulmaz — yürütme, ağacın çıktısını tüketir.
- Stok hareketleri doğru kaydedilmeden maliyetlendirme anlamlı sonuç vermez; maliyet, hareketin türevidir.
- Müşteri ve ürün ana verisi tekilleşmeden satış raporu güvenilir olmaz — mükerrer kayıt, raporu sessizce bozar.
Bu bağımlılıklar ihlal edildiğinde proje durmaz; daha kötüsü olur — yanlış sırayla kurulan faz çalışıyor görünür, sorun ancak veri birikince ortaya çıkar. Faz sırasını bağımlılığa bağlamak, bu gecikmeli hatayı baştan engeller.
Kabul, Kanıta Bağlanır
Projelerin en pahalı anı devir toplantısıdır: "bu iş kapsamdaydı" ile "bu ek geliştirme" arasındaki tartışma, faturanın hangi tarafa çıkacağını belirler. Bu tartışmanın önüne geçmenin tek yolu, kabulü baştan kanıta bağlamaktır.
Pratikte bu şu demek: her kabul senaryosunun sonucu yalnız "geçti/kaldı" olarak değil, kaldıysa sebebiyle sınıflandırılarak kaydedilir — eksik konfigürasyon mu, eksik veri mi, kapsam dışı bir talep mi, yoksa gerçek bir hata mı? Bu dört sebep dört farklı tarafa fatura çıkarır. Yanına da onaylayan kişinin adı yazılır. Sınıflandırma yapılmadığında bütün "kaldı" kayıtları tek yığına düşer ve devir toplantısında kimin haklı olduğu, kaydın değil sesin yüksekliğinin meselesi olur.
Nereden Başlanır?
Beş adımın ilki ölçüm; ölçümün de bir başlangıç noktası var. Kendi projenizin risk profilini görmek için 10 soruluk ERP Risk Skoru değerlendirmesini kullanabilirsiniz: süreç olgunluğu, yönetim sahipliği, değişim yönetimi, veri kalitesi, iç kaynak, kapsam netliği, bütçe gerçekçiliği, özelleştirme iştahı, takvim ve ekip deneyimi — on boyut, ağırlıklarıyla birlikte puanlanıyor ve dört risk bandından birine düşüyorsunuz. Sonuç bir tahmindir, teşhis değildir: nereye bakmanız gerektiğini söyler, ne yapmanız gerektiğini değil. Ama beş adımlık yolun ilk adımını atmış olursunuz.
Bu yazı 4 bölümlük serinin sonuncusudur.
1. Adam-Gün Satan
Danışmanlığın Sonu mu Geliyor?
2. Yapay Zekâ Vaatlerinin
Röntgenini Çekelim
3. Yapay Zekâ
ERP'de Neyi Ucuzlattı, Neyi Değerli Kıldı?
4. Önce Teşhis: ERP'de Yeni Yol Pratikte Neye Benziyor? (bu yazı)
Yeni analizleri kaçırmamak için MindDX-Digital Excellence bültenine abone olun.