Site Yönetim Yazılımına Geçiş: 30 Günlük Uygulama Planı

Site yönetim yazılımına geçiş, eski listedeki verileri yeni sisteme kopyalamaktan ibaret değildir. Güvenli bir geçiş; kapsamın yazılı hale getirilmesi, verinin temizlenmesi, pilot aktarımın yapılması, kayıt ve bakiye mutabakatının tamamlanması, rollerin test edilmesi, kullanıcıların eğitilmesi ve geri dönüş koşulları belirlenmiş bir canlıya alma planı gerektirir.

Bu rehber, seçilmiş bir sistemi 30 günlük karar noktalarıyla devreye almak için uygulanabilir bir çerçeve sunar. Amaç “30. günde ne olursa olsun açmak” değil; her aşamayı ölçülebilir bir çıktı ve onayla kapatmaktır. Veri hacmi, portföy büyüklüğü, entegrasyonlar ve ekip kapasitesi daha uzun bir takvim gerektiriyorsa süreyi uzatın; kontrol adımlarını atlamayın.

Kısa cevap: 30 günlük geçiş nasıl planlanır?

İlk 3 günde kapsamı ve başarı ölçütlerini belirleyin. 4–10. günlerde kaynak veriyi envanterleyip temizleyin ve alan eşleştirmesini onaylayın. 11–18. günlerde pilot aktarım ile kayıt sayısı ve bakiye mutabakatı yapın. 19–27. günlerde gerçek süreçleri, yetkileri, eğitimi ve son provayı tamamlayın. 28–30. günlerde değişiklikleri kontrollü biçimde dondurup canlıya alın, kritik göstergeleri izleyin ve kabul tutanağını kapatın.

Dönem	Ana iş	Zorunlu çıktı	Karar kapısı
Gün 1–3	Kapsam ve sahiplik	Geçiş sözlüğü, sorumlular, başarı ölçütleri	G1: Kapsam onayı
Gün 4–10	Veri hazırlığı	Temiz kaynak dosyalar, alan eşleştirme tablosu	G2: Veri seti onayı
Gün 11–18	Pilot ve mutabakat	Test aktarımı, fark listesi, düzeltme kaydı	G3: Mutabakat onayı
Gün 19–27	Süreç, rol, eğitim ve prova	Test sonuçları, eğitim kaydı, geri dönüş planı	G4: Devam / dur kararı
Gün 28–30	Canlıya alma ve yakın izleme	Kontrol raporu, açık hata listesi, kabul kaydı	G5: Kabul onayı

Başlamadan önce: Seçim ile uygulamayı ayırın

Bu plan, ürün seçimi tamamlandıktan sonra başlar. Henüz finans, operasyon, sakin deneyimi, raporlama ve güvenlik kriterlerini karşılaştırıyorsanız önce site yönetim programı seçerken dikkat edilmesi gerekenleri değerlendirin. Seçim aşamasındaki “hangi özellik var?” sorusu ile uygulamadaki “hangi veri, kim tarafından, hangi kabul ölçütüyle taşınacak?” sorusu birbirine karıştırılmamalıdır.

Geçiş lideri tek bir kişi olmalı; ancak finans, operasyon, yönetim kurulu, bilgi güvenliği ve yazılım sağlayıcısının sorumlulukları ayrı yazılmalıdır. Her işin bir sahibi, teslim tarihi ve kabul eden kişisi yoksa sorunlar “ekibin işi” olarak kalır ve canlıya alma gününde sahipsizleşir.

Gün 1–3: Kapsamı, sahipleri ve başarı ölçütlerini belirleyin

İlk üç günün çıktısı bir toplantı notu değil, onaylanabilir bir geçiş kapsamıdır. Hangi site veya blokların ilk dalgada olduğu; hangi dönemlerin, kullanıcıların ve süreçlerin taşınacağı; eski sistemin ne zaman yalnızca okunur hale geleceği açıkça yazılmalıdır.

Kapsam belgesinde bulunması gerekenler

