Yazılım Çözümleri ile Çok Şirketli Operasyonlarda Yetki ve Veri Ayrımı Nasıl Kurulur?

Ortak ve şirkete özel veriler nasıl doğru sınıflandırılır?

İlk karar, her veri nesnesinin grup genelinde ortak mı, belirli bir şirkete mi ait olduğunu tanımlamaktır. Müşteri, ürün, tedarikçi veya kullanıcı gibi kayıtlar bazı alanlarda ortak kimlik taşıyabilir; ancak fiyat, sözleşme, sipariş, maliyet, banka bilgisi veya operasyon notu gibi alanlar şirket bazında ayrılabilir. Veri sahipliği yalnızca nesne seviyesinde değil, gerekirse alan, işlem ve yaşam döngüsü seviyesinde belirlenmelidir.

Veri envanteri kararın başlangıç noktasıdır

Teknik ekip, ekran tasarımından önce veri envanteri çıkarmalı ve her kaydın sahibi, kaynağı, paylaşım sınırı, güncelleme yetkisi ve saklama kuralını tanımlamalıdır. Böylece aynı müşteri kimliğinin grup genelinde tekilleştirilmesi mümkün olurken iştiraklerin ticari detayları birbirinden izole tutulabilir. Ortak ürün kataloğu kullanılabilir ancak şirket fiyatları ayrı kalabilir; merkezi tedarikçi kaydı paylaşılırken sözleşme koşulları yalnızca ilgili tüzel kişilik tarafından görülebilir. Bu yaklaşım, iştirakler arası veri yönetimini daha öngörülebilir hale getirir ve yeni şirketlerin sisteme eklenmesini kolaylaştırır.

• Hangi kayıtlar grup genelinde ortak ana veri olarak tutulacak?
• Hangi alanlar yalnızca kaydın sahibi şirket tarafından görülebilecek?
• Ortak kaydın güncelleme sorumluluğu hangi sistem veya ekipte olacak?
• Bir şirketten diğerine veri aktarımı hangi olayla ve hangi izinle yapılacak?
• Silme, arşivleme ve anonimleştirme yetkisi şirket bazında nasıl ayrılacak?

Güvenlik bir ürün değil, bir süreçtir. - Bruce Schneier

Çok şirketli yazılım mimarisi hangi modelle kurulmalı?

Çok şirketli yazılım geliştirme için tek bir doğru veri modeli yoktur; seçim şirketler arasındaki izolasyon seviyesi, raporlama ihtiyacı, ölçek, mevzuat koşulları ve operasyonel bağımsızlığa göre yapılmalıdır. Aynı veritabanında şirket kimliğiyle ayrım, ayrı şemalar, ayrı veritabanları veya hibrit modeller kullanılabilir. Mimari sınır, yalnızca teknik performansı değil, yetki hatalarının etkisini, bakım maliyetini ve gelecekte yeni şirket ekleme yöntemini de belirler.

İzolasyon seviyesi iş modeline göre seçilmelidir

Ortak uygulama katmanı kullanılırken şirket verilerinin mantıksal veya fiziksel olarak ayrılması mümkündür. Özellikle büyüyen grup yapılarında, çok kiracılı SaaS platformu mimarisinin nasıl geliştirildiğini anlamak tenant ayrımı, yapılandırma yönetimi ve ölçeklenebilirlik kararlarını netleştirir. Ancak tenant ile tüzel şirket kavramı aynı şey olmak zorunda değildir; grup, holding, ülke veya iş birimi gibi kapsam katmanları ayrıca modellenebilir. Tasarımın şirket sayısı arttığında veri taşıma, yedekleme, arşivleme ve raporlama yükünü nasıl değiştireceği de keşif aşamasında değerlendirilmelidir.

• Paylaşımlı şema modeli merkezi yönetim sunar ancak filtre disiplinini kritik hale getirir.
• Ayrı şema modeli şirket sınırlarını belirginleştirirken operasyon yükünü artırabilir.
• Ayrı veritabanı modeli güçlü izolasyon sağlar fakat konsolidasyonu karmaşıklaştırabilir.
• Hibrit model kritik verileri ayırıp ortak servisleri merkezi tutabilir.
• Yeni şirket açılışı, taşıma ve arşivleme süreçleri baştan tasarlanmalıdır.

Grup merkezi ve iştirak erişimleri nasıl sınırlandırılır?

