grubunun mali direktörünün ay sonunda en çok zaman alan kısmı, genellikle konsolide finansal tablolar için alt şirketlerden Excel talep etmek olur: hesap sınıflandırma standartları birbirinden farklı, müşteri kodları her birinin kendi yöntemiyle yazılır ve iç işlemler tam olarak dengeleştirilmez. Bunun temel nedeni, maliyetin yetersiz çalışması değil, çoklu kurumsal ortamda tek tip bir organizasyon, yetki ve ana veri altyapısının eksikliği — her bir alt şirket bilgi adası halindedir ve grup yalnızca “sonradan parçaları bir araya getirme” işini yapabilmektedir.

Çoklu kurumsal yönetimdeki tipik sorunlar
- Organizasyon sınırlarının belirsizliği : tüzel kişilik, yönetim birimi, kâr merkezi ve maliyet merkezi karışık kullanılır; raporlama boyutları birbiriyle uyumlu değildir.
- Yetkilerin tek tip uygulaması veya tamamen serbest bırakılması : ya alt şirketler grup görünümünü göremez, ya da grup alt şirketlerin ayrıntılarını değiştirebilir ve bunun sonucunda tartışmalar yaşanır.
- Ana verilerin bölünmesi : aynı müşteri farklı alt şirketlerde farklı kodlara sahip; aynı malzeme adı ve özellikleri için farklı yazım biçimleri mevcut; bu durum, satın alma ve stok analizlerinin birleştirilmesini imkânsız hale getiriyor.
- İç işlemlerin dengeleştirilmesinde zorluklar : ilişkili satışlar, para hareketleri ve hizmet faturaları sistemsel olarak kaydedilmez; konsolidasyon sırasında ise manuel mutabakat yapılır.
- Sistem binaları : A alt şirketi belirli bir ERP sistemini kullanırken, B başka bir sistemi tercih ediyor; grup BI sadece ODS katmanına bağlanarak çalışabiliyor.
İşletmenin nasıl ayrıştırılacağı: organizasyon, yetki ve ana veri üç katmanı
Organizasyon modeli
Katmanlı yapı önerilir: Grup → Tüzel kişilik (şirket) → İş birimi/Ünite → Departman → Pozisyon . Tüzel kişilik, yasal raporlar ve vergilendirme için; iş birimi, yönetim raporları ve değerlendirme için; departman ise yetki ve onay süreçleri için kullanılır. Bir kişi birden fazla organizasyona bağlı olabilir (örneğin iki alt şirketin üst düzey yöneticisi olabilir), ancak veri aidiyeti kesin olarak belirlenmelidir: bu sipariş, bu gider hangi tüzel kişilik ve hangi iş birimine aittir. Veri aidiyeti kesin olarak belirlenmelidir: Bu sipariş, bu harcama hangi tüzel kişilik ve hangi iş birimine aittir.
Yetki sistemi
RBAC + Veri Erişim Alanı yöntemini benimseyin: rol, fonksiyonel yetkileri tanımlar (onaylayıp yapabilecek mi, ana verileri değiştirebilecek mi); veri erişim alanı ise görülebilir ve yazılabilir sınırları belirler (sadece ilgili tüzel kişilik, ilgili iş birimi, grup genelinde okuma hakkı, farklı tüzel kişilikler arasında yetki gerektiren durumlar). Temel prensip:
- Varsayılan olarak en az görülebilirlik : Alt şirket kullanıcıları varsayılan olarak yalnızca kendi şirketlerini görür; grup kullanıcıları ise özet bilgileri görebilir, ancak aşağı inmek için denetim izi gereklidir.
- Ana verilerin katmanlı bakım ve yönetimi : Grup düzeyindeki ana veriler (müşteri grup hesapları, grup malzemeleri) yalnızca grup ana veri pozisyonu tarafından değiştirilebilir; alt şirket düzeyindeki genişletilmiş alanlar ise alt şirketler tarafından bakımlanabilir.
- Kurumsal çapta iş birliğine açık olan işlemler için açık yetki : A şirketi B şirketinin stokunu satarken, iç işlem kuralları ve her iki tarafın görülebilirliği konfigürasyonu gereklidir; paylaşılan hesaplarla işleyen sistemlerin yerine geçmemelidir.
Ana veri yönetimi
Temel ana veri alanları: Müşteriler, Tedarikçiler, Malzemeler, Hesaplar, Organizasyonlar, Çalışanlar . Her alan için: kodlama kuralları, zorunlu öznitelikler, benzersizlik kısıtları, değişiklik onayı ve yürürlükteki versiyon. Grup müşterileri için “tek müşteri – tek kod”: alt şirketler kayıt sırasında önce grup deposunu araştırır ve eğer bulunursa referans verir, bulamazsa yeni kayıt onayı sürecine devam eder. Malzemeler de aynı şekilde, “aynı mal için birden fazla isim” sorununu önlemek için MRP ve satın alma birleşmesinin bozulmasını engeller.

