ERP nedir: bir işin kaydı kaç programdan geçiyor?

ERP, bir işletmenin iş takibi, stok ve muhasebe gibi temel süreçlerini ayrı programlara dağıtmadan aynı kayıt üzerinde tutan yazılım sınıfının adı; açılımı kurumsal kaynak planlaması. Kararın yeri satıcının modül listesi değil, bir işin kaydının bugün dokunduğu program sayısı. AlgoCar’ı geliştirmeye başladığımız atölyede o sayım üçe çıkıyordu; bugün aynı iş tek kayıt üzerinde kapanıyor.

ERP’nin açılımı kurumsal kaynak planlaması

Kısaltma İngilizcedeki enterprise resource planning ibaresinden geliyor ve Türkçe karşılığı kurumsal kaynak planlaması olarak yerleşti. Harfler bir markayı değil bir yazılım sınıfını işaret ediyor. Bu kelimeyi çoğu işletme sahibi bir satıcının ağzından duyuyor; o yüzden kafada kısaltma ile ürün adı aynı şeye oturuyor. Ayrımı baştan koymak gerekiyor: ERP rafta duran tek bir program değil, belli bir işi yapan programların toplu adı. Sınıfa girmenin koşulu da ad değil davranış.

Sınıfın içine giren yazılımların kalem kalem sayılabilen bir ortak listesi var: iş takibi, stok, satın alma, satış ve muhasebe kaydı tipik başlıklar arasında. Liste tanımın parçası, bir vaat değil. Bir satıcının paketinde bu başlıkların hangisinin gerçekten bulunduğu ayrı bir soru ve o soru bu yazının konusu değil. Burada sorulan soru daha geride: bu başlıklar bir araya geldiğinde ne değişiyor.

Liste tek başına soyut kalıyor, çünkü başlıkların hepsi ayrı programlarda da var. Bir işletmede bugün stok tutan bir tablo, iş takibi yapan bir yazılım ve fatura kesen bir program olabilir; başlıklar eksiksiz, buna karşın ortada ERP yok. Farkı yapan şey başlıkların varlığı değil, aralarındaki bağ.

Sınıf adı olmasının pratik bir sonucu var. Bir ERP’yi değerlendirirken karşılaştırılan şey ürün özellikleri değil kurulum düzeni oluyor: aynı adı taşıyan yazılımlar işletmenin kaydını bambaşka yerlerde açabiliyor. Bu yüzden sonraki bölümler özellik listesini değil kaydın yolunu konu alıyor.

Kısaltmanın yazılım dışında başka karşılıkları da var; psikoloji literatüründe ve oyun dünyasında aynı harfler başka şeyler anlatıyor. Burada konu işletme yazılımı.

Bir ERP’de aynı bilgi neden tek kez giriliyor

Bir ERP’yi ayıran şey ekran sayısı değil, ekranların aynı kayda bakması. Stok ekranı ile fatura ekranı kullanıcıya ayrı görünür; ikisi de aynı hareketi okur. Bir hareket bir yere yazıldığı anda öteki ekranlar onu kendi açısından görmeye başlıyor. Depo tarafı aynı hareketi tüketim olarak, muhasebe tarafı bedel olarak okuyor, ama okudukları kayıt tek.

Bunun tersi de aynı derecede açık bir gözlem. Aynı hareketi ikinci bir programa elle taşımak gerekiyorsa ortada tek kayıt yok demektir. Elle taşıma, kaydın sahibinin birden fazla olduğunun en görünür belirtisi; çünkü taşınan şey bilginin kendisi değil, bilginin ikinci bir kopyası. Bu gözlem yazılımın adından bağımsız işliyor. Bir işletmede kurulu yazılımın adı ERP olabilir ve aynı hareket yine iki yere giriliyor olabilir.

Testin neden ekran sayısına bakmadığını burada görmek kolay. Ekran çoğaltmak bir dağınıklık üretmiyor; bir kaydı birden çok açıdan göstermek sistemin olağan işi. Dağınıklığı üreten şey kaydın çoğalması. Aynı hareket iki kayıt olarak yaşamaya başladığı anda hangisinin doğru olduğunu söyleyen bir kural gerekiyor ve o kural çoğunlukla yazılıma değil, birinin hafızasına yazılıyor.

Kaydın tek olmasının raporda da bir karşılığı var: ay sonu tablosu için ikinci bir yere veri girilmiyor; rapor, zaten yazılı olan kaydı farklı bir sırayla topluyor. Diş kliniği için kurduğumuz sistemde rapor tarafı böyle çalışıyor.