• Geçiş birimi: Site, blok, bağımsız bölüm ve yönetim dönemi sınırı.
• Taşınacak veri: Bağımsız bölümler, malik ve sakin ilişkileri, açılış bakiyeleri, açık borçlar, tahsilatlar, tedarikçi carileri, sözleşmeler, açık talepler ve aktif kullanıcılar.
• Taşınmayacak veri: Kullanılmayan kopyalar, süresi dolmuş ve taşınması gerekmeyen dosyalar, doğrulanamayan notlar ve kişisel cihazlardaki kontrolsüz arşivler.
• Kesinti yaklaşımı: Kaynak sistemin hangi saatte dondurulacağı ve son farkların nasıl alınacağı.
• Geri dönüş tetikleri: Kabul edilebilir hata sınırının aşılması, kritik bakiye farkı, rol ihlali veya temel sürecin çalışmaması halinde kimin “dur” diyeceği.

Başarı ölçütlerini sayısallaştırın

“Veriler aktarıldı” tek başına kabul ölçütü değildir. Kaynak ve hedef bağımsız bölüm sayısı eşit mi? Açılış bakiyelerinin toplamı kaynak toplamla uyuşuyor mu? Örneklenen dairelerde borç ve ödeme geçmişi doğru mu? Finans rolü yalnızca yetkili olduğu siteyi görebiliyor mu? Bir talep açılıp sorumluya atanabiliyor ve kanıtla kapatılabiliyor mu? Her sorunun hedef değeri ile kontrol yöntemi yazılmalıdır.

Gün 4–7: Kaynak veriyi envanterleyin ve temizleyin

Yeni sistem, eski verideki hataları kendiliğinden düzeltmez. Excel dosyaları, banka ekstreleri, önceki yazılım dışa aktarımları, karar ve sözleşme klasörleri ile kişisel cihazlarda tutulan listeler tek envanterde toplanmalıdır. Yönetimin mevcut kayıt düzenini kurmak için hazırlanan apartman ve site yöneticisinin tutması gereken kayıtlar rehberi, taşınacak kayıt gruplarını ayırmak için kullanılabilir.

Veri grubu	Kaynak sahibi	Temizlik kontrolü	Kabul kanıtı
Site, blok, bağımsız bölüm	Yönetim	Mükerrer ve eksik kodlar	Onaylı yapı listesi
Malik, kiracı, sakin ilişkisi	Yönetim / iletişim	Güncellik, tekrar, gereksiz alan	Örneklem ve toplam kayıt
Açılış bakiyesi ve açık borç	Finans	Dönem, işaret, para birimi, açıklama	Toplam ve daire bazlı mutabakat
Tedarikçi ve sözleşme	Operasyon / finans	Aktiflik, unvan, geçerlilik	Aktif sözleşme listesi
Açık talep ve işler	Operasyon	Durum, öncelik, sorumlu	Açık iş listesi
Kullanıcı ve rol	Yönetim / güvenlik	Aktif hesap ve görev kapsamı	Onaylı yetki matrisi

Bir kişiye ait birden fazla telefon veya e-posta kaydı varsa hangisinin güncel olduğunu tahmin etmeyin; doğrulama durumu için ayrı alan kullanın. Serbest metinlerde yer alan kimlik, sağlık veya aile bilgileri gibi geçiş amacıyla ilgisiz verileri de “nasıl olsa arşiv” diyerek taşımayın.

Gün 8–10: Alan eşleştirmesini ve veri kararlarını onaylayın

Kaynak dosyadaki her sütunun hedef sistemde nereye gideceğini gösteren bir alan eşleştirme tablosu hazırlayın. Örneğin “Daire” alanı kaynaklarda A-12, Blok A / 12 veya 12A biçiminde yazılmış olabilir. Hedef kod standardı, dönüşüm kuralı ve boş değer davranışı belirlenmeden aktarım yapılmamalıdır.

• Kaynak alan, hedef alan, veri tipi ve zorunluluk bilgisi.
• Kod ve tarih biçimi dönüşüm kuralları.
• Mükerrer kayıt birleştirme yöntemi.
• Eksik değerde işlemin durup durmayacağı.
• Taşınmayacak alanın gerekçesi.
• Kontrol için kaynak kayıt sayısı ve dosya özeti.

Kişisel veriler açısından bu aşama, “elde ne varsa taşıma” yaklaşımını sınırlar. Kişisel Verileri Koruma Kurumu, verilerin belirli ve meşru amaçlarla; amaçla bağlantılı, sınırlı ve ölçülü işlenmesini, gerektiğinde güncel tutulmasını ve gerekli süre kadar saklanmasını temel ilkeler arasında sayar. Bu nedenle veri setini, geçişin amacı ve saklama politikasıyla birlikte değerlendirin; somut hukuki yükümlülüklerinizi uzmanınızla doğrulayın.