Tasarım nasıl yapılmalı: Kiracı, hesap seti ve konsolidasyon mimarisi
Tek depo, çoklu kiracı vs. Çoklu depo, federal sistem
Tek depo, çoklu kiracı : Tek sistem, org_id ile verileri ayırır; grup için güçlü kontrol ve yüksek standartlaşma açısından uygundur. Çoklu depo, federal sistem : Her alt şirket bağımsız örneklerdir; grup seviyesinde entegrasyon platformu veya MDM üzerinden senkronize edilir; alt şirketlerin yüksek otonomiye sahip olduğu ve eski sistemlerin taşınmasının zor olduğu durumlarda uygundur. Seçim, konsolide finansal tabloların gerçek zamanlılık gereksinimlerine, alt şirketlerin BT kapasitesine ve düzenleyici izolasyon şartlarına göre yapılmalıdır.
İç işlemler ve konsolidasyon
Sistem şu özelliklere sahip olmalıdır: İç satış siparişleri, iç satın alma, iç ödeme fiyatları, karşılıklı mutabakat işlemleri . Konsolide finansal tablo motoru, kurallara göre otomatik olarak iç gelirleri/maliyetleri/ödemeleri tespit eder ve dengeleme kaydını oluşturur (veya konsolidasyon sistemine aktarır). Eğer işlem düzeyinde kayıt yoksa, konsolidasyon hep manuel Excel tablolarıyla yapılır.
Onay ve süreçler kurumsal çapta
Grup düzeyindeki sistemlerde (sermaye harcamaları, önemli sözleşmeler gibi) onay zinciri tüzel kişilikler arasında geçebilir: Başlangıç alt şirket → İş birimi → Grup fonksiyonu → Grup üst düzey yöneticisi. Süreç motoru, organizasyon bazında yönlendirmeyi desteklemeli , ayrıca onaycı yalnızca kendi veri kapsamındaki belge ayrıntılarını görebilmelidir.
Uygulama nasıl gerçekleştirilmeli: Aşamalı yol haritası ve kabul prosedürleri
Aşamalı yaklaşım önerilir
- Organizasyon ve yetki altyapısı : Tüzel kişilik/İş birimi/Departman ağacı上线, RBAC + Veri Erişim Alanı test edilerek doğrulanmıştır.
- Grup ana verileri : Müşteriler ve malzemeler için tek müşteri – tek kod / tek mal – tek kod, alt şirketlerin bağlantı ve referans kullanımı.
- İç işlemler : İlgili satın alma ve satış, karşılıklı mutabakat işlemleri上线.
- Konsolide finansal tablolar : Dengeleme şablonlarının dışarı aktarılmasından sistem yarı otomatik ve tam otomatik hale getirilmesine kadar.
Kabul standartları
- Yeni müşterilerin herhangi bir alt şirkette oluşturulması sırasında, tekrar oranı test edilir yürürlüğe girer; grup hesabıyla bağlantılı sorgulama yapılabilir.
- Alt şirket kullanıcıları yetki aşamaz diğer tüzel kişiliklerin ayrıntılarını görüntüleyemez (güvenlik testi başarıyla geçilmiştir).
- İç işlemler listesi ve konsolidasyon dengeleme taslağı tek tuşla dışarı aktarılabilir , mali el yazı tablolarıyla arasındaki fark < belirlenen eşik.
Kurumsal çapta iş birliğinin tipik senaryoları
Grup içinde A şirketi üretirken, B şirketi satarken, sistem şu özellikleri desteklemelidir: İç transfer fiyatı (tüm kurumsal çapta karın yanlış dağılımı nedeniyle vergi risklerini önlemek için), Paylaşılan stok görünümü (B satış yaptığı sırada A’nın hazır ürün stokunu görebilmesi için), Tek tip müşteri görünümü (Grup hesabı herhangi bir alt şirkette sipariş verdiği zaman, geçmiş siparişlerle bağlantılı sorgulama yapılabilmesi için). Bu senaryolar e-posta ile koordinasyonla yürütülürse, yanıt günlerce sürer; tek tip organizasyon ve ana veri altyapısı sayesinde ise saatlerle kısaltılabilir.
Diğer yaygın ihtiyaç ise Grup satın alımlarının merkezileştirilmesi : Ortak satın alma sözleşmeleri, dağıtık teslimatlar, kurumsal çapta ödeme ve fatura eşleştirme — tasarım sırasında şunlar netleştirilmelidir: PO kim tarafından verilir, teslimat kim tarafından onaylanır, fatura kimle eşleştirilir, ödeme kim tarafından başlatılır — dört aşama üç tüzel kişilikle ilgili olabilir; süreç rotası organizasyon ağacına göre otomatik olarak dağıtılmalıdır, insanlar tarafından karşı tarafa yönlendirilen muhasebeci değil.
Yaygın hatalar
Organizasyon ağacı var ama veri erişim alanı yok : Fonksiyonel yetkiler mevcut, ancak veriler hâlâ tüm grup için açık. Ana verilerin hareketli temizlenmesi : Lansman öncesi ani birleşik düzenleme, lansman sonrası bakım görevi yok, üç ay sonra yeniden kaos.Alt şirketlerin değişim direncini göz ardı etmek: Grup kodlamasını zorla uygulamak direnişe yol açar; buna uygun teşvikler ve geçiş dönüştürme tabloları gereklidir. Konsolidasyon yalnızca mali işleri kapsar, operasyonel süreçlere bakmaz: Operasyonel ana veri doğru değilse, konsolide rakamlar ne kadar doğru olursa olsun işletme kararlarını destekleyemez.
Grubun çoklu kurumsal akıllı dönüşüm hedefi, “alt şirketlerin esnek işletilmesi” ile “grubun görselleştirilebilir ve yönetilebilir olması”nı aynı kurallar çerçevesinde bir arada tutmaktır; bu, sürekli rapor toplama savaşları değil, tam tersine bir yaklaşımdır.
Shandong XYN Information Technology Co., Ltd. (XYN Tech) grup tipi kuruluşlara çok organizasyonlu ERP, ana veri yönetimi ve konsolide raporlama konularına ilişkin akıllı sistemler sunmaktadır. Daha fazla bilgi için lütfen xynadmin.com adresine bakınız.