Servis Yoğun Sektörlerde ERP Projesi Nasıl Tasarlanır?

ERP projesi başlamadan önce şu soruyu sormak gerekiyor: Bu sektörde standart bir süreç var mı? Üretim tesisinde bu soru kolay yanıtlanır; montaj hattı, stok hareketi, satın alma döngüsü — hepsi tanımlı. Ama otelde, hastanede, danışmanlık şirketinde aynı soruyu sorduğunuzda oda servisinden ön büroya, talepten teslimata kadar her adımın kişiye, günübirlik kapasite durumuna ve mevsime göre değiştiğini görürsünüz. İşte servis yoğun sektörlerde ERP projelerinin büyük bölümü bu noktada kırılıyor: süreç önce kağıda dökülmeden yazılım devreye alınıyor ve sistem, kaosun çözümü değil elektronik hafızası haline geliyor.Bu tezi biraz daha açmak gerekiyor, çünkü mesele yalnızca proje yönetimi metodolojisi değil. Servis işletmelerinde ‘süreç’ kavramı üretimden farklı bir anlam taşıyor. Bir tekstil fabrikasında iplikten kumaşa giden yol tekrarlanabilir, ölçülebilir ve optimize edilebilir. Antalya’daki büyük bir tatil köyünde ise günlük 284 çalışanla yönetilen operasyon, sabahki doluluk oranından akşamki özel etkinlik talebine kadar sürekli değişen bir denklem. Bu denklemin ERP ile tanışması ancak iki koşulda işe yarıyor: ya yazılım devreye girmeden önce süreç iskeleti netleştirilmiş, ya da proje ekibinde servis operasyonunu içeriden bilen biri var. İkisi de yoksa proje genellikle muhasebe modülünde donup kalıyor.Pratikte en sık karşılaştığım durum şu: Genel müdür veya patron, bir fuarda ya da sektör toplantısında bir ERP demosuna katılmış, ‘tüm şirketi tek ekrandan görme’ vaadine inandırılmış ve projeyi başlatmış. İhtiyaç analizi aşaması ya tamamen atlanmış ya da yazılım satıcısının standart anket formuyla geçiştirilmiş. Bu form genellikle üretim ve ticaret sektörü için hazırlanmış sorulardan oluşuyor; ‘mamul türü nedir, reçete var mı, vardiyalı üretim mi?’ gibi sorular tatil köyü operasyon müdürüne yanlış adres. Anket doldurulmuş, gereksinim belgesi yazılmış, ama tatil köyüne özgü olan hiçbir şey — misafir talebinin anlık takibi, bakım iş emirleri, restoranlar arası malzeme transferi — o belgeye girmemiş.Peki doğru bir ihtiyaç analizi nasıl kurgulanmalı? Bu sorunun yanıtı üç aşamadan geçiyor. Birinci aşama, sürecin kağıda dökülmesidir. Sadece ‘muhasebe nasıl işliyor’ değil, ‘misafir konaklamaya başladığında hangi departman ne bilgiye ihtiyaç duyuyor ve bu bilgiyi şu an nereden alıyor?’ sorusu sorulmalı. Ön büro bir check-in yaptığında bu bilgi restauranta, temizliğe ve teknik servise nasıl ulaşıyor? Faks mı, telefon mu, kağıt form mu? Bu akışı görmeden ERP modüllerine karar vermek, duvarları çizmeden elektrik tesisatını planlamaya benziyor. İkinci aşama, veri sahipliğinin netleştirilmesidir. Servis işletmelerinde aynı bilgi birden fazla departmanda farklı biçimlerde tutuluyor. Misafir tercihleri ön büroda bir defterde, restoran müdüründe ayrı bir listede, satış departmanında ise başka bir formda. ERP kurulmadan önce hangi bilginin nerede yaşayacağı ve kimin güncelleyeceği belirlenmeli. Bu kararı yazılım vermez; işletme vermek zorunda. Üçüncü aşama ise entegrasyon noktalarının önceden tespit edilmesidir. Mevcut muhasebe programı, personel bordro sistemi, rezervasyon yazılımı — bunlarla ERP nasıl konuşacak? 2008’de bu entegrasyonlar çoğunlukla dosya aktarımı ve ODBC bağlantısıyla çözülüyor. Her entegrasyon noktasında ‘kim ne zaman hangi dosyayı nereye aktarıyor?’ sorusunun cevabı proje başlamadan yazılmalı.Şimdi işin gerçekten zor kısmına geliyorum. Servis işletmelerinde kullanıcı direnci, üretim sektörüne kıyasla çok daha yüksek. Üretim hattındaki operatör yazılımı kullanmak zorunda; iş akışı bunu zorunlu kılıyor. Ama otel resepsiyonisti, garson, kat görevlisi — bunlar müşteriyle yüz yüze çalışıyor, ekrana bakmak onlar için zaman kaybı. Bu gerçeği görmezden gelen projeler, sistemin teknik olarak doğru çalıştığını ama hiç kimsenin kullanmadığını altı ay sonra fark ediyor. Dolayısıyla proje tasarımında kullanıcı arayüzü ve veri giriş süresine ayrı bir bölüm ayrılmalı. Bir kat görevlisinin temizlediği odayı sisteme işlemesi beş dakikadan fazla sürüyorsa o süreç tasarlanmamış, sadece transfer edilmiş demektir. İzmir’deki orta ölçekli bir şehir oteli projesinde bu sorunu şöyle çözdük: veri girişi gerektiren her adımı önce kağıt üzerinde modelledik, sonra prototip ekranları üzerinde operasyon personeli ile gerçek senaryo testleri yaptık. Yazılıma geçmeden önce dört farklı ekran tasarımını reddettik. Bu süreç proje takvimini üç hafta uzattı, ama canlıya geçişten sonra sistem kullanımı beklentinin çok üzerinde kaldı.Yönetim beklentileri konusunda da açık olmak gerekiyor. ERP projesi biten bir işletme genellikle şu beklentiyle karşınıza geliyor: ‘Artık her şeyi tek ekrandan göreceğiz.’ Bu beklenti doğru ama yanıltıcı. ‘Görmek’ ile ‘yönetmek’ arasındaki fark, ERP projelerinin en sık atlanan boyutudur. Sistem devreye girdiğinde veriler ekrana geliyor — ama bu verilere bakarak doğru kararı vermek ayrı bir yetkinlik gerektiriyor. Raporların okunması, saptanan sapmalara göre aksiyon alınması, departmanlar arası koordinasyonun sağlanması için sürecin insan tarafı da kurgulanmış olmalı. Yazılım bu kararları vermiyor; sadece veriyi topluyor ve düzenliyor. Genel müdür her sabah rezervasyon gelirini görüyorsa ama bu rakamı maliyet yapısıyla birlikte okuyamıyorsa ERP’nin değeri yarım kalıyor.Servis yoğun sektörlerde ERP projesinin başarısı tek bir soruya indirgenebilir: Yazılım devreye girmeden önce işletmenin kendi süreçlerini ne kadar iyi tanıdığı. Süreci tanıyan bir işletmede ERP bir hız kazandırıcıdır. Sürecini tanımamış bir işletmede ise sistem, mevcut belirsizliği daha pahalı bir biçimde yaşatmaktan öteye geçemiyor. Eğer proje henüz başlamadıysa ya da başlangıç aşamasındaysa şunu öneririm: ERP seçimi yapmadan önce en kritik beş operasyonel sürecin el yazısıyla kağıda dökülmesine iki hafta ayırın. Bu iki haftada ortaya çıkan çelişkiler ve belirsizlikler, ileride yazılım değişikliği olarak önünüze gelecek faturadan çok daha ucuza mal olacaktır.