Çoklu Site Yönetiminde Ortak Operasyon Standardı Nasıl Kurulur?

Çoklu site yönetim programı, farklı yapıların verisini tek panelde gösterebilir; ancak ortak operasyon standardını kendiliğinden oluşturmaz. Standart için portföy genelinde aynı anlamı taşıyan veri alanları, durum adları, sorumluluklar, onay kuralları ve rapor tanımları gerekir. Her sitenin yönetim planı, sözleşmesi, bütçe dönemi ve hizmet kapsamı gibi yerel farkları ise ayrıca, açık ve onaylı biçimde tutulmalıdır.

Kısa karar kuralı şöyledir: Ortak olanı merkezde tanımlayın, yerel farkı site kapsamında kaydedin, istisnayı sahipsiz bırakmayın. Böylece merkez ekip farklı siteleri karşılaştırabilir; saha ekibi de kendi yapısının gerçek koşullarını ortak şablona zorla uydurmak zorunda kalmaz.

Tek panel ile ortak operasyon standardı arasındaki fark nedir?

Tek panel bir erişim ve görünürlük özelliğidir. Ortak operasyon standardı ise işin nasıl adlandırılacağını, kim tarafından hangi kapsamda yürütüleceğini, ne zaman tamamlanmış sayılacağını ve hangi veriyle raporlanacağını belirleyen işletim modelidir.

Örneğin bütün sitelerde “teknik talep” kaydı açılabilir. Fakat bir ekip talebi teknisyene atandığında, diğeri yalnızca telefon edildiğinde “işlemde” olarak işaretliyorsa iki sitenin çözüm süresi karşılaştırılamaz. Aynı ekran kullanılsa bile durumların anlamı farklıdır. Bu nedenle yazılımdan önce veya yazılımla birlikte ortak durum sözlüğü ve kapanış ölçütü kurulmalıdır.

Katman	Tek panelin sağladığı	Operasyon standardının yanıtladığı
Erişim	Siteler arasında geçiş	Hangi rol hangi site ve işlemi görebilir?
Süreç	Talep veya işlem listesi	Her durumun girdi, sahibi ve çıkışı nedir?
Veri	Ortak alan ve formlar	Aynı alan her sitede aynı anlamı mı taşır?
Rapor	Özet ekranlar	Gösterge hangi formül ve dönemle hesaplanır?
Kontrol	Kullanıcı ve işlem kaydı	İstisnayı kim, ne zaman, neden onayladı?

Önce ne standartlaştırılmalı, ne yerel kalmalı?

En sık yapılan hata iki uçtan biridir: Her siteyi bütünüyle serbest bırakıp ortak rapor üretmeye çalışmak veya bütün farklılıkları yok sayıp tek prosedürü zorlamak. Daha sağlıklı model, “ortak çekirdek” ve “kontrollü yerel ayar” ayrımıdır.

Portföy genelinde ortak kalması gerekenler

• Site, blok, bağımsız bölüm, sakin, tedarikçi ve varlık gibi temel kayıtların adlandırma ilkeleri.
• Talep, iş emri, tahakkuk, tahsilat, gider ve karar gibi ana kayıt türleri.
• Durumların anlamı; örneğin “atandı”, “kanıt bekleniyor”, “kapandı” ve “iptal edildi”.
• Zorunlu alanlar, belge ve referans kuralları.
• Kritik işlemlerde onay, görev ayrımı ve değişiklik izi.
• Portföy göstergelerinin formülü, dönem sınırı ve veri tazeliği.

Site kapsamında tanımlanması gerekenler

• Yönetim planı, kurul kararları ve hizmet sözleşmesinden doğan yerel süreç farkları.
• Bütçe ve mali dönem, banka/kasa hesapları ve raporlama takvimi.
• Blok, ortak alan, teknik varlık ve tedarikçi yapısı.
• Sahadaki görev dağılımı, vardiya veya dış hizmet modeli.
• Onaylanmış istisnanın nedeni, sahibi, başlangıç ve bitiş tarihi.

