Organizasyon → Departman → Space

Knowentra'da kurumsal yapı üç katmanda modellenir:

Organizasyon → Departman → Space

Bu yapı yalnızca sol menüyü düzenlemek için kullanılmaz. Bir kullanıcının hangi bilgiye erişebileceğini, bir agent'ın hangi araçları kullanabileceğini ve bir workflow'un hangi iş bağlamında çalışacağını belirleyen temel kapsam modelidir.

Basitçe:

Organizasyon, kurumun en üst yönetim ve güven sınırıdır.
Departman, ortak sorumluluğa ve bilgi alanına sahip ekibi temsil eder.
Space, belirli bir amaç için veri, agent, araç ve süreçlerin bir araya geldiği çalışma alanıdır.

ℹ

İyi tasarlanmış bir hiyerarşi, kullanıcıların yalnızca ihtiyaç duyduğu bağlamı görmesini ve agent'ların yalnızca izin verilen sınırlar içinde çalışmasını kolaylaştırır.

Kapsam modeli

Organizasyon
├── İnsan Kaynakları
│   ├── İşe Alım
│   ├── Çalışan Politikaları
│   └── Eğitim ve Gelişim
├── Finans
│   ├── Fatura Operasyonları
│   ├── Mutabakat
│   └── Yönetim Raporlama
└── Hukuk
    ├── Sözleşme İnceleme
    ├── Mevzuat Araştırma
    └── Yükümlülük Takibi

Her alt katman, üst katmanın kurumsal bağlamı içinde yaşar; fakat daha dar bir amaca ve erişim kapsamına sahiptir.

Katman	Temsil ettiği şey	Tipik kapsam
Organizasyon	Tüzel veya yönetsel kurum sınırı	Genel güvenlik, kimlik, model ve dağıtım politikaları
Departman	Ortak sorumluluğa sahip iş birimi	Üyelik, departman bilgisi, ortak veri ve yönetişim
Space	Belirli iş veya proje alanı	Agent talimatı, araçlar, bilgi bağlamı, workflow ve günlük çalışma

Organizasyon: en üst güven sınırı

Organizasyon, Knowentra içindeki en geniş yönetim alanıdır. Kurum genelini etkileyen kararlar bu katmanda ele alınır:

Kullanıcıların ve kimlik sağlayıcılarının yönetimi
Kurum genelinde kullanılabilecek model ve servislerin belirlenmesi
Genel güvenlik, audit ve veri işleme politikaları
Departmanların ve üst düzey yönetici rollerinin oluşturulması
Dağıtım ve kurumsal entegrasyon kararları

Birden fazla şirket veya tamamen ayrılması gereken kurum birimi aynı platformu kullanacaksa, bunları yalnızca departmanlara ayırmak yeterli olmayabilir. Aralarında kullanıcı, veri ve yönetişim paylaşımı olmaması gerekiyorsa ayrı organizasyon sınırları düşünülmelidir.

⚠

Organizasyon sınırı, yalnızca isimlendirme kararı değildir. Birimler arasında hangi kimlik, model, politika ve audit kapsamının paylaşılacağını belirler.

Ne zaman yeni organizasyon düşünülmeli?

Aşağıdaki sorulardan çoğuna “evet” yanıtı veriyorsanız ayrı organizasyon daha doğru olabilir:

Kullanıcı ve yönetici grupları tamamen farklı mı?
Verilerin ve audit kayıtlarının birbirinden kesin biçimde ayrılması mı gerekiyor?
Model sağlayıcıları veya veri işleme politikaları farklı mı?
Ayrı altyapı, lisans ya da yönetişim sorumluluğu var mı?

Sadece ekip veya iş konusu farklıysa genellikle yeni organizasyon yerine departman ya da space yeterlidir.

Departman: ekip ve bilgi alanı

Departman, kurum içindeki ortak bir iş sorumluluğunu temsil eder. İnsan Kaynakları, Finans, Hukuk veya Bilgi Teknolojileri gibi kalıcı iş birimleri bunun doğal örnekleridir.

Departman katmanında genellikle şunlar birlikte düşünülür:

Departman üyeleri ve yönetici rolleri
Ekip tarafından ortak kullanılan bilgi tabanları
Departmana ait agent ve workflow görünürlüğü
Sonuç, onay, uyarı ve operasyon akışları
Departman içindeki space'lerin yaşam döngüsü

Departman bilgi tabanı

Knowentra'da bilgi tabanları departman bağlamında yönetilebilir. Böylece departmanın onaylı politika, prosedür ve belgeleri o departmandaki izinli deneyimlere kaynak olabilir.

