ERP Öncesi Süreç Yönetimi. Bu seride;
✓ Bölüm 1: ERP Projelerinin Başarısı Yazılımla Değil, Süreçlerle Başlar (Şu an okuyorsunuz)
○ Bölüm 2: Süreç Haritalama Nasıl Yapılır?
○ Bölüm 3: Süreç Haritasından Sürekli İyileştirmeye, başlıklı yazılar yer almaktadır.
ERP Projelerinin Başarısı Yazılımla Değil, Süreçlerle Başlar
Dijital Dönüşümün En Çok Göz Ardı Edilen Gerçeği
ERP Öncesi Süreç Yönetimi – Özet
Bir ERP projesi başladığında, masada konuşulan ilk konu neredeyse her zaman yazılımdır: hangi paket, hangi danışman, hangi bütçe, hangi takvim. Oysa bu projelerin gerçek kaderi, yazılım seçilmeden çok önce, işletmenin kendi süreçlerini ne kadar net tanıdığında belirlenir.
Bu makale, bir işletmenin ERP yatırımından beklediği faydayı gerçekten alabilmesi için neden önce kendi süreçlerini tanımlaması gerektiğini anlatır. Amaç, bir yazılım kılavuzu sunmak değil, bir bakış açısı kazandırmaktır: ERP bir teknoloji kararı değil, bir organizasyonel netlik kararıdır. Bu netlik yoksa, en kapsamlı ve en pahalı ERP paketi bile düzen getirmez; sadece mevcut düzensizliği daha hızlı ve daha kalıcı hale getirir.
Bu yazı, “ERP’den Önce Süreç Yönetimi” serisinin ilk makalesidir ve süreç yönetimini bir danışmanlık hizmeti olarak değil, her yöneticinin sahip çıkması gereken bir sorumluluk olarak ele alır.
Bu Yazıda Neler Öğreneceksiniz?
Bu makaleyi okuduktan sonra, kendi işletmenizdeki bir ERP kararına (ister yeni başlıyor olun, ister devam eden bir projeyi düzeltmeye çalışıyor olun) farklı bir çerçeveden bakacaksınız. Somut olarak şunları göreceksiniz:
- ERP yazılımının gerçekte ne yaptığını ve neyi asla yapmadığını
- Fabrikanızda yazılı olan süreç ile gerçekte işleyen sürecin neden aynı şey olmadığını
- Süreç belirsizliğinin bir ERP projesinde nasıl somut bir maliyet zincirine dönüştüğünü
- Süreç haritalamanın neden tek başına yeterli bir çalışma olmadığını
- ERP’ye geçmeden önce masanızda bulunması gereken somut unsurları
- Türkiye’deki üretim işletmelerinde en sık tekrarlanan üç ERP yanılgısını
Her bölüm, gerçekçi fabrika senaryolarıyla desteklenmiştir. Amaç sizi ikna etmek değil, size bir işletme sahibi ve yönetici olarak belki de daha önce hiç bu şekilde çerçevelemediğiniz bir soruyu sormaktır: Biz süreçlerimizi, bir sisteme anlatabilecek kadar tanıyor muyuz?
Giriş: ERP Kararının Yanlış Başladığı Yer
Bir fabrika sahibiyle ilk görüşmenin neredeyse tamamı aynı şekilde başlar. Masaya oturulur, birkaç yazılım logosu konuşulur, bir bütçe rakamı telaffuz edilir ve ardından şu cümle gelir: “Biz artık bir ERP’ye geçmeliyiz.” Sorulan soru genellikle bellidir: Hangi ERP? SAP mi, Microsoft mu, yerli bir çözüm mü? Bulut mu, yerinde kurulum mu? Hangi danışmanlık firması?
Bu sorular yanlış değildir. Ancak zamanlaması yanlıştır.
Bir işletme bu soruları sormadan önce kendine çok daha temel bir soru sormalıdır: Biz, bir üretim planlama kararını nasıl verdiğimizi, bir satınalma onayının hangi kritere göre işlediğini, bir kalite red kararının hangi ölçüte dayandığını yazılı ve tutarlı biçimde açıklayabiliyor muyuz? Çoğu işletmede bu sorunun cevabı hayırdır; ama bu hayır, toplantı odasında hiç yüksek sesle söylenmez. Çünkü herkes, “biz zaten yıllardır bu işi yapıyoruz, süreçlerimizi biliyoruz” varsayımıyla hareket eder.
İşte tam bu varsayım, ERP projelerinin çoğunun asıl başarısızlık nedenidir. Yazılım eksik kalmaz; kod satırları doğru yazılır, modüller doğru kurulur, sunucular doğru çalışır. Eksik kalan, o yazılıma girilecek olan mantıktır. Bir üretim planlama modülü size “acil sipariş nedir” sorusunun cevabını vermez; bu cevabı siz vermek zorundasınızdır. Bir satınalma modülü size “hangi tutarda kim onaylar” sorusunu çözmez; bu hiyerarşiyi siz netleştirmek zorundasınızdır.
Bu makale, ERP’yi bir yazılım projesi olarak değil, bir organizasyonel netlik projesi olarak ele almanızı önerir. Danışmanlık pratiğimde gördüğüm en pahalı hatalar, yanlış yazılım seçiminden değil, netleştirilmemiş süreçlerin bir sisteme aceleyle aktarılmasından doğdu. Bu yazı boyunca, bu hatanın nasıl oluştuğunu, nasıl fark edilebileceğini ve nasıl önlenebileceğini, gerçek fabrika senaryolarıyla birlikte adım adım ele alacağız.
Türkiye’de ERP Projelerinin Genel Görünümü
Türkiye’deki üretim işletmelerinin büyük bölümü, ERP’ye iki farklı yoldan ulaşır. Birinci yol organik büyümedir: aile şirketi olarak başlayan bir işletme, üretim hacmi büyüdükçe Excel tablolarının ve sözlü talimatların yetmediği bir noktaya gelir. İkinci yol ise dışsal baskıdır: bir ana sanayi firmasının tedarikçisinden izlenebilirlik istemesi, bir ihracat pazarının belgelendirme talep etmesi veya bir yatırımcının kurumsallaşma şartı koşması.
Her iki yolda da ortak bir örüntü tekrarlanır: karar, “artık bir sisteme ihtiyacımız var” cümlesiyle başlar ve çok hızlı biçimde “hangi sistem” sorusuna atlar. Süreçlerin mevcut durumunun tanımlanması, çoğu zaman ya hiç yapılmaz ya da danışmanlık firmasının “analiz” adı altında yürüttüğü, işletmenin kendi katılımının sınırlı kaldığı kısa bir egzersize indirgenir.
Bunun sonucunda ortaya çıkan tablo, sektörde şaşırtıcı derecede tekrarlayan bir desendir:
| Gözlem | Açıklama |
| Modül aktif, süreç belirsiz | ERP modülleri teknik olarak çalışır durumdadır, ancak hangi kararın hangi kritere göre verildiği hâlâ kişilere bağlıdır. |
| Veri var, güven yok | Sistemde stok, sipariş ve üretim verisi tutulur, ancak yöneticiler kritik kararları hâlâ sahadan telefonla teyit ederek alır. |
| Özelleştirme sarmalı | Süreç netleşmediği için her belirsizlik bir “özel geliştirme” talebine dönüşür, proje kapsamı sürekli genişler. |
| İkinci sistem gölgesi | Kullanıcılar ERP’ye paralel olarak kendi Excel tablolarını sürdürmeye devam eder, çünkü sisteme tam güvenmezler. |
Bu tablo bir istisna değil, gözlemlenen genel eğilimdir. Danışmanlık sürecinde defalarca karşılaştığım bir sahne bunu net biçimde özetler: bir üretim planlama toplantısında, ekranda ERP’nin ürettiği bir çizelge açıktır, ancak toplantıdaki herkes gözünü ekrana değil, planlama şefinin elindeki kağıda diker. Sistem vardır, ama karar hâlâ kağıttan alınır.
| DANIŞMAN NOTU Bir işletmenin ERP’ye ne kadar hazır olduğunu anlamanın en pratik yolu, “sisteminiz kaç yıldır çalışıyor” sorusu değildir. Asıl soru şudur: “Sisteminiz olmadan bir gün çalışsanız, üretim durur mu, yoksa insanlar eski yöntemle devam eder mi?” Cevap ikincisiyse, sistem henüz gerçek karar mekanizması değil, bir kayıt defteridir. |
Bu tablonun tekrarlanmasının en sık nedeni, süreç çalışmasının bir maliyet kalemi olarak görülmesidir. Oysa yaşanan tam tersidir: süreç çalışması atlanınca proje daha ucuz başlar, ancak çok daha pahalı biter; çünkü belirsizlik, projenin ortasında özelleştirme, gecikme ve kullanıcı direnişi olarak geri döner.
| EN SIK YAPILAN HATA İşletmeler süreç çalışmasını “projeyi yavaşlatan bir bürokrasi” olarak görür ve bu adımı atlayarak zaman kazandıklarını düşünür. Gerçekte olan, riskin projenin başından ortasına ve sonuna ötelenmesidir; üstelik daha yüksek bir bedelle. |
| YÖNETİCİYE ÖZEL ERP projesine başlamadan önce, yönetim kurulu gündemine tek bir madde ekleyin: “Kritik on kararımızı (kimin, hangi kritere göre verdiğini) yazılı olarak açıklayabiliyor muyuz?” Bu sorunun cevabı net değilse, yazılım seçimini ertelemek, projeyi geciktirmek değil, projeyi korumaktır. |
Türkiye’deki üretim işletmelerinin çoğunda tekrarlanan bu tablo, aslında iyi haber de taşır: sorun teknik değil, çerçevesel bir sorundur ve çerçeve değiştirilebilir. Aşağıdaki bölümde, bu çerçeve değişikliğinin ilk adımını ele alıyoruz: ERP projesine başlarken sorulan sorunun neden çoğu zaman yanlış olduğunu ve doğru sorunun ne olması gerektiğini.
Bölüm 1: Yanlış Soruyla Başlayan ERP Projeleri
Bir yönetim kurulu toplantısını hayal edin. Gündemde tek bir madde vardır: ERP yatırımı. Genel müdür söz alır: “Üç teklif aldık. İkisi yerli, biri yabancı. Fiyatlar şu aralıkta, uygulama süresi şu kadar.” Yönetim kurulu üyeleri sorular sormaya başlar: Bulut mu, yerinde kurulum mu? Referans müşterileri kimler? Destek ekibi ne kadar hızlı dönüyor?
Bu, gördüğüm yüzlerce toplantının neredeyse birebir kopyasıdır. Ve bu toplantıların hiçbirinde, gerçekten hiçbirinde, şu soru sorulmaz: “Bizim üretim planlama sürecimiz, satınalma onay hiyerarşimiz, kalite kabul kriterlerimiz yazılı ve tutarlı mı?”
Bu soru sorulmaz, çünkü sorulmasına gerek olmadığı düşünülür. Herkes, işletmenin nasıl çalıştığını zaten bildiğini varsayar. Oysa bir süreç hakkında “biliyoruz” demek ile o süreci başka birine, ya da bir yazılım sistemine, tutarlı biçimde anlatabilmek, tamamen farklı iki yetenektir. Birincisi sezgiseldir, ikincisi disiplinlidir.
Bunu somutlaştıran bir sahne, orta ölçekli bir mobilya üretim işletmesinde yaşanmıştı. Yönetim kurulu, üç ay süren bir değerlendirme sonunda bir ERP paketine karar verir. Karar kriterleri modülerlik, fiyat ve referans sayısıdır. Proje başladığında danışmanlık ekibi ilk toplantıda basit bir soru sorar: “Bir müşteri siparişi geldiğinde, hangi ürünün önce üretileceğine kim, hangi kritere göre karar veriyor?” Toplantı odasındaki dört yönetici dört farklı cevap verir. Üretim müdürü “kapasiteye göre” der, satış müdürü “müşteri önceliğine göre” der, planlama şefi “hangi malzeme depoda hazırsa ona göre” der, genel müdür ise “bana sorulur, ben karar veririm” der. Dördü de haklıdır, çünkü hiçbiri yanlış değildir, hepsi farklı zamanlarda gerçekten böyle karar vermiştir. Ama bu, bir sürecin var olduğu anlamına gelmez; sadece dört farklı alışkanlığın var olduğu anlamına gelir.
| SAHADAN GÖZLEM Bir sürecin gerçekten tanımlı olup olmadığını anlamanın en hızlı yolu, aynı soruyu üç farklı yöneticiye sormaktır. Üç farklı cevap alıyorsanız, elinizde bir süreç değil, üç farklı gelenek (alışkanlık) vardır. |
Asıl mesele, hangi ERP’nin bu dört cevabı “doğru” kabul edeceği değildir. Mesele, dört cevaptan hangisinin işletme için gerçekten doğru olduğuna işletmenin kendisinin karar vermemiş olmasıdır. Bir yazılım, sizin yerinize bu kararı veremez. Yapabileceği tek şey, siz karar verdikten sonra o kararı tutarlı biçimde uygulamaktır.
| EN SIK YAPILAN HATA İşletmeler, ERP seçim sürecini bir “hangi araç daha iyi” değerlendirmesi olarak yürütür; oysa asıl değerlendirilmesi gereken, “biz bu aracı besleyecek kadar net bir mantığa sahip miyiz” sorusudur. |
| Toplantıda Konuşulan Soru | Aslında Sorulması Gereken Soru |
| Hangi ERP paketi bize uygun? | Kritik kararlarımızı hangi mantıkla veriyoruz? |
| Uygulama kaç ayda biter? | Süreçlerimizi netleştirmek kaç ay sürer? |
| Hangi danışmanlık firmasıyla çalışalım? | Süreç sahipliğini kim üstlenecek: danışman mı, biz mi? |
| Fiyat teklifleri arasında fark ne? | Belirsizlik bize projenin neresinde faturayı kesecek? |
| YÖNETİCİYE ÖZEL Bir sonraki ERP değerlendirme toplantınızda, gündeme yazılım karşılaştırmasından önce tek bir soruyu koyun: “En kritik beş kararımızı, üç farklı yöneticiye sorduğumuzda aynı cevabı alır mıyız?” Bu sorunun cevabı belirsizse, yazılım seçimi henüz gündemde olmamalıdır. |
Bu gözlem bizi doğal olarak bir sonraki soruya taşır: madem ERP bu belirsizliği çözmüyor, peki ERP gerçekte ne yapıyor? Çoğu yöneticinin zihnindeki “sistem bize düzen getirecek” beklentisi nereden geliyor ve bu beklenti neden yanlış? Aşağıdaki bölümde, ERP’nin gerçekte nasıl çalıştığını ve neden bir düzen üretici değil, bir düzen çoğaltıcısı olduğunu inceliyoruz.
Bölüm 2: ERP Aslında Ne Yapar, Ne Yapmaz?
ERP kelimesinin arkasında, çoğu yöneticinin zihninde sessizce taşınan bir beklenti vardır: “Sistemi kurunca düzenli hale geliriz.” Bu beklenti o kadar yaygındır ki, birçok proje teklifinde bile örtük biçimde satılır; sanki yazılımın kendisi bir disiplin kaynağıymış gibi.
Gerçek mekanizma bunun tam tersidir. ERP, bir düzen üretici değil, bir çarpandır. Girdiğiniz mantığı büyütür; ister iyi olsun, ister kötü. Bir işletme net tanımlanmış, sahiplenilmiş ve tutarlı bir sürece sahipse, ERP bu süreci hızlandırır, görünür kılar ve ölçeklenebilir hale getirir. Aynı işletme belirsiz, kişiye bağlı ve çelişkili bir mantıkla çalışıyorsa, ERP bu belirsizliği olduğu gibi dijital ortama taşır; üstelik artık kağıt üzerinde olduğu gibi kolayca esnetilemeyen, sistemsel bir belirsizlik haline getirir.
Bunu somutlaştıran bir örnek, aynı ERP paketini iki farklı üretim hattında devreye alan bir metal işleme fabrikasında yaşanmıştı. Fabrikanın bir hattında, iş emri açma ve hammadde tahsis süreci önceden net tanımlanmıştı: hangi siparişin hangi kritere göre önceliklendirileceği, kimin iş emri açabileceği, hangi durumda üretim planlama şefinin devreye gireceği yazılı ve üzerinde mutabık kalınmış bir mantıktı. Bu hatta ERP devreye girdiğinde, planlama süresi kısaldı, iş emirleri daha az hatayla açıldı, veri girişindeki tutarsızlıklar azaldı.
Aynı fabrikanın ikinci hattında ise bu süreç hiç yazılı hale getirilmemişti. Herkes “her zaman yaptığı gibi” iş emri açıyordu: bazen ustabaşının tecrübesine göre, bazen depodaki malzeme durumuna göre, bazen o gün kimin masasında olduğuna göre. ERP bu hatta devreye girdiğinde, sistem bu çelişkili alışkanlıkları olduğu gibi dijitalleştirdi. Farklı vardiyalarda farklı iş emri mantıkları uygulanmaya devam etti; ama artık bu farklılıklar sistemde kayıtlı hale geldiği için, hataları geriye dönük tespit etmek eskisinden daha zor oldu. Aynı yazılım, aynı bütçe, aynı danışmanlık ekibi; iki taban tabana zıt sonuç.
| DANIŞMAN NOTU ERP danışmanları süreç tasarlamaz; süreci sisteme kodlar. Süreç tasarımının sorumluluğu işletmenin kendisindedir. Bu sorumluluğu danışmana devretmek, aslında kararları da danışmana devretmek anlamına gelir; ve danışman, sizin işletmenizin gerçek önceliklerini sizin kadar bilemez. |
Bu ayrım, ERP yatırımının gerçek doğasını netleştirir. Yazılım nötr bir araçtır; ne iyi niyetlidir ne kötü niyetli. Girdiğiniz mantığı sadakatle uygular. Bu nedenle “ERP bize düzen getirecek” cümlesi, “araba bize güvenli sürüş öğretecek” cümlesi kadar yanıltıcıdır: araç, sizin sürüş alışkanlıklarınızı ölçekler, değiştirmez.
| Yaygın Beklenti | Gerçek Mekanizma | Fark Neden Var |
| ERP bize düzen getirir | ERP mevcut mantığı büyütür | Sistem, kendi başına karar mantığı üretmez |
| Sistem devreye girince kafa karışıklığı biter | Kafa karışıklığı sistemde daha görünür ve kalıcı hale gelir | Belirsizlik artık esnek kağıt sürecinde değil, katı sistem kuralında yaşar |
| Danışman süreçlerimizi düzeltir | Danışman süreci koda döker, tasarlamaz | Süreç sahipliği işletmeye aittir, dışarıdan devralınamaz |
| İyi yazılım kötü süreci telafi eder | İyi yazılım kötü süreci büyütür | Çarpan etkisi iki yönlü çalışır |
| EN SIK YAPILAN HATA İşletmeler ERP projesini “mevcut kaosu düzeltecek bir müdahale” olarak satın alır. Oysa ERP, kaosu düzeltmez; kaosu ölçekler. Düzeltme işi, sistemden önce, insan eliyle yapılması gereken bir iştir. |
| YÖNETİCİYE ÖZEL ERP’ye geçmeden önce kendinize şunu sorun: “Bugün elimizdeki süreç mantığını, hiçbir yazılım olmadan, sadece kağıt üzerinde tutarlı biçimde üç farklı kişiye anlatabilir miyiz?” Cevap evetse, ERP bu mantığı büyütecek bir yatırımdır. Cevap hayırsa, ERP yatırımı önce belirsizliği, sonra da onun maliyetini büyütecektir. |
Şimdi doğal bir soru ortaya çıkıyor: Peki işletmeler neden bu belirsizliği fark etmeden ERP projesine giriyor? Cevap, çoğu zaman şu inançta gizlidir: “Biz zaten nasıl çalıştığımızı biliyoruz.” Aşağıdaki bölümde, bu inancın neden çoğu zaman bir yanılsama olduğunu, fabrikada gerçekten olan ile kağıt üzerinde anlatılanın neden aynı şey olmadığını, görüyoruz.
Bölüm 3: Görünmeyen Süreç, Fabrikanın Gerçek İşleyişi ile Anlatılan İşleyişi Arasındaki Uçurum
Her fabrikada iki farklı süreç eş zamanlı olarak yaşar. Birincisi, kalite el kitabında, prosedür dokümanlarında veya ISO belgelerinde yazılı olan süreçtir. İkincisi, gerçekte vardiya değişiminde, ustabaşının kafasında, kalite şefinin gözünde, planlama uzmanının telefon trafiğinde yaşayan süreçtir. Bu iki süreç, çoğu işletmede birbirine yeterince benzemez; ve bu fark, ne kadar uzun süredir çalışılıyorsa o kadar derinleşmiştir.
Yönetim bilimi bu ikinci türe “örtük bilgi” der: bir kişinin deneyim yoluyla edindiği, ancak hiçbir zaman yazıya dökülmemiş karar mantığı. Örtük bilgi kötü bir şey değildir; aksine, birçok işletmenin yıllarca ayakta kalmasını sağlayan gerçek değerdir. Ancak bir ERP projesi söz konusu olduğunda, örtük bilgi ciddi bir risk haline gelir: çünkü sistem, yazılı olmayan hiçbir şeyi bilemez.
Bu ayrımı açık biçimde ortaya koyan bir sahne, bir gıda ambalaj üretim işletmesinin kalite biriminde yaşanmıştı. Üretilen ambalajların sevkiyata uygun olup olmadığına dair nihai karar, yıllardır aynı kalite şefi tarafından verilmektedir. Prosedür dokümanında yazan kriterler ölçülebilir parametrelerdir: kalınlık toleransı, renk sapması, baskı hizalaması. Ancak gerçekte, kalite şefi bu parametrelerin sınırında kalan ürünlerde farklı bir değerlendirme yapmaktadır: “gözle bakınca sorun çıkarmaz” dediği ürünleri kabul etmekte, dokümanda yazmayan, sadece kendi tecrübesine dayanan bir eşiği uygulamaktadır.
ERP projesi kapsamında kalite modülü kurulurken, danışmanlık ekibi bu eşiği sisteme tanımlamak için kalite şefine sorar: “Sınır değerlerdeki kararınızı hangi ek kritere göre veriyorsunuz?” Kalite şefi net bir cevap veremez. “Bakınca anlıyorum” der. Bu cevap, prosedüre değil bir kişiye bağlı, yirmi yıllık bir tecrübeye dayanmaktadır; ve bu tecrübe hiçbir zaman yazıya dökülmemiştir. Sistem bu kararı otomatikleştiremez, çünkü otomatikleştirilecek bir kural yoktur; sadece bir kişide biriken bir sezgi vardır.
| SAHADAN GÖZLEM Bir sürecin en kritik anları, genellikle en az dokümante edilen anlardır. Standart durumlar prosedürde yazılıdır; asıl karar zorluğu yaşanan istisna durumları ise neredeyse hiçbir zaman yazılı değildir; çünkü onlar “nadiren olur” diye ihmal edilir. Oysa ERP projelerinde asıl kırılma noktası, tam olarak bu istisna anlarında yaşanır. |
Bu fark, sadece kalite alanına özgü değildir. Aynı örüntü satınalma onaylarında, üretim planlamasında, depo transferlerinde, hatta insan kaynakları süreçlerinde tekrarlanır. Bir işletmenin resmi organizasyon şemasında “satınalma onayı finans müdürüne aittir” yazabilir; gerçekte ise finans müdürü izinliyken bu onayın muhasebe uzmanı tarafından sözlü mutabakatla verildiği bilinir. Bu, kötü niyetli bir kaçak yol değildir; sadece hiç yazıya dökülmemiş, ama işleyen bir alışkanlıktır.
| EN SIK YAPILAN HATA İşletmeler süreç dokümantasyonunu “zaten elimizde var” varsayımıyla atlar. Oysa elde var olan doküman, genellikle sertifikasyon veya denetim amacıyla yazılmış, günlük gerçekliği tam yansıtmayan bir metindir. Gerçek süreç, dokümanın satır aralarında değil, sahada yaşar. |
| Kağıt Üzerindeki Süreç | Fabrikada Gerçekte Olan | Risk |
| “Kalite kriterleri ölçülebilir parametrelere dayanır” | Sınır değerlerde kalite şefinin sezgisi devreye girer | Sezgi, sisteme aktarılamaz |
| “Satınalma onayı finans müdürüne aittir” | İzin döneminde sözlü mutabakatla ilerler | Onay hiyerarşisi sistemde tıkanır |
| “Üretim planlaması kapasiteye göre yapılır” | Planlama şefi müşteri ilişkisine göre önceliklendirir | Sistem önceliklendirmesi gerçek uygulamayla çelişir |
| YÖNETİCİYE ÖZEL ERP projesine başlamadan önce, her kritik süreçte “en zor karar anını” tespit edin: istisna, sınır durum veya belirsizlik yaşanan anı. O anı kimin, hangi ek bilgiye dayanarak çözdüğünü sorun. Eğer cevap bir kişiye bağlıysa, bu bilgiyi yazıya dökmek, sistemi kurmadan önce yapılması gereken en kritik işlerden biridir. |
Bu fark, tek başına rahatsız edici bir gözlem olarak kalabilir; ama gerçek önemi, bir ERP projesine somut bir maliyet olarak yansıdığında ortaya çıkar. Aşağıdaki bölümde, tam olarak bu mekanizmayı, süreç belirsizliğinin nasıl adım adım bütçe aşımına, takvim gecikmesine ve kullanıcı direncine dönüştüğünü, nedensellik zinciri olarak inceliyoruz.
Bölüm 4: Süreç Tanımsızlığının ERP Projesine Maliyeti
Süreç belirsizliği, bir ERP projesinde tek seferlik bir risk olarak ortaya çıkmaz. Bir zincirleme reaksiyon başlatır; ve bu zincirin her halkası, bir öncekinden daha pahalıdır.
Mekanizma şöyle işler: Bir süreç netleştirilmeden sisteme aktarılmaya çalışıldığında, proje ekibi bir belirsizlikle karşılaşır: örneğin “acil sipariş” tanımının net olmaması. Bu belirsizlik, danışmanlık ekibine bir soru olarak gelir. Danışman, işletmenin kendi kararını vermesini beklemek yerine (çünkü takvim baskısı vardır), genellikle en pratik çözümü önerir: bir özel alan, bir ek kural, bir “geçici” ayar. Bu, tek başına küçük bir karardır. Ancak bu tür kararlar bir projede onlarca kez tekrarlanır; her belirsizlik, bir özelleştirme talebine dönüşür.
Özelleştirmelerin birikmesi iki sonuç doğurur. Birincisi, bütçe ve takvim büyür; çünkü her özel geliştirme ek zaman ve ek maliyet demektir. İkincisi, ve daha kritik olanı, sistem giderek işletmenin gerçek ihtiyacından değil, projenin ilerleyişi sırasında alınan geçici kararlardan oluşan bir yapıya dönüşür. Sistem artık tutarlı bir mantığı değil, farklı zamanlarda farklı kişiler tarafından verilmiş, birbiriyle tam örtüşmeyen kararların toplamını yansıtır.
Bu birikim, go-live anında patlak verir. Kullanıcılar sisteme girdiğinde, kendi gerçek iş akışlarıyla örtüşmeyen kurallarla karşılaşır. Bu uyumsuzluk, kullanıcı direncine dönüşür; insanlar sisteme güvenmemeye başlar, paralel Excel tabloları tutmaya devam eder, “sistem yanlış” dedikleri her durumda eski yönteme geri döner. Bu direnç, projenin teknik olarak tamamlanmasından çok sonra bile, işletmenin ERP’den beklediği faydayı gerçek anlamda hiç alamamasına yol açar.
Bu zincirin nasıl işlediğini gösteren çarpıcı bir örnek, bir dokuma iplik üretim tesisinde yaşanmıştı. İşletme, üretim planlama modülünü devreye alırken “acil sipariş” kavramının net bir tanımını yapmamıştı. Satış ekibi, müşteriden gelen her ısrarlı talebi “acil” olarak işaretliyordu; üretim planlama ekibi ise “acil” ibaresini yalnızca teslim tarihi bir haftadan kısa olan siparişler için kullanıyordu. Sistem devreye girmeden önce bu fark, sözlü iletişimle idare edilebiliyordu; planlama şefi telefon açıp “bu gerçekten acil mi” diye sorabiliyordu. Sistem devreye girdiğinde bu esneklik ortadan kalktı: “acil” işaretlenen her sipariş otomatik olarak üretim çizelgesinin başına geçmeye başladı.
Sonuç, go-live sonrası üç haftalık bir kriz oldu. Üretim çizelgesi günde birkaç kez yeniden düzenlendi, fazla mesai arttı, gerçekten acil olan siparişler bile “acil” etiketinin enflasyonundan dolayı önceliğini kaybetti ve iki önemli müşteriye teslimat gecikmesi yaşandı. Kriz teknik bir hata değildi; sistem tam olarak kendisine söyleneni yapıyordu. Eksik olan, “acil” kelimesinin daha proje başlamadan tek bir ortak tanıma kavuşturulmuş olmasıydı.
| DANIŞMAN NOTU Bir ERP projesinde en pahalı kelimeler, teknik terimler değil, gündelik dilde belirsiz bırakılan kelimelerdir: “acil”, “büyük tutar”, “uygun zaman”, “gerektiğinde”. Bu kelimeler toplantılarda rahatlıkla kullanılır, çünkü herkes kendi zihnindeki tanımla anladığını sanır. Sistem ise hiçbir zihinsel tanım kabul etmez; sadece açık kural kabul eder. |
Bu zincirin en can alıcı yanı, maliyetin çoğunlukla proje bütçesinde ayrı bir kalem olarak görünmemesidir. “Özelleştirme maliyeti” fatura kalemi olarak görünür, ancak “kullanıcı güvensizliği” veya “paralel Excel kullanımı devam ediyor” gibi kalemler hiçbir bilançoda yer almaz; bunlar sessizce, günlük operasyonun içine gömülür ve orada uzun yıllar yaşamaya devam eder.
| Belirsizlik Türü | Tetiklediği Sonuç | Projeye Etkisi |
| Tanımsız öncelik kriteri (“acil” gibi) | Sistem kuralı gerçek uygulamayla çelişir | Go-live sonrası çizelgeleme krizi |
| Belirsiz onay hiyerarşisi | Her istisna özel geliştirme talebine dönüşür | Bütçe ve takvim aşımı |
| Kişiye bağlı karar mantığı (örtük bilgi) | Sistem kararı otomatikleştiremez | Manuel müdahale ve paralel sistem kullanımı |
| Çelişkili departman tanımları | Farklı ekipler sistemi farklı yorumlar | Veri tutarsızlığı ve güven kaybı |
| EN SIK YAPILAN HATA Proje ekipleri, go-live sonrası yaşanan sorunları “kullanıcı eğitimi eksikliği” olarak yorumlar ve ek eğitim oturumları düzenler. Oysa çoğu zaman sorun eğitim değil, tanımdır; kullanıcı sistemi yanlış anlamamıştır, sistem gerçekten de tanımlanmamış bir kuralı uygulamaktadır. |
| YÖNETİCİYE ÖZEL Proje planınıza, “gündelik dilde belirsiz kalan kelimeler” için ayrı bir çalışma oturumu ekleyin. Süreçlerinizde sık geçen ama net tanımlanmamış ifadeleri (“acil”, “öncelikli”, “büyük tutar”, “uygun zaman”) listeleyin ve her biri için ölçülebilir bir tanım üzerinde mutabık kalın. Bu, teknik bir egzersiz değil, yönetim kurulu seviyesinde bir karar sürecidir. |
Buraya kadar, süreç belirsizliğinin nereden geldiğini ve nasıl bir maliyete dönüştüğünü gördük. Ancak bir soru hâlâ cevapsız: süreç belirsizliğini gidermek için bir akış şeması çizmek yeterli midir? Çoğu işletme bu soruya evet der; ve tam da bu noktada, süreç yönetimi ile süreç haritalama arasındaki farkı kaçırır. Aşağıdaki bölümde bu ayrımı netleştiriyoruz.
Bölüm 5: Süreç Yönetimi Nedir, Süreç Haritalama Neden Yeterli Değildir?
Bir süreç haritalama oturumu genellikle iyi hisler bırakır. Duvara yapıştırılan renkli kağıtlar, birlikte çizilen oklar, “işte böyle çalışıyormuşuz” cümlesiyle biten bir toplantı; bu deneyim gerçekten değerlidir. Ancak sık yapılan bir kavram karışıklığı vardır: bir akış şemasına sahip olmak ile bir süreci yönetiyor olmak, aynı şey değildir.
Bir süreç haritası size ne olduğunu gösterir: hangi adım hangi adımdan sonra gelir, hangi adımlar paralel ilerleyebilir, süreç hangi noktada başlar ve biter. Bu, değerli ama eksik bir resimdir. Çünkü bir ERP sistemine bir süreci gerçekten aktarabilmek için üç sorunun daha cevaplanması gerekir: Bu adımı kim yapıyor? Bu adım ne zaman tetikleniyor? Ve en kritik olanı, bu adımdaki karar hangi kurala göre veriliyor?
Bir akış şeması “sipariş onaylanır” kutusunu rahatlıkla çizebilir. Ama bu kutunun içinde gizli kalan soru şudur: onaylayan kimdir, hangi tutara kadar onaylayabilir, hangi durumda bir üst makama yönlendirir? Bu sorular cevaplanmadan çizilen bir akış şeması, güzel görünen ama işlevsiz bir dokümandır; duvarda asılı kalır, ERP’ye aktarılamaz.
Bu farkı gözler önüne seren bir sahne, bir tarım makineleri yedek parça üreticisinde yaşanmıştı. İşletme, satınalma sürecini haritalamak için bir çalıştay düzenlemişti. Ortaya çıkan akış şeması gayet düzenliydi: talep oluşturulur, teklif toplanır, onay alınır, sipariş verilir. Danışmanlık ekibi bu şemayı ERP’ye aktarmadan önce tek bir soru sordu: “Onay kutusunda, kim onaylıyor?” Cevap, toplantıdaki herkesi şaşırttı; çünkü kimse net bir cevap veremedi. “Genellikle genel müdür” dendi, ama “büyük tutarlarda” ifadesi kullanıldığında bu tutarın kaç lira olduğu, kimsenin daha önce hiç yazılı olarak belirlemediği ortaya çıktı. Akış şeması doğruydu; ama karar mantığı hâlâ havada asılıydı.
| DANIŞMAN NOTU Bir süreç haritası genellikle “ne oluyor”u gösterir. Asıl değerli soru ise “kim karar veriyor ve neye göre” sorusudur. Haritayı çizmek kolay kısımdır; karar mantığını netleştirmek zor kısımdır ve ERP projelerinde asıl farkı oluşturan da bu zor kısımdır. |
Süreç yönetimi, tam olarak bu dört unsurun bir arada ele alınmasıdır: görev (ne yapılıyor), olay (ne zaman tetikleniyor), rol (kim yapıyor) ve karar kuralı (hangi kritere göre). Bir işletme bu dördünü net biçimde tanımladığında, elinde artık bir duvar posteri değil, bir sisteme aktarılabilir bir mantık vardır.
| Boyut | Süreç Haritalama | Süreç Yönetimi |
| Odak | Adımların sırası ve akışı | Sahiplik, karar kuralı ve istisna yönetimi |
| Çıktı | Görsel bir şema | Uygulanabilir bir karar mantığı |
| Sorduğu soru | “Ne oluyor?” | “Kim, neye göre karar veriyor?” |
| ERP’ye aktarılabilirlik | Sınırlı; genellikle yeniden çalışma gerektirir | Doğrudan aktarılabilir |
| Yaşam süresi | Toplantı sonunda değerini kaybedebilir | Sürekli güncellenen bir yönetim aracı |
Bu ayrımı gözden kaçırmanın en yaygın sonucu, işletmelerin “biz zaten süreçlerimizi haritaladık” diyerek ERP projesine güvenle girmesi, ama proje ortasında haritanın hiçbir karar kuralı içermediğini fark etmesidir. Bu fark edildiğinde proje zaten ilerlemiş, takvim baskısı oluşmuş olur; ve karar kuralları, en kötü zamanda, aceleyle ve baskı altında netleştirilmeye çalışılır.
| EN SIK YAPILAN HATA İşletmeler bir akış şemasını “süreç tanımlandı” anlamına geldiğini düşünür. Oysa bir akış şeması, sadece sürecin iskeletidir. Kaslar (yani karar kuralları, sahiplik ve istisna yönetimi) eklenmeden bu iskelet ayakta duramaz. |
| YÖNETİCİYE ÖZEL Elinizde bir süreç haritası varsa, onu çöpe atmayın; ama yeterli sanmayın. Her kutu için şu soruyu sorun: “Bu adımı kim yapıyor, hangi kritere göre karar veriyor, ve karar kriteri belirsizse ne oluyor?” Bu üç soruyu her kutuda cevaplayabiliyorsanız, elinizde gerçek bir süreç yönetimi çerçevesi var demektir. |
Bu netlik sağlandığında, bir işletme artık soyut bir “süreç çalışması yapalım” fikrinden, somut ve ERP’ye doğrudan aktarılabilir bir çıktıya geçebilir. Aşağıdaki bölümde, tam olarak bu somut çıktıların neler olması gerektiğini, ERP’ye girmeden önce masanızda bulunması gereken unsurları, gösteriyoruz.
Bölüm 6: ERP Öncesi Süreç Çalışmasının Somut Çıktıları
Süreç yönetiminin ne olduğunu anlamak bir şeydir; bunu somut bir çalışmaya dönüştürmek başka bir şeydir. Bu bölümün amacı, size bir hizmet paketi satmak değil, ERP’ye geçmeden önce masanızda bulunması gereken beş somut unsuru göstermektir. Bu unsurlar bir danışmanlık firması tarafından üretilebilir, ama işletmenin kendi ekibi tarafından da, doğru disiplinle, üretilebilir.
Birinci unsur, süreç envanteridir. İşletmenin hangi süreçlere sahip olduğunun tam bir listesi. Bu, şaşırtıcı derecede çoğu işletmede eksiktir; üretim planlama, satınalma, kalite kontrol gibi büyük süreçler bilinir, ama “iade yönetimi” veya “numune onayı” gibi daha küçük ama kritik süreçler genellikle listelenmemiştir.
İkinci unsur, her sürecin karar noktalarıdır. Bir sürecin içinde, birden fazla seçeneğin mümkün olduğu her nokta bir karar noktasıdır. Bu noktaların her birinde “kim, hangi kritere göre karar veriyor” sorusunun cevabı yazılı olmalıdır.
Üçüncü unsur, veri sahipliğidir. Bir bilginin hangi sistemde, kim tarafından, ne zaman güncellendiği net olmalıdır. Aynı bilginin (örneğin bir müşteri kredi limitinin) hem satış ekibinin Excel’inde hem de finansın ayrı bir tablosunda farklı değerlerle yaşaması, ERP projelerinde en sık karşılaşılan veri tutarsızlığı kaynağıdır.
Dördüncü unsur, istisna senaryolarıdır. Her süreç, standart akışın dışına çıkan durumlarla karşılaşır: iptal edilen bir sipariş, reddedilen bir parti, gecikmiş bir tedarik. Bu istisnaların nasıl yönetileceği, standart akış kadar net tanımlanmalıdır; çünkü ERP projelerinde asıl kırılma noktaları neredeyse her zaman istisna anlarında yaşanır.
Beşinci unsur, değer/israf ayrımıdır. Mevcut sürecin her adımının gerçekten bir değer üretip üretmediğinin sorgulanmasıdır. Bu adım, bir sürecin olduğu gibi ERP’ye aktarılmasını değil, aktarılmadan önce eleneceğini garanti eder.
Bu son unsuru somutlaştıran bir örnek, bir dayanıklı tüketim malları üreticisinin deposunda yaşanmıştı. Mal kabul sonrası ürünler önce “geçici bekleme alanına” konuluyor, uygun bir zaman diliminde ikinci bir personel tarafından “kalıcı rafa” taşınıyordu. WMS projesine başlamadan önce yürütülen süreç çalışmasında bu ikinci taşıma adımı sorgulandığında, kimse bu adımın neden var olduğuna dair net bir açıklama getiremedi; yıllar önce depo düzeninin farklı olduğu bir dönemden kalma bir alışkanlıktı. Bugünkü depo yerleşiminde, ürünler doğrudan kalıcı rafa yerleştirilebilirdi. Bu adım hiçbir değer üretmiyordu; sadece zaman, iş gücü ve ek bir hata riski (taşıma sırasında yanlış rafa yerleştirme) doğuruyordu. Süreç çalışması, bu adımı ERP’ye aktarmadan önce tamamen ortadan kaldırma fırsatı sağladı.
| SAHADAN GÖZLEM İşletmeler genellikle mevcut sürecin her adımını “elbette gerekli” varsayımıyla ERP’ye taşımak ister. Oysa süreç çalışmasının en değerli anı, tam olarak “bu adım neden var?” sorusunun sorulduğu ve kimsenin tatmin edici bir cevap veremediği andır. |
| Unsur | Sorulması Gereken Soru | Yoksa Ortaya Çıkacak Risk |
| Süreç envanteri | Hangi süreçlere gerçekten sahibiz? | Kritik bir süreç ERP kapsamı dışında unutulur |
| Karar noktaları | Bu noktada kim, neye göre karar veriyor? | Sistem, kişiye bağlı kararı otomatikleştiremez |
| Veri sahipliği | Bu bilgiyi kim, hangi sistemde günceller? | Çelişkili veri kaynakları güven kaybına yol açar |
| İstisna senaryoları | Standart dışı durumda ne oluyor? | Go-live sonrası en sık yaşanan kriz noktası |
| Değer/israf ayrımı | Bu adım gerçekten değer üretiyor mu? | Gereksiz adımlar dijitalleşerek kalıcı hale gelir |
| EN SIK YAPILAN HATA İşletmeler süreç çalışmasını “mevcut durumu belgelemek” olarak anlar ve mevcut sürecin her adımını olduğu gibi ERP’ye aktarmaya çalışır. Oysa amacın bir kısmı, mevcut adımların bir kısmını tamamen ortadan kaldırmaktır; ERP, iyileştirilmemiş bir süreci hızlandırmak için değil, iyileştirilmiş bir süreci ölçeklemek için kullanılmalıdır. |
| YÖNETİCİYE ÖZEL Bu beş unsuru bir kontrol listesi olarak değil, bir öz değerlendirme çerçevesi olarak kullanın. Her kritik süreciniz için bu beş soruyu yanıtlayamıyorsanız, ERP tedarikçisi seçimini ertelemek, projeyi geciktirmek değil, projenin gerçek maliyetini düşürmektir. |
Bu beş unsur elinizde olduğunda, artık teoride kalan bir farkındalıktan, uygulamada somut bir hazırlığa geçmiş olursunuz. Ancak bu hazırlığı yapmayan işletmelerin düştüğü hatalar oldukça tekrar edendir; ve bu hataları tanımak, kendi işletmenizde aynı tuzağa düşmemek için en pratik yoldur. Aşağıdaki bölümde, Türkiye’deki üretim işletmelerinde en sık karşılaşılan üç ERP yanılgısını inceliyoruz.
Bölüm 7: Sık Görülen ERP Hataları ve Yanlış Varsayımlar
Danışmanlık pratiğinde karşılaşılan ERP hataları, teknik detaylarda değil, üç tekrarlayan zihniyet kalıbında yoğunlaşır. Bu üç yanılgı, sektör, büyüklük veya bölge fark etmeksizin şaşırtıcı bir tutarlılıkla tekrarlanır.
Birinci Yanılgı: “Danışman Zaten Süreçlerimizi Tasarlar”
Bu, en maliyetli yanılgıdır çünkü sorumluluk devrini gizler. Bir işletme ERP danışmanlık sözleşmesi imzaladığında, çoğu zaman süreç tasarımının da bu sözleşmenin bir parçası olduğunu varsayar. Oysa bir danışman, işletmenin kendi önceliklerini, kendi risk toleransını, kendi örtük bilgisini bilemez. Danışmanın yapabileceği, işletme kendi kararını verdikten sonra bu kararı sisteme doğru biçimde kodlamaktır. Süreç tasarımını danışmana bırakan bir işletme, genellikle danışmanın “en yaygın uygulama” olarak sunduğu genel bir şablonu devralır; bu şablon, işletmenin kendi özgün rekabet mantığını yansıtmaz.
İkinci Yanılgı: “Biz Zaten Excel’de Her Şeyi Biliyoruz”
Bu yanılgı, bir gıda üretim tesisinde net biçimde ortaya çıkmıştı. İşletme, sevkiyat onay sürecinin Excel tablolarında yıllardır sorunsuz işlediğini düşünüyordu ve ERP projesine bu güvenle girdi. Proje ortasında, sevkiyat onayının aslında üç farklı vardiya sorumlusu tarafından üç farklı mantıkla yürütüldüğü ortaya çıktı: biri parti numarasına göre sıralıyor, biri üretim tarihine göre önceliklendiriyor, biri de müşteri önem derecesine göre karar veriyordu. Excel’in esnekliği, bu üç farklı mantığın yıllarca fark edilmeden bir arada var olmasına izin vermişti; çünkü her vardiya kendi tablosunu kendi mantığıyla dolduruyordu. ERP bu esnekliği kaldırınca, üç mantık aynı anda “doğru” olarak sisteme girilemedi ve proje iki ay gecikti.
Üçüncü Yanılgı: “Modülü Aktif Etmek, Süreci Tanımlamak Demektir”
Bu yanılgı, bir modülün kurulum ekranında birkaç alanın doldurulmasını “süreç tanımlandı” olarak yorumlar. Gerçekte bir modülün aktif olması, sadece teknik bir yapılandırmadır; modülün içindeki iş akışının işletmenin gerçek karar mantığıyla örtüşüp örtüşmediği ayrı bir sorudur. Birçok işletme, modül ekranlarının dolu görünmesini “süreç oturdu” sanısıyla yorumlar, oysa ekranın arkasında hâlâ kişiye bağlı, tutarsız bir karar mekanizması işlemeye devam edebilir.
| DANIŞMAN NOTU Bu üç yanılgının ortak paydası, sorumluluğun bir yere devredilebileceği inancıdır; ya danışmana, ya geçmişteki sisteme (Excel), ya da yazılımın kendisine. Oysa süreç sahipliği, hiçbir aracıya devredilemeyen tek sorumluluktur. |
| Yanılgı | Gerçek Durum | Sonuç |
| “Danışman süreçlerimizi tasarlar” | Danışman süreci koda döker, tasarlamaz | Genel şablon, işletmenin özgün mantığını yansıtmaz |
| “Excel’de zaten her şey net” | Excel’in esnekliği, çelişkili mantıkların bir arada saklanmasına izin verir | ERP devreye girince çelişkiler aynı anda ortaya çıkar |
| “Modül aktif = süreç tanımlı” | Modül teknik yapılandırmadır, karar mantığı ayrı bir konudur | Ekran dolu görünür, karar hâlâ kişiye bağlıdır |
| EN SIK YAPILAN HATA Bu üç yanılgının hepsi, aynı kökten beslenir: süreç sahipliğinin bir yerlerde zaten var olduğu varsayımı. Oysa süreç sahipliği, aktif olarak inşa edilmesi gereken bir şeydir; kendiliğinden var olmaz. |
| YÖNETİCİYE ÖZEL Proje ekibinize şu üç soruyu düzenli olarak sorun: “Bu kararı biz mi verdik, yoksa danışman mı önerdi?” “Excel’de gördüğümüz düzen, gerçekten tek bir mantığa mı dayanıyor, yoksa farklı kişilerin farklı yaklaşımlarının tesadüfi bir arada duruşu mu?” “Bu modül ekranı dolu, ama karar hâlâ birinin telefon açmasını mı gerektiriyor?” Bu üç sorunun cevapları, projenizin gerçek olgunluk seviyesini gösterir. |
Bu üç yanılgı, farklı görünse de aynı temel gerçeği gizler: ERP’nin başarısı, teknik bir yeterlilik meselesi değil, bir sahiplenme meselesidir. Bu makale boyunca ele aldığımız her gözlem (yanlış sorudan başlamak, ERP’nin çarpan etkisini yanlış anlamak, örtük bilgiyi görmezden gelmek, belirsizliğin maliyetini hafife almak, haritalamayı yönetimle karıştırmak ve sorumluluğu bir yerlere devretmeye çalışmak) hepsi tek bir noktada birleşir. Bu birleşim noktasını, makalenin son bölümünde netleştiriyoruz.
Sonuç: ERP Bir Yazılım Kararı Değil, Bir Organizasyon Kararıdır
Bu makale boyunca ele aldığımız her gözlem, tek bir gerçeğe farklı açılardan işaret etti: ERP projelerinin başarısı, seçilen yazılımın kalitesinde değil, o yazılıma girilecek olan mantığın netliğinde belirlenir. Bir işletme kendi kararlarını (kim, neye göre, hangi durumda verir) net biçimde tanımlayabiliyorsa, ERP bu netliği hızlandırır ve büyütür. Aynı netlik yoksa, ERP bu boşluğu doldurmaz; boşluğu olduğu gibi dijitalleştirir ve kalıcı hale getirir.
Bu nedenle, bir ERP projesinin gerçek başarı kriteri “sistem canlıya alındı mı” sorusu değildir. Gerçek kriter şudur: işletme, kendi süreçlerini bir sisteme, ve daha önemlisi kendi çalışanlarına, tutarlı biçimde anlatabilecek kadar tanıyor mu?
Bu soru, bir yazılım seçim komitesinin değil, yönetim kurulunun sorumluluğundadır. Çünkü bu soru, teknik bir konfigürasyon meselesi değil, bir organizasyonun kendi kararlarına ne kadar sahip çıktığının göstergesidir. Süreç netliği olmadan başlayan bir ERP projesi, teknik olarak ne kadar kusursuz tamamlanırsa tamamlansın, organizasyonel olarak eksik kalır; çünkü sistemin arkasında hâlâ kişiye bağlı, tutarsız ve görünmez bir karar mekanizması işlemeye devam eder.
İyi haber şudur: bu netliği inşa etmek, büyük bütçeler veya uzun aylar gerektiren bir egzersiz değildir. Gerektirdiği şey, doğru soruları doğru sırayla sormaktır: hangi ERP yerine hangi süreç; hangi yazılım özelliği yerine hangi karar kuralı; hangi modül yerine hangi sahiplik. Bu sorular sorulduğunda, bir işletme ERP’ye sadece bir yazılım yatırımı olarak değil, kendi organizasyonel netliğini sınayan ve güçlendiren bir süreç olarak yaklaşmış olur.
Süreç netliği, bir ERP projesinin maliyeti değildir. Onun sigortasıdır. Baştan yatırılmayan bu bedel, projenin ortasında çok daha yüksek bir faizle geri döner: gecikme, özelleştirme ve kullanıcı direnci olarak.
Bu makale, “ERP’den Önce Süreç Yönetimi” serisinin ilk adımıydı. Buraya kadar, neden önce süreçlere bakmanız gerektiğini gördük. Serinin bir sonraki makalesinde, bu bakışı somut bir metodolojiye dönüştüreceğiz: bir sürecin nasıl doğru biçimde haritalandığını, karar noktalarının nasıl tespit edildiğini ve bir işletmenin kendi süreç olgunluğunu nasıl değerlendirebileceğini, adım adım ele alacağız.