Gün 11–14: Pilot aktarımı gerçekçi bir örneklemle yapın

Pilot için yalnızca en temiz binayı seçmek yanlış güven oluşturabilir. Farklı borç durumları, malik-kiracı değişimi, birden fazla iletişim kaydı, açık talep ve farklı kullanıcı rollerini içeren temsilî bir site veya blok seçin. Pilot ortamı canlı kullanıcıları etkilememeli ve test verisine erişim sınırlandırılmalıdır.

Aktarımdan önce kaynak dosyaların tarihini, sürümünü, kayıt sayısını ve mümkünse bütünlük özetini kaydedin. Aktarımdan sonra yalnızca toplam satır sayısına bakmayın; ilişki kayıtlarını da sınayın. Bir bağımsız bölüm doğru kişiye, doğru döneme, doğru açık bakiyeye ve doğru site kapsamına bağlı mı? Sorun bulunduğunda kaynak veri hatası, eşleştirme kuralı veya aktarım hatası olarak sınıflandırın.

Gün 15–18: Kayıt ve bakiye mutabakatını kapatın

Finansal veride mutabakat iki düzeyde yapılmalıdır: toplam kontrol ve örnek kayıt kontrolü. Kaynak sistemdeki toplam açılış bakiyesi hedef sistemle uyuşsa bile tek bir dairenin borcu başka daireye bağlanmış olabilir. Bu nedenle toplam, dönem ve daire düzeyi birlikte incelenmelidir.

site aidat takibi rehberindeki karar, tahakkuk, tahsilat, banka hareketi ve cari hesap ayrımı geçiş testine de uygulanabilir. Açık borç; ödeme geçmişi, tahsilat veya banka hareketiyle aynı şey değildir. Hangi verinin açılış bakiyesi, hangisinin geçmiş işlem ve hangisinin yalnızca belge olduğu netleştirilmelidir.

G3 mutabakat onayı için asgari kontrol

• Site, blok ve bağımsız bölüm toplamları kaynakla eşit.
• Aktif malik, kiracı ve sakin ilişkilerinde mükerrerlik sınır içinde.
• Açılış bakiyesi toplamı ile dönem ve örnek daire kontrolleri uyumlu.
• Açık taleplerin durum, öncelik ve sorumluları korunmuş.
• Dosya ve eklerde örnek açma testi başarılı.
• Bulunan tüm farkların sahibi, kararı ve yeniden test sonucu kayıtlı.

Kritik bakiye farkı veya açıklanamayan ilişki hatası varsa takvimi korumak için onay vermeyin. Hatanın etkisini sınırlandırın, kuralı düzeltin, pilotu yeniden çalıştırın ve önceki sonuçla karşılaştırın.

Gün 19–21: Günlük süreçleri uçtan uca test edin

Veri doğru görünse bile günlük iş akışı çalışmıyorsa geçiş tamamlanmış sayılmaz. Finans ekibi için dönemsel aidat planı ve kontrollü toplu borç senaryosu; operasyon için sakin talebinden atama ve kapanışa uzanan senaryo; yönetim için rapor ve kayıt izleme senaryosu çalıştırın.

Arıza operasyonunda örnek bir kaydı uçtan uca sınamak için sakin talebinden iş emrine arıza yönetimi akışını temel alabilirsiniz. Bir talebin kategori, öncelik, durum, görsel ve sorumlu bilgileriyle izlenmesi; gerekiyorsa iş emrine dönüşmesi ve doğrulanmış kapanışa ulaşması test edilmelidir.

Gün 22–24: Yetkileri sınayın ve role göre eğitim verin

Tek bir “sistem eğitimi” oturumu yeterli değildir. Finans kullanıcısı, saha yöneticisi, yönetim kurulu ve destek ekibi farklı görevleri ve riskleri görür. Eğitimleri role göre ayırın; her grubun en sık yaptığı üç işi kendi hesabıyla tamamlamasını isteyin.