Grup merkezinin geniş raporlama ihtiyacı, sınırsız operasyon yetkisi anlamına gelmemelidir. Kurumsal rol yetki sistemi; kullanıcının rolünü, bağlı olduğu şirketi, eriştiği veri nesnesini ve gerçekleştirmek istediği işlemi birlikte değerlendirmelidir. En az yetki ilkesiyle merkez kullanıcıları yalnızca görevleri için gerekli şirketlere, alanlara ve aksiyonlara erişebilmelidir; salt “merkez yönetici” rolü bütün veriler üzerinde değişiklik hakkı vermemelidir.

Rol matrisi unvandan daha ayrıntılı olmalıdır

Merkez ekip, iştirak yöneticisi ve operasyon kullanıcısı için yalnızca rol tabanlı erişim çoğu zaman yeterli olmaz. Rol tabanlı model, şirket veya kayıt bağlamını kullanan ek kurallarla desteklenebilir. Sağlayıcı karşılaştırırken yetkilendirme, entegrasyon ve destek modelinin nasıl değerlendirileceği de incelenmeli; yetki kurallarının kod içine dağılmak yerine yönetilebilir bir politika katmanında toplanması tercih edilmelidir. Ayrıca geçici görevler, vekâlet, onay limiti ve hassas alan erişimi gibi istisnalar rol matrisinin ayrı satırlarında tanımlanmalıdır.

• Merkez yönetici tüm şirketleri görebilir fakat her işlemi değiştiremeyebilir.
• İştirak yöneticisi yalnızca kendi şirketinin kullanıcı ve süreçlerini yönetebilir.
• Operasyon kullanıcısı görev kapsamındaki kayıtları görüntüleyip işleyebilir.
• Finans, insan kaynakları veya hukuk verileri ek hassasiyet katmanı taşıyabilir.
• Geçici veya vekâleten verilen yetkiler süreli ve kayıtlı olmalıdır.

İştirakler arası işlemler ve onaylar nasıl izlenmeli?

İştirakler arası işlem, tek şirkete ait sıradan bir kayıt gibi modellenmemelidir. Kaynak şirket, hedef şirket, işlemi başlatan kullanıcı, karşı tarafın kabulü, muhasebe sonucu ve operasyon sonucu ayrı izlenmelidir. Çift taraflı işlem izi, bir şirketin yaptığı değişikliğin diğer şirketin kaydını sessizce değiştirmesini önler ve şirket bazlı iş akışını denetlenebilir hale getirir. Böylece işlem hangi aşamada olursa olsun sorumluluğun hangi tüzel kişilikte olduğu görülebilir.

Onay zinciri tarafların sorumluluğunu görünür kılmalıdır

Stok transferi, grup içi hizmet, masraf yansıtma, sipariş aktarımı veya ortak müşteri süreci gibi senaryolarda durum geçişleri açıkça tanımlanmalıdır. Bir işlem gönderildiğinde karşı şirkette yeni bir onay görevi oluşabilir; reddedildiğinde gerekçe kaydedilebilir; düzeltme gerekiyorsa önceki sürüm korunabilir. Limit aşımı veya kritik tutar gibi koşullar ek onay katmanı başlatabilir. Böylece süreç yalnızca tamamlanmış son kaydı değil, kararların ve değişikliklerin tamamını açıklayan bir denetim izi üretir.

• Kaynak ve hedef şirket kimlikleri işlem kaydında ayrı tutulmalıdır.
• Gönderme, kabul, ret ve iptal adımları ayrı durumlar olarak izlenmelidir.
• Her onay adımı kullanıcı, zaman ve gerekçe bilgisi taşımalıdır.
• Karşı şirketin verisi doğrudan düzenlenmek yerine kontrollü akışla güncellenmelidir.
• Düzeltme ve geri alma işlemleri önceki kayıt izini silmemelidir.

ERP ve CRM sistemlerinde veri sorumluluğu nasıl paylaşılır?

Mevcut ERP ve CRM sistemleri korunacaksa her veri alanı için hangi sistemin ana kaynak olduğu belirlenmelidir. Bir müşteri ERP'de finansal hesap, CRM'de satış ilişkisi, yeni platformda operasyon profili taşıyabilir. Kaynak sistem tanımlanmadan iki yönlü senkronizasyon kurmak çakışan güncellemeler, mükerrer kayıtlar ve belirsiz veri sahipliği üretir. Bu nedenle entegrasyon tasarımı “hangi sistem bağlanacak” sorusundan önce “hangi bilgi kimin sorumluluğunda” sorusunu cevaplamalıdır.

Entegrasyon sözleşmesi alan bazında tanımlanmalıdır