Buradan bir dil sorunu da çıkıyor. İşletme ihtiyacını anlatırken çoğunlukla modül adı sayıyor: fatura tarafı, raporlama tarafı, stok tarafı. Modül adı kaydın nerede açıldığını söylemiyor, yalnız hangi ekranın istendiğini söylüyor. İhtiyacı modül yerine kayıt birimiyle anlatmanın listeyi nasıl kısalttığını ayrıca yazdık. Bu yazıda modül dili yalnız tanıma testinin karşı kutbu olarak duruyor.

Karşı durum da yazılsın. Modül satın alınıp aynı hareket iki ekrana ayrı ayrı girilmeye devam ediyorsa ad ERP olsa da kayıt yine iki yerde duruyor. O durumda alınan şey bir ERP değil, ikinci bir program.

Soru modül sayısı değil, bir işin kaydının yolu

Teşhisi tek cümlede bırakalım. AlgoCar servis yönetim yazılımını geliştirmeye başladığımız atölyede bir onarımın kaydı üç yazılıma bölünüyordu: emri biri tutuyordu, parça stoğunu ikincisi, faturayı üçüncüsü. Bu yazının yükü teşhiste değil, ondan çıkan sayımda; o sayım işletmenin kendi günüyle yapılıyor.

Sayımın kuralı tek bir soruyla işliyor. Bir işi baştan sona izleyin ve kaydının kaç ayrı programa dokunduğunu sayın. Soruya cevabı modül adları vermiyor; işletmenin kendi günü veriyor. Sayım, satıcının listesinden bağımsız olduğu için görüşmeye gitmeden önce yapılabiliyor ve sonucu hiçbir broşürde yazmıyor.

Modül listesiyle sayım arasındaki fark, kimin neyi bildiği. Modül listesi satıcının elindeki ürünü tarif ediyor; sayım işletmenin kendi düzenini tarif ediyor. İkisi aynı masada konuşulduğunda liste her zaman kazanıyor, çünkü yazılı ve kalemli. Sayımı yazılı hâle getirmek bu dengeyi değiştiriyor: bir işin kaydının açıldığı, değiştirildiği ve kapandığı yerleri sırayla yazdığınızda elinizde modül adları değil program adları oluyor.

Dağınık sayımın bedeli kaydın kendisinde görünmüyor. Ayrı yazılımların her biri kendi işini düzgün yapıyor. Bedel, iki kaydı sonradan birleştirme işinde çıkıyor: bir işin bedeli ile kazancı ay sonunda elle karşılaştırılıyor ve karşılaştırmayı yapan kişi hangi parçanın hangi işe gittiğini hatırlamak zorunda kalıyor. Kayıtlar arasında referans olmadığı için birleştirmeyi yazılım devralamıyor; iş insana kalıyor.

Sayım bire indiğinde ortaya çıkan şey de somut. AlgoCar’da bugün emir, o emre yazılan parça ve fatura tek kayıt üzerinde duruyor; işletme tarafı ile muhasebe tarafı aynı sisteme bağlı. Ürün bizim ve geliştirmesi sürüyor. Bu düzende hangi kaydın kaynak, hangisinin ondan üreyen olduğu veri modeli kurulurken karara bağlandı; kararın zamanını mimari kararların ne zaman verildiği üzerine yazdığımız yazıda ayrıca açtık.

Sayım bir ise ERP sorusu o işletmenin sorusu değil. Bir işin kaydı bugün tek yerde açılıp tek yerde kapanıyorsa yeni bir sistemle giderilecek bir dağınıklık yok; o işletmenin sorusu başka bir yerde duruyor. Testin değeri de burada: cevabı her zaman yeni bir yazılım olmuyor.

Zincirin ilk halkası her işletmede başka bir kayıt

Zincirin nereden başladığı işin kendisine bağlı. ERP tartışması çoğunlukla bu halkayı atlayıp modüle geçiyor; oysa birim adlandırılmadan zincir kurulmuyor. Atölyede birim iş emri: aracın rampaya çıkmasıyla açılan emir, işin kendisinin kaydı. Parça da fatura da o kayda bağlanıyor.

Birimi adlandırmanın pratik sonucu şu: zincirin geri kalanı o birime bağlanıyor. Atölyede parçanın tüketimi emre yazılıyor, fatura da aynı emirden çıkıyor. Birim değişse bağlanma noktası da değişiyor; yani birim bir isimlendirme tercihi değil, kayıt yapısının merkezi.