• Yönetim: Kapsam, onay, rapor ve istisna takibi.
• Finans: Tahakkuk, tahsilat, açık bakiye ve mutabakat.
• Operasyon: Talep, öncelik, atama, görsel kanıt ve kapanış.
• Yetki yöneticisi: Kullanıcı açma, rol verme, site kapsamı ve hesap kapatma.
• Destek: Sorun kaydı, önem derecesi, cevap ve çözüm kanıtı.

Rol testi yalnızca kullanıcının görebildiği ekranları değil, görmemesi gereken site ve işlemleri de kapsamalıdır. Ayrılan personelin hesabı, görev değişikliği ve geçici vekâlet senaryolarını da sınayın. Kişisel Veri Güvenliği Rehberi; yetki matrisi, yetki kontrolü, erişim ve log kayıtları, kullanıcı hesabı yönetimi, veri maskeleme ve yedeklemeyi teknik tedbir örnekleri arasında gösterir.

Gün 25–27: Son provayı ve geri dönüş planını tamamlayın

Son prova canlıya alma gününün saat saat tekrarıdır. Kaynak sistemin dondurulması, son fark verisinin alınması, aktarım, otomatik ve manuel kontroller, kullanıcı açılışı, ilk duyuru ve destek kanalının devreye girmesi sırayla uygulanmalıdır. Her adımın tahmini değil ölçülmüş süresini kaydedin.

Geri dönüş planı “yedek var” cümlesinden daha ayrıntılı olmalıdır. Hangi hata geri dönüşü tetikler? Kararı kim verir? Kaynak sistem yeniden ne kadar sürede kullanılabilir? Canlıya alma sırasında oluşan yeni kayıtlar nasıl korunur? Kullanıcılara hangi kanaldan bilgi verilir? Microsoft’un güncel veri geçişi belgeleri de canlıya geçişte zamanlama, iletişim, doğrulama, geri dönüş stratejisi ve canlı sonrası izlemenin birlikte planlanmasını önerir.

G4 devam / dur kontrolü

Kontrol	Devam koşulu	Durma örneği
Finans	Onaylı toplam ve örneklem mutabakatı	Açıklanamayan kritik bakiye farkı
Veri	Zorunlu kayıt ve ilişkiler tamam	Bağımsız bölüm–sakin ilişkisi bozuk
Yetki	Rol ve site kapsamı testleri geçti	Yetkisiz site veya veri görünümü
Operasyon	Temel senaryolar uçtan uca çalıştı	Talep, tahakkuk veya rapor akışı kesik
Geri dönüş	Tetik, sorumlu ve süre prova edildi	Kaynak sisteme güvenli dönüş belirsiz

Gün 28–30: Kontrollü canlıya alın ve yakın izleyin

Canlıya alma öncesinde kaynak sistemde değişiklik penceresini başlatın; son fark kayıtlarını alın ve onaylı aktarım paketini çalıştırın. Otomatik kontroller tamamlandıktan sonra finans, operasyon ve yetki sahipleri kendi kabul senaryolarını tekrar etmelidir. Kullanıcılara yalnızca “sistem açıldı” mesajı göndermek yerine giriş adresi, ilk yapılacak işlem, destek kanalı ve eski sistemin erişim durumunu açıklayın.

İlk 48–72 saatte hata ve soru kayıtlarını tek kuyrukta toplayın. Kritik, yüksek, normal ve eğitim ihtiyacı olarak sınıflandırın. Geçici çözüm ile kalıcı düzeltmeyi ayırın. Canlıya alma sırasında fark edilen her veri düzeltmesinin kim tarafından, hangi kaynağa dayanarak ve ne zaman yapıldığını kayıt altına alın.

G5 kabul kaydında ne bulunmalı?

• Kaynak ve hedef kayıt sayılarının son karşılaştırması.
• Finansal toplamların ve seçilen örneklerin onayı.
• Temel iş akışı ile rol testlerinin sonucu.
• Açık hataların önemi, sahibi ve hedef tarihi.
• Eski sistemin okunur erişim ve kapatma planı.
• Yönetim, finans, operasyon ve sağlayıcı temsilcilerinin kabul kararı.

Liyova’da geçiş kapsamını ürün süreçleriyle eşleştirin

Çoklu site yöneten ekipler, ilk dalgayı seçerken portföy görünürlüğü ve merkezi personel/yetki ihtiyacını Liyova yönetim şirketleri çözümü üzerinden değerlendirebilir. Tek seferde tüm portföyü açmak yerine temsilî bir siteyle pilot yapmak; ortak kodları, sorumlulukları ve istisnaları görmeyi kolaylaştırır.