Kurumsal entegrasyon projesinde hangi sistemin hangi alanı oluşturduğu, güncellediği ve doğruladığı açıkça belgelenmelidir. SaaS mimarisi, API entegrasyonları ve bulut altyapısının birlikte planlanması veri akışının yalnızca bağlantı kurmakla bitmediğini gösterir. Hata kuyruğu, tekrar deneme, eşleme kuralları, senkronizasyon gecikmesi ve veri düzeltme yetkisi de sorumluluk modelinin parçasıdır. Özellikle birden fazla ERP kullanılan gruplarda ortak kimlik eşleştirme kuralları merkezi olarak yönetilmelidir.

• Müşteri ana kimliğinin hangi sistemde üretileceği belirlenmelidir.
• Finansal alanların ERP dışından değiştirilip değiştirilemeyeceği tanımlanmalıdır.
• CRM satış verisinin hangi şirketlerle paylaşılacağı sınırlandırılmalıdır.
• Entegrasyon hatalarında kayıt sahibi ve düzeltme sorumlusu atanmalıdır.
• Toplu veri taşıma ile günlük senkronizasyon kuralları birbirinden ayrılmalıdır.

Merkezi raporlama veri ayrımını bozmadan nasıl yapılır?

Merkezi raporlama yazılımı, iştirak verilerini tek ekranda göstermek için operasyonel erişim sınırlarını kaldırmak zorunda değildir. Konsolide metrikler ayrı bir raporlama katmanında üretilebilir ve kullanıcının yetkisine göre şirket, bölge veya grup seviyesinde sunulabilir. Raporlama yetkisi ile işlem yapma yetkisi birbirinden ayrıldığında merkez ekip görünürlük kazanırken operasyon sistemindeki değişiklik hakları sınırlı kalabilir. Bu ayrım, yönetim raporu ihtiyacının operasyonel yetki genişlemesine dönüşmesini engeller.

Konsolidasyon ortak tanım ve kontrollü erişim ister

Ciro, sipariş, müşteri, stok veya hizmet seviyesi gibi göstergelerin şirketler arasında karşılaştırılabilmesi için ortak veri sözlüğü gerekir. Raporlama katmanı farklı ERP'lerden gelen alanları normalize edebilir; ancak ham kayda erişim yalnızca yetkili rollere açılmalıdır. Ayrıca rapor filtresi değiştirilerek başka şirket verisinin görülmesi, dışa aktarım, e-posta ile zamanlanmış rapor gönderimi veya indirilebilir dosyalar gibi ikincil erişim kanalları da kontrol edilmelidir. Konsolidasyon için kullanılan veri dönüşümlerinin kaynağı ve güncellik zamanı raporda izlenebilir olmalıdır.

• Grup KPI'ları için ortak hesaplama tanımları oluşturulmalıdır.
• Şirket bazlı satır erişimi raporlama katmanında da uygulanmalıdır.
• Ham veri ile özet metrik erişimleri ayrı yetkilendirilmelidir.
• Dışa aktarma ve paylaşma hakları görüntüleme hakkından ayrılmalıdır.
• Rapor verisinin güncellik seviyesi ve kaynak sistemi görünür olmalıdır.

Veri ayrımı ekran görünürlüğünün ötesinde nasıl korunur?

Bir kaydı arayüzde gizlemek, güvenli veri ayrımı sağlamak için yeterli değildir. API, arka uç servisleri, rapor sorguları, dosya çıktıları ve entegrasyon hesapları aynı erişim politikasına uymalıdır. Sunucu tarafı yetkilendirme, kullanıcının yalnızca arayüz üzerinden değil doğrudan istek gönderdiğinde de başka şirketin verisine erişmesini engellemelidir. Şirket kimliğinin yalnızca kullanıcıdan gelen parametreye güvenilerek belirlenmesi yerine, oturum ve yetki bağlamıyla doğrulanması gerekir.

Denetim izi ve teknik kontroller birlikte çalışmalıdır

Yazılım güvenlik tasarımı; nesne seviyesinde erişim kontrolü, şirket bağlamının doğrulanması, servis hesaplarının sınırlandırılması ve kritik hareketlerin loglanması gibi katmanları birlikte ele almalıdır. Özellikle yönetici rollerinde yapılan şirket değiştirme, toplu dışa aktarma veya geçici ayrıcalık yükseltme işlemleri ek kayıt üretmelidir. Loglar yalnızca “kim giriş yaptı” sorusunu değil, hangi şirkette hangi kayda hangi işlem uygulandığını cevaplayabilmelidir. Böylece yetki ihlali yalnızca önlenmeye değil, sonradan incelenmeye de uygun hale gelir.