Üreticinin satış tarafında halka başka bir yerden başlıyor. Resterm ısıtıcı seçim yazılımında kullanıcı bir katalog kodu girmiyor; işin ısıtma ihtiyacını giriyor. Zincirin ilk halkası o girdi oluyor. Birim bir ürün değil bir ihtiyaç olduğu için zincir de ürün listesinden değil işin kendisinden başlıyor.

Klinikte birim tedavi planı. Diş kliniği sisteminde plan, tedavinin diş diş neye bölündüğünü taşıyor ve randevuya bağlı olmayan, kendi başına var olan bir kayıt oluyor. Randevu bir olay, plan ise işin kendisi. ERP’nin birimi her zaman yapılacak iş oluyor, o işin takvimdeki yeri değil.

Bu birimler yan yana konduğunda ortak bir şey görünüyor. Hiçbiri bir ekran adı değil; hepsi işletmenin gerçekten yaptığı işin adı. İş emri bir onarım, girilen ihtiyaç bir ısıtma işi, tedavi planı bir tedavi. ERP sorusu bu yüzden hangi modülün alınacağı sorusundan önce geliyor: işin adı konulmadan hangi modülün hangi kaydı tutacağı da belirlenemiyor.

Birim yanlış seçilirse zincir hiç kurulmuyor. Aynı klinikte önceki düzen bir takvim yazılımına dayanıyordu: randevunun saatini biliyor, tedavinin hangi adımda olduğunu bilmiyordu. Eksik olan bir modül değildi, birimi taşıyan kaydın kendisiydi. O kayıt açılmadan ne rapor çıkıyor ne fatura; çıkanlar da birbirini doğrulamıyor.

Karşı durum şurada. Birim her işletmede kendiliğinden belli olmuyor. Bir kurumda aynı işi herkes kendi yöntemiyle yürütüyorsa yazılıma gömülecek tek bir zincir de yok; sıradaki iş yazılım almak değil, yöntemi sabitlemek. Yazılım var olan bir standardı çoğaltıyor; kendisi standart üretmiyor.

Dört işletmede aynı dağınıklığın dört ayrı yüzü

Dağınıklık sektöre özgü bir arıza değil. Aynı desen oto serviste, ısıtıcı üretiminde, diş kliniğinde ve saha serviste ayrı birimlerle tekrar ediyor. Soru bir ölçek sorusu da değil; tablodaki klinik de aynı sayımı veriyordu. Tablo olguyu taşıyor: her satırda zincirin ilk halkası, dağınık hâlde kaydın durduğu yerler ve tek sistemde neye bağlandığı yan yana duruyor.

Deseni sabit tutan şey program sayısı değil, kayıtlar arasında referans olmaması. Her kayıt ötekinin varlığından habersiz durduğu için birleştirme işi insana kalıyor ve o iş hiçbir yerde görev olarak görünmüyor. Satırların ikinci sütunu bu yüzden önemli: orada yazan şey dosya sayısı değil, bağsız kayıt sayısı.

İki satırın arkasında ayrıntılı bir anlatı duruyor. Resterm satırındaki dağınıklığın bedelini ve hesaptan teklife giden zinciri ayrı bir yazıda yazdık. Klinik satırındaki dağınıklığın bir teklif listesinde ayrı ayrı kalemlere dönüşmesini ise ilk sürümde hangi kaydın kurulduğunu sorduğumuz yazıda açtık. Burada ikisi olgu olarak duruyor; tekrar anlatmıyoruz.

Tablonun dördü de aynı ilacı almadı. Son satır ötekilerin devamı değil: AlgoKlima’da sorun ayrı programlar değil, aynı işin işletmenin iki tarafında ayrı ayrı tutulmasıydı. O yüzden dağınıklığın bu ikinci biçimini kendi bölümünde açıyoruz.

Dağınıklığın ikinci biçimi: aynı kayıt iki tarafta

Kayıt her zaman farklı programlara dağılmıyor. Bazen aynı iş, işletmenin iki tarafında ayrı ayrı tutuluyor. AlgoKlima servis yönetim yazılımının çıkış düzeni buydu: müşteri, cihaz ve teknisyen ofis tarafıyla saha tarafında ayrı yerlerde takip ediliyordu. Program adı saymak bu durumu görmüyor, çünkü taraflardan biri çoğunlukla yazılım bile değil.

Bu biçim ilk bakışta dağınıklık gibi görünmüyor. İki taraf da kendi kaydını güncel tutuyor ve ikisi de kendi içinde doğru. Sorun, ikisinin aynı işi anlatması: bir cihazın son servisinin ne zaman yapıldığı iki yerde yazılı ve yazılanlar birbirini tutmak zorunda değil. Hangisinin geçerli olduğunu söyleyen kural da yazılımda durmuyor; bir telefon görüşmesinde kuruluyor.