Bir yerel farkın yalnızca “bu site böyle çalışıyor” notuyla tutulması yeterli değildir. Hangi ortak kuraldan ayrıldığı, neden gerekli olduğu, kim tarafından onaylandığı ve ne zaman yeniden değerlendirileceği yazılmalıdır. Süresiz istisnalar zamanla görünmez ikinci standartlara dönüşür.

Ortak operasyon standardının 7 katmanı

1. Hizmet kataloğu ve süreç sahipliği

Önce portföyde gerçekten sunulan hizmetleri listeleyin: aidat ve tahsilat, sakin iletişimi, talep yönetimi, teknik bakım, ziyaretçi, tedarikçi, raporlama ve yönetişim gibi. Her hizmet için bir süreç sahibi, sahadaki uygulayıcı, kontrol eden rol ve üretilen çıktı belirleyin.

“Merkez ofis takip eder” ifadesi görev tanımı değildir. Merkez ofiste hangi rolün kuralı yazdığı, site yöneticisinin hangi kararı alabildiği ve saha ekibinin hangi kaydı kapattığı ayrı görünmelidir. Aynı sorumluluğun iki role verilmesi kadar, hiç kimseye verilmemesi de gecikme üretir.

2. Veri sözlüğü ve kod yapısı

Ortak raporun temeli ortak veri dilidir. “Acil”, “gecikmiş”, “açık borç”, “tamamlandı”, “ortak alan” veya “tedarikçi kaynaklı” gibi ifadelerin portföy boyunca tek tanımı olmalıdır. Alanın adı, açıklaması, veri tipi, zorunluluğu, sahibi ve örnek değeri veri sözlüğünde tutulabilir.

Kod yapısı da aynı mantığı izlemelidir. Site, blok, varlık, gider kategorisi ve iş türü kodları benzersiz olmalı; sonradan ad değişse bile geçmiş kayıtla bağ kopmamalıdır. Serbest metin yalnızca açıklama için kullanılmalı, raporlanan ana sınıflar kontrollü listelerden seçilmelidir.

3. Site kartı ve kapsam kaydı

Her site için tek bir kapsam kartı oluşturun. Bu kartta yönetilen bloklar, bağımsız bölüm sayısı, hizmet başlangıcı, sözleşme kapsamı, mali dönem, hesaplar, yönetim organları, sorumlu ekipler, kritik teknik varlıklar ve yerel raporlama takvimi bulunabilir. Amaç bütün belgeleri tek karta kopyalamak değil; ilgili kaynağa ve güncel sürüme ulaşılmasını sağlamaktır.

Kapsam kartı, portföy raporundaki farklılıkları açıklamak için de kullanılır. Örneğin güvenlik hizmeti bir sitede yönetim şirketi personeliyle, diğerinde tedarikçiyle yürütülüyorsa personel performansı iki site arasında aynı payda ile karşılaştırılmamalıdır.

4. Rol ve site kapsamı

Yetkiyi kişi adına göre değil, iş rolü üzerinden kurun; ardından site kapsamını ekleyin. NIST’in güncel rol tabanlı erişim kontrolü tanımı, izin verilen eylemlerin tek tek kişi kimlikleri yerine rollerle ilişkilendirildiği modeli açıklar. Çoklu site bağlamında rol tek başına yeterli değildir: “finans sorumlusu” rolünün hangi sitelerde geçerli olduğu da atanmalıdır.

Rol; görüntüleme, oluşturma, düzenleme, silme, onaylama ve dışa aktarma gibi işlem düzeylerine ayrılmalıdır. Başka siteye doğrudan bağlantı, arama sonucu veya portföy raporundan erişim yolları da test edilmelidir. Uygulanabilir bir örnek için site yönetiminde yetki matrisi rehberini kullanabilirsiniz.

5. Ortak süreç durumları ve kapanış ölçütleri

Her ana süreç için başlangıç, ara durumlar, bekleme nedenleri ve kapanış ölçütü tanımlayın. Talep “kapandı” sayılmadan önce yapılan iş, tarih, sorumlu ve gerekiyorsa fotoğraf ya da belge bulunmalı mı? Tahsilat “eşleşti” sayılmadan banka hareketi ve cari mahsup doğrulanmalı mı? Duyuru “yayımlandı” ile “teslim edildi” ayrımı nasıl okunacak?