• Her API isteğinde kullanıcı ve şirket kapsamı sunucu tarafında doğrulanmalıdır.
• Kayıt kimliği değiştirilerek çapraz şirket erişimi denenmesi engellenmelidir.
• Servis hesapları yalnızca ihtiyaç duydukları şirket ve işlemlere erişmelidir.
• Kritik yönetici işlemleri korumalı kayıt izine alınmalıdır.
• Toplu indirme ve rapor dışa aktarma işlemleri ayrıca yetkilendirilmelidir.

Yetki ve veri ayrımı kabul testlerinde nasıl doğrulanır?

Kabul testleri yalnızca doğru kullanıcının doğru ekranı görmesini değil, yanlış kullanıcının erişemediğini de kanıtlamalıdır. Şirket, rol, veri nesnesi ve işlem kombinasyonlarından bir test matrisi oluşturularak pozitif ve negatif senaryolar birlikte yürütülmelidir. Negatif yetki testi, çok şirketli mimaride kritik bir doğrulamadır çünkü görünmeyen ancak API, rapor veya dışa aktarım kanalı üzerinden erişilebilen açıkları ortaya çıkarabilir. Test sonuçları, proje kabulünün ölçülebilir kanıtı olarak saklanmalıdır.

Kabul kriterleri teklif aşamasında tanımlanmalıdır

Test senaryoları proje sonunda düşünülmemeli; teknik kapsam ve kabul kriterleri teklif içinde yer almalıdır. Sağlayıcı seçimi sırasında kod kalitesi, test yaklaşımı ve kaynak kod tesliminin nasıl değerlendirileceği incelenerek yetki testlerinin otomasyon düzeyi ve sorumluluğu netleştirilebilir. Özellikle çapraz şirket erişimi, rol değişimi, aktif oturum davranışı ve entegrasyon kullanıcıları için tekrarlanabilir testler istenmelidir. Böylece yeni sürümlerde aynı güvenlik kontrollerinin yeniden doğrulanması kolaylaşır.

• Her rol için izin verilen ve reddedilmesi gereken işlemler test edilmelidir.
• Başka şirketin kayıt kimliğiyle doğrudan erişim denenmelidir.
• API, rapor ve dosya dışa aktarım kanalları ayrıca kontrol edilmelidir.
• Yetki değişikliğinin aktif oturumlara etkisi doğrulanmalıdır.
• Denetim kayıtlarının kullanıcı, zaman, şirket ve işlem bilgisini tuttuğu görülmelidir.

Teknik keşif öncesinde hangi bilgiler hazırlanmalıdır?

Teknik keşif görüşmesine yalnızca özellik listesiyle değil, şirket yapısı ve işlem örnekleriyle hazırlanmak gerekir. Organizasyon şeması, kullanılan ERP ve CRM sistemleri, mevcut kullanıcı rolleri, şirketler arası işlem örnekleri ve konsolide rapor beklentileri mimari kararları doğrudan etkiler. Keşif paketi ne kadar somut olursa çözüm sağlayıcıların kapsam, risk, veri sorumluluğu ve entegrasyon yaklaşımını karşılaştırmak o kadar anlamlı hale gelir. Bu hazırlık, varsayımların teklif içine gizlenmesini de azaltır.

Teklif karşılaştırması mimari varsayımları görünür kılmalıdır

İki teklif aynı ekranları kapsasa bile veri izolasyonu, entegrasyon sorumluluğu, loglama, kabul testi ve yeni şirket ekleme yaklaşımı farklı olabilir. Bu nedenle tekliflerde yalnızca modül listesini değil, veri modeli, rol matrisi, kaynak sistem sorumluluğu, raporlama katmanı, güvenlik kontrolleri ve teslim sonrası değişiklik yönetimini de karşılaştırın. Böylece yüksek bütçeli yatırımın kapsamı geliştirme başlamadan önce daha ölçülebilir hale gelir ve teknik keşif görüşmesi doğrudan karar gerektiren noktalar üzerine kurulabilir.

• Grup ve iştirak organizasyon şemasını hazırlayın.
• Merkez, iştirak yöneticisi ve operasyon rollerini örnekleyin.
• ERP, CRM ve diğer kaynak sistemlerin veri sahipliğini listeleyin.
• En az üç gerçek iştirakler arası işlem ve onay senaryosu paylaşın.
• Şirket bazlı ve konsolide rapor beklentilerini örnek çıktılarla tanımlayın.
• Kabul testinde doğrulanmasını istediğiniz erişim sınırlarını yazılı hale getirin.