Bu, departmandaki her kullanıcının her belgeyi otomatik olarak göreceği anlamına gelmemelidir. Belge ve klasör erişimi, kullanıcı rolü ve space kapsamı birlikte değerlendirilmelidir.

Bilgi tabanı oluşturma adımları için: Belge Yükleme ve Bilgi Tabanı.

Departman ne zaman açılmalı?

Yeni bir departman oluşturmak için yalnızca farklı bir proje adı yeterli değildir. Şunlardan biri varsa departman anlamlı bir sınır olabilir:

Ayrı bir ekip üyeliği ve yönetim sorumluluğu
Kalıcı ve kendine özgü bilgi alanı
Diğer birimlerden ayrılması gereken sonuç veya onay akışı
Departman düzeyinde raporlama ve audit ihtiyacı

Geçici bir proje, tek kullanım senaryosu veya aynı ekip içindeki dar bir çalışma konusu için space tercih edilmelidir.

Space: işin gerçekleştiği bağlam

Space, kullanıcıların agent ile çalıştığı, bilgiye eriştiği ve workflow'ları yönettiği en dar iş bağlamıdır.

Bir space şu soruya açık bir yanıt vermelidir:

“Bu alanda kim, hangi bilgi ve araçlarla, hangi işi yapıyor?”

Örneğin “Finans” bir departmanken aşağıdakiler ayrı space olabilir:

Fatura Operasyonları
Aylık Mutabakat
Bütçe ve Tahmin
Yönetim Raporlama

Bu ayrım, tek bir genel finans agent'ına bütün araçları ve belgeleri vermek yerine her iş için daha dar ve anlaşılır yetkiler tanımlamanızı sağlar.

Bir space'in temel bileşenleri

Bileşen	Yanıtladığı soru
Amaç	Bu space hangi işi veya sonucu destekliyor?
Üyeler	Kimler bu alanda çalışabilir veya sonuçları görebilir?
Agent talimatı	Space Agent nasıl davranmalı, neyi yapmamalı?
Bilgi bağlamı	Hangi koleksiyon ve belgeler kullanılabilir?
Araçlar	Agent hangi API, veri kaynağı veya fonksiyonları çağırabilir?
Workflow'lar	Hangi tekrarlanan süreçler bu alanda çalışır?
Onaylar	Hangi aksiyonlarda insan kararı zorunludur?

Space Agent ve Workflow Agent ilişkisini ayrıntılı okumak için: Workflow ve Space Agent.

Yetki ve kapsam nasıl düşünülmeli?

Yetki modelini “kullanıcı sisteme girebiliyor mu?” sorusuna indirgemeyin. Kurumsal AI'da erişim birkaç ayrı düzeyde değerlendirilmelidir:

Görünürlük: Kullanıcı organizasyonu, departmanı veya space'i görebiliyor mu?
Bilgi erişimi: Hangi belge ve bilgi tabanlarını sorgulayabiliyor?
Model erişimi: Hangi yerel veya harici modeller kullanılabilir?
Araç erişimi: Agent hangi sistemleri okuyabilir veya güncelleyebilir?
Aksiyon yetkisi: Hangi işlemler doğrudan, hangileri insan onayıyla yapılabilir?
Yönetim yetkisi: Kim üye, talimat, araç veya workflow yapılandırmasını değiştirebilir?

✦

En az yetki ilkesiyle başlayın: kullanıcıya ve agent'a yalnızca mevcut iş için gereken bilgi ve araçları verin. Yeni ihtiyaç ortaya çıktığında kapsamı kontrollü biçimde genişletin.

Miras ve açık sınırlar

Üst katmandaki bir politika alt katmanlara varsayılan sağlayabilir; ancak kritik erişimlerde yalnızca örtük mirasa güvenmek yerine açık sınırlar tanımlayın.

Örneğin:

Organizasyon, kullanılabilecek model sağlayıcılarını belirleyebilir.
Departman, ortak bilgi kaynaklarını yönetebilir.
Space, bu kaynakların yalnızca işiyle ilgili bölümünü ve gerekli araçları kullanabilir.
Workflow, belirli bir yazma aksiyonu için ayrıca insan onayı isteyebilir.

Bu yaklaşım hem aşırı geniş yetkiyi hem de aynı ayarın her space'te tekrar edilmesini önler.

Space tasarlarken karar çerçevesi

Yeni bir space açmadan önce aşağıdaki soruları cevaplayın.

1. Tek ve anlaşılır bir iş amacı var mı?

“Finans işleri” çok geniştir. “Aylık mutabakat istisnalarını inceleme” daha iyi bir space amacıdır.

2. Bilgi kaynakları diğer işlerden farklı mı?

Kullanılan belge koleksiyonu, veri tabanı veya prosedür farklıysa ayrı space erişim modelini sadeleştirir.