• Aidat ve tahakkuk: Dönemsel plan, toplu borç, daire bazlı açık borç ve izlenebilir işlem geçmişi için finans senaryoları.
• Talepler: Kategori, öncelik, durum, görsel kayıt ve iş emrine dönüşüm için operasyon senaryoları.
• Yetki ve rol yönetimi: Rol şablonu, yetki matrisi, site kapsamı ve işlem kaydı bağlantısı için erişim senaryoları.

Bu özellikler bir geçişin kendiliğinden doğru olacağını garanti etmez; doğru veri, onaylı kurallar ve sorumlu ekip yine gereklidir. Liyova ekibiyle kapsamınızı, pilot dalganızı ve doğrulama ölçütlerinizi birlikte değerlendirmek için demo talebi oluşturun.

Sık yapılan geçiş hataları

1. Kirli veriyi aynen taşımak: Mükerrer ve güncelliği belirsiz kayıtlar yeni sistemde daha görünür ama daha doğru olmaz.
2. Yalnızca toplam bakiyeyi kontrol etmek: Toplam eşitken daire eşleşmeleri yanlış olabilir.
3. En kolay veriyi pilot seçmek: Gerçek hayattaki istisnaları görmeyen pilot yanıltır.
4. Eğitimi canlıya alma sonrasına bırakmak: İlk gün hatalarının bir kısmı ürün değil kullanım ve rol belirsizliğinden doğar.
5. Geri dönüşü yalnızca teknik yedek sanmak: Karar yetkisi, iletişim ve yeni kayıtların korunması da planlanmalıdır.
6. Tüm portföyü tek seferde açmak: Küçük bir kural hatası bütün sitelere yayılabilir.
7. Eski hesapları açık bırakmak: Ayrılan personel ve geçici erişimler canlıya alma günü tekrar kontrol edilmelidir.

Sık sorulan sorular

Site yönetim programı kurulumu gerçekten 30 gün sürer mi?

30 gün örnek bir uygulama çerçevesidir. Küçük ve temiz veri seti daha kısa sürebilir; çoklu portföy, yüksek veri hacmi, banka/ödeme entegrasyonu veya karmaşık yetkiler daha uzun süre gerektirebilir. Süre yerine onay kapılarını sabit tutun.

Geçmişteki bütün işlemler taşınmalı mı?

Hayır. Operasyonel ihtiyaç, saklama yükümlülüğü, erişim amacı ve veri kalitesi birlikte değerlendirilmelidir. Taşınmayan geçmiş kayıtların nerede, ne kadar süreyle ve kimlerin erişiminde korunacağı ayrıca planlanmalıdır.

Yalnızca açılış bakiyesi taşımak yeterli mi?

Bu, yönetimin raporlama ve denetim ihtiyacına bağlıdır. Açılış bakiyesi günlük başlangıç için yeterli olabilir; ancak kaynağın nasıl oluştuğu, geçmiş belgelerin nerede tutulduğu ve itiraz halinde hangi kayda erişileceği belirlenmelidir.

Canlıya alma sırasında eski sistem kapatılmalı mı?

Çift kayıt riskini önlemek için bir değişiklik dondurma penceresi gerekir. Eski sistemin hemen tamamen kapatılması şart değildir; belirli süre yalnızca okunur erişimle korunabilir. Süre ve erişim yetkisi yazılı olmalıdır.

Geçiş başarısı hangi göstergelerle izlenir?

Kayıt eşitliği, bakiye mutabakatı, başarısız işlem sayısı, kritik açık hata, yetki testi, destek talebi çözüm süresi ve temel işlemleri tamamlayan kullanıcı oranı birlikte izlenebilir. Yalnızca giriş yapan kullanıcı sayısı başarıyı göstermez.

Veri aktarımını kim onaylamalı?

Teknik ekip aktarımı çalıştırabilir; ancak finansal veriyi finans sorumlusu, operasyon kayıtlarını ilgili süreç sahibi, yetki matrisini yönetim ve güvenlik sorumlusu onaylamalıdır. Nihai kabul, bu alan onaylarını birleştiren geçiş lideri ve yetkili yönetim tarafından verilmelidir.