Yazılım Devreye Alma ve Geri Dönüş Planı Nasıl Kurulur

Devreye alma, yazılımın hazır olup olmadığı sorusunun değil, işletmenin o gün nasıl çalışacağı sorusunun cevabıdır. İyi bir geçiş planı üç şeyi önceden yazar: hangi biçimde geçileceğini, geçiş günü kimin neyi onaylayacağını ve hangi eşikte geri dönüleceğini.

Aşağıda geçiş biçimlerini, takvim seçimini, dondurma kararını, geri dönüş planının içeriğini ve ilk haftada izlenecek kontrolleri ele alıyoruz. Verinin nasıl taşındığı ayrı bir konu; burada geçiş anına odaklanıyoruz.

Geçiş biçimi: hepsi birden, aşamalı ya da paralel

Üç temel yol vardır ve hiçbiri diğerinden mutlak olarak iyi değildir; her biri farklı bir maliyeti farklı bir riskle takas eder.

Hepsi birden (big bang): Belirlenen anda eski sistem kapanır, yeni sistem açılır. En kısa geçiş ve en düşük toplam emek budur; iki sistemi aynı anda besleme derdi yoktur. Karşılığında risk tek bir güne yığılır: o gün çıkan aksaklık doğrudan işletmenin tamamını etkiler.

Aşamalı: Modül modül ya da şube şube geçilir; önce stok ve ürün yönetimi, sonra satış, en sonunda raporlama devreye alınabilir. Risk bölünür ve ilk aşamada öğrenilen her şey sonrakine girdi olur. Maliyeti, geçiş süresince iki sistemin bir arada yaşaması ve aradaki veri alışverişinin bir süre ayakta tutulmasıdır.

Paralel çalışma: Bir süre aynı işlemler iki sisteme de girilir ve sonuçlar karşılaştırılır. Doğruluk açısından en güvenli yoldur, çünkü yeni sistemin sayıları eskisiyle birebir sınanır. Buna karşılık en pahalıdır: kullanıcı aynı işi iki kez yapar. Bu yüzden genellikle bütün sistem için değil, para ve stok gibi kritik birkaç akış için ve kısa bir pencerede uygulanır.

• Tek lokasyonlu ve sade akışlı işletmelerde hepsi birden değerlendirilebilir.
• Çok şubeli ya da çok modüllü yapıda aşamalı geçiş riski belirgin biçimde azaltır.
• Yanlış sayının maliyeti çok yüksekse paralel çalışma yalnızca o akış için düşünülür.
• Hangi yol seçilirse gerekçesiyle yazılır; geçiş günü tartışılacak bir konu olmamalıdır.

Takvim penceresi seçimi

Geçiş tarihi teknik değil operasyonel bir karardır. Yazılım hazır olduğu gün geçilmez; işletmenin en az yoğun olduğu gün geçilir. Kaçınılacak dönemler bellidir: ay sonu ve dönem kapanışı, kampanya ve yoğun satış dönemleri, yıl sonu sayımı, izinlerin yoğunlaştığı haftalar, ekibin ulaşılamayacağı tatil günleri.

Geçişi cuma akşamına koymak hafta sonu boşluğu sağladığı için işe yarar; ama hafta sonu kimin ulaşılabilir olacağı yazılı değilse bu avantaj kayba dönüşür. Geçişten sonraki ilk iki hafta da destek verilebilecek, kritik yükün binmediği bir dönem olmalıdır.

Dondurma kararı: kod ve veri

Kod dondurma, belirlenen tarihten sonra yeni özellik eklenmemesi demektir; yalnızca kabul testinde çıkan durdurucu hatalar düzeltilir. Gerekçesi basittir: geçişe girecek sürüm, test edilmiş sürüm olmalıdır. Geçişten iki gün önce eklenen "küçük bir özellik", test edilmemiş bir değişiklikle canlıya çıkmak anlamına gelir.

Veri dondurma ise son aktarım öncesinde eski sistemde kayıt girişinin durdurulduğu penceredir. Pencere uzadıkça aktarım rahatlar, operasyon zorlaşır; kısaldıkça tersi olur. Süre gerçekçi tutulur ve "bu saatten sonra eski sisteme giriş yapılmayacak" bilgisi saat verilerek herkese duyurulur.

Açık işler nasıl taşınır

Geçiş anında işletmenin yarı yolda kalmış işleri vardır ve bunlar planın en çok ihmal edilen kısmıdır. Her tür için önceden karar verilir.

• Bekleyen siparişler: Yeni sisteme mi aktarılacak, yoksa eskide kapatılıp yenide yalnızca bakiyesi mi görünecek?
• Açık teklifler: Geçerliliği süren teklifler taşınır mı, yoksa yeniden mi oluşturulur?
• Yarım sayımlar: Devam eden bir sayım varsa geçişten önce kapatılması neredeyse her zaman daha basittir.
• Yolda olan sevkiyatlar: Hangi sistemde kapanacağı ve stok etkisinin nerede oluşacağı netleşmelidir.
• Açık cari bakiyeler: Devir bakiyesi olarak mı gelecek, hareket detayıyla mı taşınacak?

Yazılı karar olmadığında kullanıcılar kendi başlarına farklı yollar seçer ve iki hafta sonra hiçbir rapor tutmaz.

Geri dönüş planı yazılı olmalı

Geri dönüş planı başarısızlık beklentisi değil, geçişin sigortasıdır. Yazılı olmadığında bir şey ters gittiğinde kimse karar veremez ve en sonunda kötü bir karar alelacele verilir. Planın cevaplaması gereken sorular şunlardır.

