ERP ve Muhasebe

Bu konuda yıllardır dikkatimi çeken bir şey var: Türkiye'deki ERP'lerin büyük bölümü muhasebe kökenli, IFS ve SAP ise maliyet muhasebesi kökenli tasarlanmış sistemler. Bu tasarım farkı bugün bile hissediliyor.

Yerli ERP'lerin klasik yaklaşımı

Logo, Netsis, Mikro, ETA, Zirve gibi ürünlerin ilk nesilleri şu mantıkla büyüdü:

Muhasebe Hesabı
    ↓
Mizan
    ↓
Mali Tablolar

Dolayısıyla analitik boyutlar sonradan eklendi.

IFS'in başlangıç noktası

IFS'te ise başlangıç noktası şuydu:

Muhasebe Hesabı
+
Cost Center
+
Cost Element
+
Project
+
Activity

Çok boyutlu yapı, çekirdeğin içinde yer alıyor.

Tek eksen ve çok eksen: aradaki teknik fark

İki yaklaşımın farkı en net muhasebe satırının anatomisinde görülür.

Tek eksenli tasarımda analiz bilgisi hesap kodunun içine gömülür. Kod, hem hesabı hem de kırılımı taşımak zorundadır:

770.01.003
 │   │   └── kırılım (kira? elektrik? hangi birim?)
 │   └────── alt kırılım
 └────────── ana hesap (Genel Yönetim Gideri)

Çok eksenli tasarımda ise hesap yalnızca hesaptır; analiz ayrı alanlarda taşınır:

Hesap           770
Masraf Merkezi  ÜRT-01
Gider Çeşidi    ELEKTRİK
Proje           P-2026-14
Aktivite        MONTAJ

İki yapı aynı bilgiyi tutuyor gibi görünür. Aradaki fark, bilginin tek bir eksende sıkıştırılmış mı yoksa birbirinden bağımsız eksenlerde mi durduğudur. Bu fark, kırılım sayısı arttıkça büyür.

Kırılım patlaması

Diyelim ki 12 gider çeşidini, 8 masraf merkezini ve 6 projeyi ayrı ayrı görmek istiyorsunuz.

Tek eksenli yapıda her kombinasyon için ayrı bir hesap açmanız gerekir:

12 × 8 × 6 = 576 hesap

Çok eksenli yapıda ise her ekseni bir kez tanımlarsınız:

12 + 8 + 6 = 26 tanım

Asıl acı, yeni bir kırılım eklenirken çıkar. Tek eksenli yapıda yeni bir masraf merkezi açmak, o merkezin tüm gider ve proje kombinasyonları için yeni hesaplar açmak demektir — yukarıdaki örnekte 72 yeni hesap. Çok eksenli yapıda ise tek bir kod değeri eklenir, geçmiş yapı bozulmaz.

Sahada gördüğümüz binlerce satırlık hesap planlarının ardında genellikle bu vardır: sistem çok boyutlu düşünmediği için hesap planı boyutların yerine geçmiştir.

Raporlama tarafındaki bedel

Fark yalnızca tanım sayısında kalmaz; rapor yazarken de karşınıza çıkar.

Tek eksenli yapıda analiz, hesap kodunu parçalayarak yapılır:

-- analiz hesap kodunun içinden çıkarılıyor
SELECT SUBSTR(hesap_kodu, 1, 3) AS ana_hesap,
       SUBSTR(hesap_kodu, 5, 2) AS gider_turu,
       SUM(borc - alacak)
  FROM muhasebe_satir
 GROUP BY SUBSTR(hesap_kodu, 1, 3), SUBSTR(hesap_kodu, 5, 2);

Çok eksenli yapıda ise alanlar zaten ayrıdır:

-- analiz kendi kolonlarında
SELECT hesap, masraf_merkezi, gider_cesidi,
       SUM(borc - alacak)
  FROM muhasebe_satir
 GROUP BY hesap, masraf_merkezi, gider_cesidi;

İkisi arasındaki fark üç yerde kendini gösterir:

• Performans. Kolonu fonksiyonla saran sorgular, o kolondaki normal indeksi kullanamaz. Ayrıntısı için: Oracle'da performans notumuz.
• Kırılganlık. Kod yapısı bir kez değişirse (araya bir hane eklenirse) tüm raporların karakter konumları bozulur.
• Esneklik. Çok eksenli yapıda yeni bir kırılıma göre rapor almak, sorguya bir kolon eklemekten ibarettir. Tek eksenli yapıda çoğu zaman hesap planını değiştirmeyi gerektirir.

Bütçe ve kontrol tarafı

Boyutlar yalnızca raporu değil, kontrolü de mümkün kılar. Bütçeyi "hesap" üzerinden değil, "masraf merkezi + gider çeşidi" üzerinden kurabildiğinizde bütçe bir rapor olmaktan çıkıp uyarı, bloke ve onay mekanizmasına dönüşür. Bu konuyu ayrıca yazdık: SAP ve IFS'te bütçe anlayışı.

Tek Düzen Hesap Planı'nı bırakmak gerekmiyor

Burada sık karşılaştığımız bir yanlış anlama var. Çok eksenli yapıya geçmek, Tek Düzen Hesap Planı'nı terk etmek demek değildir.

TDHP yasal bir zorunluluktur; beyannameler, mali tablolar ve denetim onun üzerinden yürür. Çok eksenli sistemlerde de yasal defter ekseni hesap kodudur. Değişen şey şudur: analiz yükü hesap kodunun sırtından alınır.

Yani 770 hesabı 770 olarak kalır; elektrik gideri, üretim müdürlüğü ve ilgili proje bilgisi aynı satırda ayrı alanlarda taşınır. Beyanname tarafında hiçbir şey değişmez, yönetim raporlaması tarafında ise kapı açılır.

Masraf merkezi var ama kullanılmıyor

Logo, Netsis ve Mikro'nun tamamında şu yapılar mevcut:

• Masraf Merkezi
• Proje Kodu
• İş Merkezi
• Departman

Ama çoğu projede kullanılmıyor. Çünkü kullanıcı tarafında şu anlayış yaygın:

"770.01 Personel, 770.02 Elektrik, 770.03 Kira açalım yeter."

Sonuç olarak sistemde masraf merkezi özelliği olsa bile organizasyon onu kullanmıyor.

Bunun tek sebebi alışkanlık da değil. Boyut alanı zorunlu tutulmadığında, girişlerin bir kısmı boş kalır; boş kalan boyut raporu güvenilmez yapar; güvenilmeyen rapora kimse bakmaz; bakılmayan alanı kimse doldurmaz. Döngü kendini besler.

Nereden başlanır

Boyutlu yapıya geçmek büyük bir proje olmak zorunda değil. Sahada işe yarayan sıra şu:

1. Hangi kararı vereceğinizi yazın. "Hangi hattın enerji maliyeti yüksek?" gibi somut bir soru, kaç boyuta ihtiyacınız olduğunu da söyler.
2. Boyut sayısını az tutun. İki iyi işleyen boyut, altı yarım dolu boyuttan iyidir.
3. Zorunlu yapın. Boş geçilebilen boyut, olmayan boyuttur.
4. Raporu boyut üzerinden kurun. Ekipler kendi masraf merkezinin raporunu görmeye başladığında alan kendiliğinden doğru dolmaya başlar.

Logo, Netsis, Mikro, Uyumsoft, ETA ve Zirve ilgili şirketlerin; IFS IFS AB'nin, SAP SAP SE'nin tescilli markalarıdır. Bu not bağımsız bir değerlendirmedir.