Durum sayısını gereksiz yere artırmayın. Her durum farklı bir iş, sorumlu veya rapor anlamı üretmiyorsa sadeleştirin. Serbest notla yönetilen belirsizlikleri ise “bekleme nedeni” veya “istisna türü” gibi kontrollü alanlara dönüştürün.

6. İstisna yönetimi

Standart süreç, normal akışı açıklar; gerçek kaliteyi istisna yönetimi gösterir. Belgesiz gider, açıklamasız banka hareketi, yanlış siteye açılmış talep, hizmet kapsamı dışındaki iş veya süresi aşılmış onay gibi durumlar için ortak istisna kaydı kullanın.

Asgari istisna alanları; site, süreç, kayıt referansı, kategori, etki, neden, sahibi, hedef tarih, son aksiyon ve kapanış kanıtıdır. İstisna kapatıldığında yalnızca “çözüldü” yazmak yerine kaynağın düzeltildiğini doğrulayın. Tekrar eden istisnalar, eğitim veya standart değişikliği ihtiyacını gösterebilir.

7. Portföy raporlama sözlüğü

Aynı başlıklı iki gösterge farklı hesaplanıyorsa portföy karşılaştırması yanıltıcı olur. Her gösterge için ad, iş amacı, formül, pay/payda, dahil edilen ve edilmeyen kayıtlar, dönem, saat dilimi, veri kaynağı, sahibi ve tazelenme zamanı yazılmalıdır.

Örneğin “talep çözüm süresi” ilk kayıttan teknik kapanışa mı, sakinin onayına mı kadar ölçülüyor? Tedarikçi bekleme süresi dahil mi? İptal edilen talepler paydaya giriyor mu? Bu sorular cevaplanmadan siteleri renklerle sıralamak doğru bir yönetim kararı üretmez.

Üç kritik süreç portföy genelinde nasıl çalışmalı?

Finans: yerel hesap, ortak kontrol

Her sitenin bütçesi, banka hesapları ve cari kayıtları ayrı kalmalıdır. Buna karşılık tahakkuk, tahsilat, banka mutabakatı, gider belgesi ve dönem kapanışı için ortak kontrol listesi kullanılabilir. Merkez raporu, site toplamlarını birleştirmeden önce her sitenin dönem ve mutabakat durumunu göstermelidir.

Finans özeti için “gelir”, “tahsilat” ve “tahakkuk” kavramlarının aynı anlamda kullanılması özellikle önemlidir. Kaynak hareketten toplama geri izleme ve kurul soruları için site gelir-gider raporu hazırlama rehberine bakabilirsiniz.

Talep ve iş emri: ortak durum, yerel ekip

Sakin talebi bütün portföyde aynı ana sınıflarla kaydedilebilir; atama ise site, varlık, vardiya ve sözleşmeye göre değişebilir. Aciliyet tanımı, ilk yanıt, görev atama, bekleme nedeni, müdahale kanıtı ve kapanış ölçütü ortak olursa merkez ekip biriken işleri gerçek nedenleriyle görebilir.

Bir sitede dış tedarikçi beklenirken diğerinde iç teknik ekip çalışıyorsa süreleri körlemesine karşılaştırmayın. Hizmet modeli ve bekleme nedeni raporda ayrıştırılmalıdır. Böylece standart, yerel çalışma biçimini gizlemek yerine açıklanabilir kılar.

Raporlama: özetten kaynağa inebilme

Portföy yöneticisi bütün siteleri ortak göstergelerle görmeli; fakat gerektiğinde ilgili site, süreç ve kaynak kayda inebilmelidir. Yalnızca konsolide toplam sunmak, hangi sitenin gerçek istisna ürettiğini saklayabilir. Rapor; normal değer, eşik dışı durum ve veri eksikliği arasında ayrım yapmalıdır.

Çoklu site operasyon standardı 10 adımda nasıl kurulur?

