ERP neden kalıba girmez

Tanıdık geldi mi?

Önce kelimelere bakalım: ERP ne demek

ERP, Enterprise Resource Planning ifadesinin kısaltmasıdır. Türkçesi Kurumsal Kaynak Planlaması. Üç kelimenin üçü de bilerek seçilmiş ve üçü de bugün çoğu firmada eksik karşılık buluyor.

Ve buradaki asıl sorun şu: piyasadaki ERP'lerin çoğu ilk iki kelimede iyidir, üçüncüde zayıftır. Kaydı tutarlar, kurumu bir araya getirmeye çalışırlar; ama planlamayı çoğunlukla insana bırakırlar. Planlama yine bir kişinin Excel'inde, tecrübesinde ve kafasında kalır.

ERP nereden çıktı

ERP gökten inmedi; üretim yapan firmaların çok somut bir derdinden doğdu. Bugünkü kısıtlarının çoğu da o geçmişten geliyor.

Ama bir şey oldu. Sistem büyüdükçe, her firmaya ayrı yazılmak yerine tek bir ürünün binlerce firmaya satılması gerekti; ekonomik olarak başka türlü mümkün değildi. Kalıp tam burada doğdu — teknik bir tercih olarak değil, ticari bir zorunluluk olarak.

Kalıp neden kaçınılmaz — ve neden sorun

Bu bir suçlama değil. ERP üreticileri kötü niyetli oldukları için kalıp dayatmıyor; başka türlü var olamayacakları için dayatıyor. Bir üretici tek bir yazılım yazar ve binlerce firmaya satar. Her firmaya ayrı yazsa fiyat yüz katına çıkar. Dolayısıyla ürün, binlerce firmanın ortalamasına göre tasarlanır.

Ama sahada "ortalama firma" diye bir şey yoktur. Her firmanın kendine özgü bir çalışma biçimi, kendine özgü istisnaları vardır. Ürün ortalamaya göre yazıldığı için, işinizin ortalamadan ayrıldığı her yerde sürtünme çıkar.

Sorun kalıbın var olması değil. Kalıbın tek seçenek olarak sunulmasıdır.

"En iyi uygulama" argümanının ayrılmayan iki yarısı

ERP satışlarında en sık duyulan cümle şudur: "Bu sistem dünyadaki en iyi uygulamaları içeriyor, siz de süreçlerinizi ona uydurun." Bu cümlenin bir kısmı doğru, bir kısmı tehlikeli — ve ikisi hiç ayrılmıyor.

Tuzak şurada: "en iyi uygulama" söylemi ikisini ayırmaz, hepsini aynı torbaya koyar. Firma da ya uyar ve farkını kaybeder, ya uymaz ve sistemin dışına taşar.

Firmanın farkı, kalıbın sildiği şeydir

Her firmanın ayakta kalmasını sağlayan birkaç şey vardır. Çoğu zaman yazılı değildir, bir yerde kayıtlı da değildir — ama işin gerçek değeri oradadır:

• Acil iş geldiğinde hangi işi bölüp hangi makineye aldığınız.
• Hangi üründe ne kadar fire vereceğinizi baştan bilip fiyatı ona göre vermeniz.
• Hangi tedarikçinin sözünü tuttuğunu bilip planı ona göre kurmanız.
• Hangi müşteriye vade verilebileceğini bilmeniz.

Bunları kimse size öğretmedi; yıllar içinde öğrendiniz. Standart bir ERP hiçbirini bilmez. Bilmediği için de ya yok sayar ya da "önce şunu tanımlayın" der. Tanımlama işi ağırlaştıkça kullanıcı vazgeçer ve eski yöntemine döner.

Kalıp firmayı ortalamaya çeker. Ama hiçbir firma ortalama olduğu için kazanmaz.

Peki uyarlama? Onun da üç bedeli var

Sonuç genellikle şudur: firma bir süre sonra "bunu sisteme yaptırmayalım, dışarıda halledelim" demeye başlar. Masumca görünür ama sistemin dışına atılan ilk adımdır.

Gölge sistemler: iş durmaz, başka yere kayar