Hangi eşikte geri dönülür? Bu eşik duyguyla değil önceden yazılmış ölçütle belirlenir: belirlenen süre içinde sipariş girişinin hiç yapılamaması, para ya da stok hesabının yanlış üretildiğinin görülmesi, kullanıcıların çoğunluğunun sisteme girememesi gibi. Kararı kim verir? Tek bir isim yazılır; komite geçiş gününde karar veremez. Teknik olarak nasıl yapılır? Eski sistem hangi anda yeniden yazılabilir hâle getirilir, hangi adımlarla ve ne kadar sürede?

En kritik soru ise şudur: geri dönülürse yeni sistemde girilen kayıtlar ne olacak? Geçişten sonra birkaç saat boyunca yeni sisteme veri girilmiştir; bunların eski sisteme nasıl taşınacağı ya da elle yeniden girileceği baştan kararlaştırılmalıdır. Pratik önlem, geçiş gününde girilen belgelerin ayrı bir listesinin tutulmasıdır. Bu sorunun cevabı yoksa geri dönüş planı aslında yok demektir.

Geçiş günü ekip ve iletişim düzeni

Geçiş günü, herkesin aynı anda her yere baktığı bir gün olmamalıdır. Roller önceden dağıtılır ve tek bir koordinasyon noktası belirlenir.

1. Her modül için bir doğrulama sorumlusu atanır; belirlenmiş birkaç kontrolü yapıp "tamam" ya da "sorun var" der.
2. Tek bir iletişim kanalı açılır; bulgular dağınık mesajlarla değil o kanaldan bildirilir.
3. Geri dönüş kararını verecek kişi gün boyu ulaşılabilir olur.
4. Geliştiren taraftan kimin hangi saatlerde hazır olduğu yazılı olur.
5. Saat saat bir kontrol listesi yürütülür; her adımın bittiği kanala yazılır.
6. Kullanıcılara ne zaman giriş yapacakları saat verilerek, tek kaynaktan duyurulur.

İlk gün ve ilk hafta kontrolleri

Geçişin başarılı sayılması sistemin açılmasıyla değil sayıların tutmasıyla olur. İzlenecek kontroller önceden listelenir ve bilinen bir referansla karşılaştırılır.

• İşlem hacmi: Girilen sipariş, teklif ve sevk sayısı normal bir günün seviyesinde mi? Belirgin düşüş, bir akışın tıkandığının ilk işaretidir.
• Hata kayıtları: Tekrarlayan aynı hata, tek seferlik hatadan daha önemlidir.
• Entegrasyon kuyruğu: Dış sistemlere giden mesajların bekleyen sayısı kontrol edilir; birikiyorsa bir şey akmıyor demektir.
• Yavaş işlemler: Hangi ekran ve raporların uzun sürdüğü kaydedilir; ilk günün yükü gerçek yük profilini gösterir.
• Para ve stok mutabakatı: Gün sonunda birkaç cari bakiyesi ve birkaç kalemin stoğu elle doğrulanır.
• Kullanıcı soruları: Aynı sorunun çok tekrarlanması eğitim ya da arayüz eksiğini gösterir.

Eğitim ve kullanım notları geçişten önce hazır olur

Geçiş günü eğitim yapılmaz. Kullanıcı ilk kez o gün sistemi görüyorsa, çıkan aksaklığın yazılım hatası mı kullanım hatası mı olduğu ayırt edilemez. Eğitim geçişten önce, test ortamında ve gerçek senaryolarla yapılır; yanına her rol için bir sayfayı geçmeyen kısa kullanım notları konur, çünkü uzun el kitapları geçiş gününde okunmaz. Her vardiya için "soru sorulacak kişi" belirlenir; kullanıcının kime döneceğini bilmesi aksaklığın bulguya dönüşmesini sağlar.

Eski sistem salt-okunur kalır

Geçişten sonra eski sistem kapatılmaz, salt-okunur hâle getirilir. Birincisi geçmişe dönük sorgulara bir süre ihtiyaç duyulur: eski bir belgeyi görmek, bir mutabakatı karşılaştırmak, aktarımda eksik gelen bir alanı kontrol etmek gerekir. İkincisi ve daha önemlisi, yazma yetkisi açık kalırsa bazı kullanıcılar alışkanlıkla eski sisteme kayıt girmeye devam eder; o kayıtlar hiçbir yere akmaz ve haftalar sonra fark edilir.

Ne kadar süre erişilebilir kalacağı baştan kararlaştırılır ve duyurulur. Erişimin kapatılacağı tarihte sistemin silinmesi gerekmez; erişim kesilir, arşiv kopyası ve gerekli raporların dışa alınmış hâli saklanır. Genellikle sınırlı sayıda kişiye okuma yetkisi yeterlidir.

Özet

• Geçiş biçimi (hepsi birden, aşamalı, paralel) gerekçesiyle önceden seçilir.
• Tarih en az yoğun pencereye alınır; ay sonu ve kampanya dönemine denk getirilmez.
• Kod ve veri dondurma tarihleri yazılır ve saat verilerek duyurulur.
• Bekleyen sipariş, açık teklif ve yarım sayım için ayrı karar alınır.
• Geri dönüş planı yazılıdır: eşik, karar verecek kişi, teknik adımlar ve ara kayıtların akıbeti.
• Geçiş günü roller dağıtılır, tek iletişim kanalı ve saatli kontrol listesi kullanılır.
• İlk gün ve ilk hafta için izlenecek sayılar önceden belirlenir.
• Eğitim ve kısa kullanım notları geçişten önce tamamlanır.
• Eski sistem salt-okunur bırakılır ve erişim süresi duyurulur.

KAV Yazılım, geliştirdiği özel yazılımların devreye alınmasını bu plan üzerinden yürütür: geçiş biçimi, kontrol listesi ve geri dönüş eşikleri geçişten önce yazılır.