Bu yüzden sayımın birimi ekran değil kayıt. İki ekranı olup aynı kaydı tutan bir işletme sayımda bire düşüyor; tek ekranda çalışıp kaydını başka bir programa yeniden yazan işletme ikiye çıkıyor. Kural kulağa ince geliyor ama sayımı tersine çevirecek kadar belirleyici: yüzey çoğaltmak dağınıklık üretmiyor, kayıt çoğaltmak üretiyor.

AlgoKlima’da bugün iki yüzey var, iki defter yok. Ofisteki panel ile sahadaki uygulama, aynı müşterinin ve aynı cihazın kaydı üstünde çalışıyor; sahadan ve ofisten gelen değişiklikler ayrı kopyalar olarak yaşamıyor. Ürün bizim ve geliştirmesi sürüyor. Saha uygulamasının bağlantı yokken kaydı nasıl tuttuğunu ayrı bir yazıda açtık; burada ilgilendiğimiz tek şey sayım kuralı.

Bir sınırı da burada yazalım. Bir işin kaydını tek yerde toplamak ile kimin neyi ne zaman yapabileceğini kurala bağlamak ayrı işler. İkincisi yetki, onay ve iş akışı tarafında duruyor ve kurum içi yönetim yazılımları başlığına giriyor. Bu yazı o kapıyı açmıyor; yalnız adını söylüyor, çünkü sayım testini yapan işletme ikisini çoğunlukla tek soru sanıyor.

Karşı durum da var. İki yüzeyi tek kayda bağlamak her işte kazanç değil. Tek panelle yürüyen bir işte ikinci bir yüzey kurmak boşa maliyet. Yüzey sayısı bir hedef değil, işin kendisinden çıkan bir sonuç.

ERP adının kapsadığı alan nerede bitiyor

ERP adıyla satılan paketler bu yazının anlattığından daha geniş bir alanı kapsıyor: tedarik zinciri, üretim planlama, konsolide finans ve insan kaynakları da aynı başlığın altında geçiyor. Portföyümüzde bu alanları gösteren bir iş yok. O yüzden bu yazı da o alanlara iddia kurmuyor.

Gösterebildiğimiz zincir üç akışla sınırlı: işin kaydı, tüketilen malzemenin kaydı ve kesilen faturanın kaydı. Bu üçünü birlikte taşıyan işimiz AlgoCar; onun zinciri de dördüncü bir akışa uzanmıyor. Kapsamı bu şekilde kapatmak bir ödünleşim değil, iddiayı kanıtın yüzeyine eşitlemek. Bir satıcının kapsamını anlamanın yolu da aynı yerden geçiyor: sayabildiği başlıklar değil, gösterebildiği kayıt.

Kapsamı daraltmanın bir de okuma tarafı var. Bir ERP paketinin tanıtımında geçen başlık sayısı, o paketin sizin işinizde hangi kaydı tutacağını söylemiyor. Başlık listesi her pakette uzun; ayrımı yapan şey hangi kaydın nerede açıldığı. Sayım testi bu yüzden kapsam görüşmesinin de aracı oluyor: masaya başlık listesiyle değil, kendi kayıt yolunuzla oturuyorsunuz.

Kapsamın bir ucu da yasal defterde bitiyor. Defteri işletmenin dışındaki bir program tutuyorsa o program içeri alınamıyor; zincir orada devam etmiyor, bir teslim noktasında kapanıyor. Teslim noktasının nereye kurulduğunu ve ne geçtiğini ayrı bir yazıda ele aldık. Bu bölüm için yeterli olan tek şey, ERP’nin muhasebe programının yerine geçmek zorunda olmadığı.

Karşı durum açık yazılsın. Bir ERP arayışının merkezinde üretim planlama, tedarik zinciri ya da insan kaynakları varsa bu yazının anlattığı kapsam o arayışa cevap vermiyor. Kapsam sınırı bir pazarlık kalemi değil, kanıtın bittiği yer. Söylemenin bedeli de bir görüşme; söylememenin bedeli bir proje.

Kapanışta tek bir öneri var. Kendi düzeninizde bu testi bir kez yürütün, sonra bir satıcıyla konuşurken sorunuzu kapsam üzerinden kurun: hangi akışı gösterebiliyorsunuz. Bir işin bedeli ile kazancı sizde hâlâ ay sonunda mı buluşuyor sorusunun cevabı da o konuşmada işe yarıyor. ERP kapsamımızın nerede başlayıp nerede bittiği hizmet sayfasında aynı sınırla yazılı.