1. Portföy envanterini çıkarın. Siteleri, sözleşme kapsamlarını, ekipleri, hesapları, süreçleri, kullanılan dosya ve sistemleri listeleyin.
2. En kritik üç süreci seçin. Bütün modülleri aynı anda ele almak yerine yüksek hacimli veya yüksek riskli üç akışla başlayın.
3. Mevcut farkları haritalayın. Aynı işin sitelerde hangi adlarla, durumlarla, belgelerle ve sorumlularla yürüdüğünü karşılaştırın.
4. Ortak çekirdeği yazın. Zorunlu kayıt, durum, sahip, onay ve kapanış ölçütlerini belirleyin.
5. Yerel ayar alanlarını ayırın. Sözleşme, dönem, ekip ve yönetim kararından doğan farkları site kartına bağlayın.
6. Rol-kapsam matrisini kurun. Merkez, site ve saha rollerini; modül, işlem ve site düzeyinde test edilebilir hâle getirin.
7. Gösterge sözlüğünü onaylayın. Formül, dönem ve kaynak tanımlanmayan ölçümü portföy raporuna almayın.
8. İki farklı siteyle pilot yapın. Yalnızca en düzenli siteyi değil, hizmet modeli veya veri kalitesi farklı ikinci bir siteyi de seçin.
9. İstisnaları standarda geri besleyin. Pilot sırasında her farkı yeni kural yapmayın; geçici istisna mı, site ayarı mı, ortak standart değişikliği mi olduğuna karar verin.
10. Sürüm ve yönetim ritmini başlatın. Standardın sahibi, yürürlük tarihi, sürümü ve gözden geçirme takvimi belli olsun.

Bu çalışma, yazılım seçimi ve veri taşıma projesinden farklıdır. Sistem henüz seçilmediyse site yönetim programı seçim rehberindeki gerçek senaryolarla adayları sınayın. Seçim tamamlandıysa veriyi, rolü ve kabul ölçütlerini kontrollü devreye almak için 30 günlük geçiş planını operasyon standardıyla eşleştirin.

Yönetim ritmi nasıl kurulmalı?

Standart yalnızca bir prosedür dosyasında kalırsa kısa sürede güncelliğini yitirir. Farklı seviyelerde kısa kontrol ritimleri oluşturun:

• Günlük: Kritik ve süresi yaklaşan istisnalar; sahipsiz kayıtlar; başarısız aktarım veya eşleşme sorunları.
• Haftalık: Açık talepler, iş emirleri, finans istisnaları, geciken onaylar ve site yöneticisi aksiyonları.
• Aylık: Portföy göstergeleri, veri kalitesi, bütçe ve süreç sapmaları; özetten kaynak kayda örnek kontrol.
• Çeyreklik: Rol ve site kapsamı, süresi biten istisnalar, gösterge tanımları ve standart sürümü.

ISO’nun resmî teknik komite sayfasında yayımlanmış olarak yer alan ISO 41001:2018 tesis yönetimi sistemi standardı, tesis yönetiminin organizasyon hedeflerini ve ilgili tarafların ihtiyaçlarını tutarlı biçimde desteklemesine yönelik bir yönetim sistemi çerçevesi sunar. Bu yazı bir ISO uygulama veya belgelendirme rehberi değildir; planla–uygula–kontrol et–iyileştir mantığı, operasyon standardının yaşayan bir sistem olması için yararlı bir referanstır.

Çoklu site yönetim yazılımı demosunda ne test edilmeli?

Özellik listesini değil, kendi portföyünüzden kısa senaryoları çalıştırın:

• Merkez kullanıcısı bütün siteleri görebilirken site yöneticisi yalnızca atanmış kapsamda kalıyor mu?
• Aynı rol iki farklı siteye atanırken yerel yetki istisnası görünür ve süreli tutulabiliyor mu?
• Bir talep ortak statülerle ilerliyor, fakat doğru site ekibine ve varlığa bağlanıyor mu?
• Portföy raporundan ilgili siteye, istisnaya ve kaynak işleme inilebiliyor mu?
• Gösterge filtreleri, dönem ve veri tazelenme zamanı kullanıcıya açık mı?
• Kritik değişiklikte kullanıcı, zaman, kapsam ve işlem referansı görülebiliyor mu?
• Başka siteye ait doğrudan bağlantı, arama ve dışa aktarma erişimi gerçekten engelleniyor mu?
• Yeni site eklenirken ortak şablon ile siteye özel ayarlar birbirinden ayrılabiliyor mu?