Gölge sistemin üç zararı vardır. Rakamlar ayrışır — bir süre sonra kimse sistemin rakamına güvenmez. Bilgi kişiye bağlanır — o kişi izne çıkınca iş aksar. Karar gecikir — rapor için gün beklenir, gün beklendiğinde karar çoktan geç kalmıştır.

Gölge sistem, çalışanların tembelliği değildir. Sistemin karşılamadığı bir ihtiyacın, insanlar tarafından çaresizce kapatılmasıdır.

Planlama neden sabit bir kalıba girmez

Kayıt tutmak kalıba girer; fatura hep faturadır. Ama planlama karar vermektir ve karar her seferinde farklı şartlar altında verilir. Dört sebebi var:

• Kısıtlar firmaya özgüdür. Birinde darboğaz makine, diğerinde kalifiye operatör, bir başkasında kalıp sayısıdır. Standart bir planlama motoru hepsini aynı ağırlıkta görür.
• Öncelik kuralı yazılı değildir. "Hangi işi öne alalım" sorusunun cevabı sözleşmede yazmaz; ilişkinin geçmişi, cezai şart ve sevkiyat günü belirler.
• Talep belirsizdir. Sipariş kesin görünür ama değişir; miktar artar, tarih öne çekilir, revizyon gelir.
• Plan, planlandığı anda eskimeye başlar. Asıl soru "iyi plan nasıl yapılır" değil, "plan bozulduğunda ne yapılır"dır.

Klasik ERP bu dördünü de "parametre" olarak çözmeye çalışır; sizden baştan tanımlamanızı ister. Ama bunlar baştan tanımlanacak şeyler değil, sürekli değişen şeylerdir. Planlama modülleri bu yüzden kurulur, bir süre kullanılır ve sonra sessizce terk edilir.

İstisnalar kuralı yönetir

Yazılım kuralla çalışır, saha ise istisnayla. Sahadan tanıdık cümleler: "Bu müşteride kalite kontrolü atlıyoruz." "Reçetede böyle yazıyor ama biz biraz fazla veriyoruz." "Bu iş acil, kâğıtla yürüsün sonra gireriz." Her biri bir istisnadır ve her biri, kayda geçmediği sürece sistemin doğruluğunu bozar.

İki kötü çözüm vardır. İstisnayı yasaklamak — saha durmaz, istisna görünmeden yapılmaya devam eder; şimdi hem vardır hem görünmezdir. Her istisnaya kod yazmak — sistem şişer, güncellenemez hâle gelir.

Doğru olan üçüncü yol: istisnayı yasaklamak da her birine kod yazmak da değil — istisnayı sisteme anlatabilmek.

Bir de Türkiye şartları var

Yurt dışında yazılmış bir ERP, yazıldığı ülkenin şartlarını varsayar. Burada üretim yapan bir firmanın günlük gerçekliği ise farklıdır.

• Kur. Hammadde dövizle alınır, satış kısmen TL'dir. Maliyet hangi kurdan hesaplanacak — sipariş günü mü, üretim günü mü, sevk günü mü? Yanlış kur, zararlı bir işi kârlı gösterir.
• Vade. Satış vadeli, alım peşine yakın. Kâğıt üstünde kârlı bir ay, nakit tarafında sıkışık olabilir.
• Tedarik belirsizliği. Planlama, tedarikçinin söylediği tarihe göre değil, geçmişte tuttuğu tarihe göre yapılmalıdır.
• Mevzuat hızı. e-Belge düzenlemeleri sık değişir; sistemin hızla uyması gerekir, aylarca sürüm beklenecek bir konu değildir.

Yapay zekâ burada neyi değiştiriyor

Abartılı bir şey söylemeyelim: yapay zekâ ERP'yi ortadan kaldırmıyor, muhasebeyi de yapmıyor. Değiştirdiği şey daha dar ama daha önemli — sistemle konuşma biçimi.

Eskiden bir ihtiyacınız olduğunda yazılımcıya anlatırdınız. O anlar, analiz yazar, kodlar, test eder, devreye alır; aradan haftalar geçer. İhtiyaç küçükse çoğu zaman hiç yapılmaz — "buna değmez" denir ve Excel'e dönülür. Şimdi ise ihtiyacı tarif edersiniz; sistem verinizi, terimlerinizi ve kurallarınızı zaten bildiği için işi yapar.