3. Araç veya aksiyon riski farklı mı?

Sadece belge okuyan bir asistanla ERP kaydı güncelleyebilen bir agent aynı araç kapsamını paylaşmamalıdır.

4. Üye veya onaylayanlar farklı mı?

İşi yürüten ekip ve kritik aksiyonu onaylayan rol farklıysa bunu space ve workflow tasarımında görünür kılın.

5. Sonuçların ayrı takip edilmesi gerekiyor mu?

Farklı SLA, audit, raporlama veya operasyon kuyruğu varsa ayrı space daha sağlıklı olabilir.

Örnek: Finans departmanını yapılandırma

Departman

Finans

Ortak bilgi:

Finans politika ve prosedürleri
Hesap planı rehberi
Onaylı rapor şablonları
Yetki ve limit matrisi

Space 1 — Fatura Operasyonları

Amaç: Gelen faturaları ön işlemek ve istisnaları incelemeye hazırlamak
Bilgi: Fatura prosedürü, tedarikçi kuralları
Araç: Belge kaynağı, tedarikçi sorgusu, ERP salt-okunur erişim
Onay: ERP'ye kayıt veya ödeme süreci başlatma

Space 2 — Mutabakat

Amaç: Farklı kaynaklardaki kayıtları eşleştirmek
Bilgi: Mutabakat kontrol listeleri
Araç: Finansal veri kaynakları, rapor üretme
Onay: Düzeltme kaydı oluşturma

Space 3 — Yönetim Raporlama

Amaç: Onaylı verilerden dönemsel rapor taslağı hazırlamak
Bilgi: Rapor tanımları ve geçmiş dönem açıklamaları
Araç: Veri ambarı salt-okunur erişim
Onay: Raporu dağıtım listesine gönderme

Bu yapı, her agent'ın yalnızca kendi işine gereken bilgi ve araçları kullanmasını sağlar.

İsimlendirme önerileri

İyi isimler hem kullanıcıların alanı bulmasını hem de yöneticilerin audit kayıtlarını anlamasını kolaylaştırır.

Tercih edin:

“Tedarikçi Fatura Kontrolü”
“Aylık Satış Raporlama”
“Sözleşme Yükümlülük Takibi”
“BT Destek Talebi Sınıflandırma”

Kaçının:

“AI Alanı”
“Test 2”
“Genel”
“Yeni Proje”

Space adında mümkünse nesne + iş yapısını kullanın: “Fatura + Kontrol”, “Sözleşme + İnceleme”.

Yayına almadan önce kontrol listesi

Organizasyon ve departman sınırı gerçek yönetişim yapısını yansıtıyor.
Space'in tek cümleyle açıklanabilen bir iş amacı var.
Üyeler en az yetki ilkesiyle seçildi.
Bilgi kaynaklarında taslak veya geçersiz belgeler ayrıldı.
Agent talimatında kapsam dışı davranışlar belirtildi.
Araçlar okuma ve yazma yetkisine göre ayrıldı.
Geri alınamaz aksiyonlar için insan onayı tanımlandı.
Workflow sonuçlarını izleyecek sorumlu ekip belli.
Test senaryoları gerçek veri yerine güvenli örneklerle denendi.
Kullanım ve audit kayıtlarının kim tarafından inceleneceği belirlendi.

Sık yapılan hatalar

Her şeyi tek space'e koymak

Tek space kısa vadede kolay görünür; fakat zamanla çok fazla belge, araç ve yetki biriktirir. Agent'ın bağlamı belirsizleşir ve erişim kapsamı gereksiz genişler.

Organizasyon şemasını birebir kopyalamak

Her resmi birim için departman açmak zorunda değilsiniz. Hiyerarşi, yalnızca insan kaynakları şemasını değil, veri ve iş sorumluluğunu da yansıtmalıdır.

Agent'a departmandaki bütün araçları vermek

Bir aracın departmanda bulunması, her space agent'ının onu kullanması gerektiği anlamına gelmez. Aracı iş amacına göre bağlayın.

Onayı yalnızca kullanıcı rolü olarak düşünmek

Bir kullanıcının yönetici olması, her yüksek etkili aksiyonun otomatik uygulanması gerektiği anlamına gelmez. Kritik işlemlerde workflow içindeki açık onay kapısını kullanın.

Sonraki adımlar

Departmanınızın ortak bilgisini hazırlayın: Belge Yükleme ve Bilgi Tabanı
Space'e özel model veya agent yapılandırmasını öğrenin: Model / Ajan Oluşturma
Agent ve tekrarlanan süreç ilişkisini inceleyin: Workflow ve Space Agent
Harici model kullanımında hassas veriyi koruyun: LLM Secure Gateway