Başarıyı “ekran açıldı” diye kabul etmeyin. Örnek kullanıcının izinli işi yapabildiğini ve izinli olmayan siteye ulaşamadığını; rapor toplamının da kaynak kayıtlarla tutarlı olduğunu kanıtlayın.

Liyova çoklu site çalışma modelini nasıl destekler?

Liyova’nın yönetim şirketleri çözümü, birden fazla sitenin finansal ve operasyonel görünümünü ortak yönetim bağlamında ele alır. yetki ve rol yönetimi; rol şablonu, yetki matrisi, site kapsamı ve işlem kaydı bağlantısıyla erişim tasarımını destekler.

Raporlar alanı açık bakiye, tahsilat, talep, iş emri ve yönetim verisini aynı raporlama standardına yaklaştırır. İşlem kayıtları ise kritik adımlarda kullanıcı, zaman, kapsam ve istek bilgisini inceleme bağlamı sunar. Bu araçlar standardın yerini almaz; onaylanmış veri dili, rol modeli ve süreç kurallarının uygulanabilmesi için ortak bir çalışma yüzeyi sağlar.

Demo sırasında portföyünüzden iki farklı site, üç rol ve bir finans/operasyon senaryosu seçin. Liyova’nın bunları site kapsamı, rapor ve işlem iziyle nasıl ele aldığını görmek için demo talebi oluşturabilirsiniz.

Sık sorulan sorular

Her site aynı prosedürü kullanmak zorunda mı?

Hayır. Ortak veri dili, durumlar, kontrol ve rapor tanımları portföy standardı olabilir; yönetim planı, sözleşme, dönem ve hizmet modelinden doğan farklar site kapsamında tutulmalıdır. Önemli olan farkın görünür, gerekçeli ve onaylı olmasıdır.

Konsolide rapor ile site bazlı rapor birlikte mi olmalı?

Evet. Konsolide görünüm portföy eğilimini gösterir; site bazlı görünüm farkın kaynağını açıklar. Özetten siteye ve mümkünse kaynak kayda inilemiyorsa toplam, yönetim aksiyonu için yetersiz kalabilir.

Kaç göstergeyle başlanmalı?

Gösterge sayısından önce karar ihtiyacını belirleyin. Finans, talep/iş emri ve veri kalitesi için az sayıda fakat formülü, sahibi ve aksiyon eşiği tanımlı ölçümle başlamak; çok sayıda belirsiz grafikten daha kullanışlıdır.

Merkez ekip her site verisini görmeli mi?

Otomatik olarak değil. Merkez rolünün görevi, ihtiyaç duyduğu veri ve yapacağı işlem belirlenmeli; erişim site, modül, kayıt ve işlem düzeyinde sınırlandırılmalıdır. Sistem yönetme yetkisi bütün kişisel veya finansal ayrıntıları görme zorunluluğu doğurmaz.

İstisnalar standarttan sapma olarak mı değerlendirilir?

Her istisna hata değildir. Yerel sözleşme veya yapı özelliğinden doğan geçerli fark olabilir. Yine de nedeni, sahibi, onayı ve gözden geçirme tarihi yoksa kontrolsüz sapmaya dönüşür. Tekrar eden istisna, ortak standardın yetersizliğini de gösterebilir.

Standart ne sıklıkla güncellenmeli?

Sabit bir süre bütün portföyler için doğru değildir. Yeni site eklenmesi, sözleşme değişikliği, önemli süreç hatası, yeni rapor ihtiyacı veya rol değişimi takvim dışı inceleme tetiklemelidir. Ayrıca belirli bir çeyreklik veya altı aylık gözden geçirme ritmi kurulabilir.

Sonuç: Çoklu site yönetiminde ölçek, yalnızca daha fazla siteyi aynı ekranda açmak değildir. Ölçeklenebilir model; ortak dili korur, site farkını açıkça tanımlar, rolleri kapsamla sınırlar, istisnaları sahipli hâle getirir ve raporu kaynağa bağlar. Yazılım bu modeli taşıyan araçtır; standardın sahibi ve karar mercii yine yönetim organizasyonudur.