Asıl kazanç, yapılabilen işin büyüklüğü değil — yapılmaya değer görülen işin eşiğinin düşmesidir.

Eskiden "boş ver, Excel'de yaparım" denen yüzlerce küçük iş artık sistemin içinde yapılabiliyor. Gölge sistem de tam bu yüzden küçülüyor.

Kalıp yerine ne var: üç katmanlı bakış

Peki kalıbın yerine ne konacak? Sistemi üç katman olarak yazmak ve esnekliği doğru katmana koymak. Böylece standart olması gereken yer standart kalır, firmayı rakiplerinden ayıran yer de gerçekten firmaya özgü olur.

Klasik yaklaşımın hatası üç katmanı da aynı sertlikte kurmaktır. Alt katman sert olmalıdır — orası zaten öyle. Ama orta ve üst katman sert olduğunda firma sisteme uymak zorunda kalır. Çekirdeğe dokunulmadığı için güncelleme kilidi de oluşmaz: ERP'niz güncellenmeye devam eder.

Ve en önemlisi: yazılımı işi bilen yazdırır

Bugüne kadar yazılım geliştirmenin en pahalı ve en yavaş yeri, işi bilen kişi ile yazılımı yazan kişi arasındaki çeviri katmanıydı.

Maliyet muhasebesini en iyi bilen kişi muhasebecinizdir; üretimin gerçekte nasıl döndüğünü en iyi bilen üretim şefinizdir. Ama hiçbiri yazılım yazamaz. Bu yüzden yazılımcıya anlatırlar, yazılımcı da işi bilmediği için anladığı kadarıyla koda çevirir. Kayıp burada yaşanır: "İstediğim bu değildi." Yeniden anlatılır, yeniden yazılır; üçüncü denemede genelde vazgeçilir ve o iş Excel'e döner.

Yazılım artık yazılımcının anladığı kadarını değil, işi bilenin tarif ettiği kadarını yapıyor.

Bu yalnız bir hız kazancı değil. Daha derin bir şey oluyor: maliyet kurgusunu artık maliyeti bilen kuruyor, üretim önceliğini üretimi bilen tarif ediyor, kontrol listelerini kaliteyi bilen yazıyor. Kimse kimseye "yazılım buna izin vermiyor" demek zorunda kalmıyor.

Kontrol kimde kalmalı

Yazılım projelerinde en sık yaşanan ve en az konuşulan şey bağımlılıktır. Kontrol aslında üç ayrı yerdedir:

• Verinin kontrolü. Sistem firmanın kendi sunucusunda çalışmalıdır. Muhasebe, ciro ve müşteri listesi firmada kalır.
• Geliştirmenin kontrolü. Temel kurulduktan sonra yeni bir rapor ya da kural için kuran firmaya dönmek gerekmemelidir.
• Bilginin kontrolü. Sisteme öğretilen her kural kurumun malı olur; personel değişse de o bilgi yerinde kalır.

Bir iş ancak müşterisi memnun olduğu için sürüyorsa sağlıklıdır; mecbur olduğu için sürüyorsa değildir.

Somut bir örnek: maliyeti neyin bozduğunu bulmak

Şikâyet şuydu: "Bir ürün grubunda kâr marjımız düştü ama sebebini bulamıyoruz. Hammadde fiyatı çok değişmedi, satış fiyatını da düşürmedik."

Çıkarılacak ders: sorun yazılımda değil, modeldeydi. Maliyet modeli sahadaki gerçeği yansıtmıyordu. Bu tür sorunlar ancak üretimin ve muhasebenin dilini aynı anda konuşan biri tarafından görülebilir.

Nereden başlanır

Büyük ve belirsiz bir projeye bağlanmadan önce yapılabilecek en sağlıklı şey, mevcut durumu dışarıdan bir gözle çıkarmaktır: hangi işler sistemin dışında yürüyor, hangi rakama güvenilmiyor, hangi iş tek bir kişiye bağlı kalmış.

Biz bu görüşmede bir şey satmıyoruz. Yapılacak bir iş varsa ne kadar süreceğini ve neye mal olacağını rakamla söyleriz; yapılacak bir iş yoksa ya da mevcut sisteminizde düzeltmek yeterliyse onu da açıkça söyleriz.