Kurumsal yazılım devreye alma (go-live) kontrol listesi

Devreye alma (go-live), ERP, MES veya kalite yönetim sistemi gibi kurumsal bir yazılımın test ortamından çıkıp işletmenin günlük işini yürüttüğü canlı sisteme dönüştüğü geçiştir. Başarılı bir devreye alma tek bir günün işi değildir; kapsam tanımından destek devrine kadar uzanan bir proje döngüsünün sonucudur.

Bu kontrol listesi, ORELSIS ekibinin OREL MRP, OREL QMS ve OREL DMS gibi kurumsal yazılım projelerinde izlediği çalışma düzenini aşamalar halinde özetler. Liste, hangi yazılımı kurarsanız kurun uyarlanabilecek biçimde yazılmıştır.

Proje tüzüğü, kapsam ve roller

Proje tüzüğü (project charter), projenin neden yapıldığını, neyi kapsadığını, kimin karar verdiğini ve başarının nasıl ölçüleceğini yazan kısa ve onaylı belgedir. Tüzük olmadan başlayan projelerde kapsam sürekli genişler ve kararlar kişilere göre değişir.

Yönlendirme kurulu ve roller

Yönlendirme kurulu (steering committee), kapsam, bütçe ve takvimle ilgili kararları veren üst düzey gruptur. Düzenli toplanır, proje yöneticisinin raporunu dinler ve tıkanan kararları çözer. Rollerin yazılı olması, devreye alma haftasında kimin karar vereceği sorusunu önceden cevaplar.

R: yapan, A: hesap veren, C: danışılan, I: bilgilendirilen. BT ve tedarikçi ekibi ayrı sütunlar olarak da izlenebilir; önemli olan her satırda tek bir hesap verenin olmasıdır. Anahtar kullanıcılar, süreci en iyi bilen ve projeye zamanının anlamlı bir kısmını ayırabilen kişiler arasından seçilmelidir.

Mevcut ve hedef süreç analizi

Mevcut durum (as-is) analizi, işin bugün nasıl yapıldığını; hedef durum (to-be) tasarımı ise yeni sistemle nasıl yapılacağını tanımlar. Amaç bugünkü süreci yazılıma kopyalamak değil, sistemin standart akışıyla iş ihtiyacını buluşturmaktır.

1. 1.Her süreç için sahibi ve anahtar kullanıcıyı belirleyin.
2. 2.Mevcut akışı, kullanılan formları, Excel dosyalarını ve onay adımlarını çıkarın.
3. 3.Sorunları ve iyileştirme beklentilerini sürecin içinde not edin.
4. 4.Yazılımın standart akışını anahtar kullanıcılara canlı olarak gösterin.
5. 5.Hedef akışı çizin ve her farkı (gap) ayrı bir kayıt olarak listeleyin.
6. 6.Her fark için çözüm yolunu seçin: süreç değişikliği, konfigürasyon, rapor veya geliştirme.
7. 7.Hedef süreç belgelerini süreç sahiplerine onaylatın.

Konfigürasyon, özelleştirme ve ortamlar

Konfigürasyon, yazılımın kendi ayarlarıyla (parametre, iş akışı, alan, rapor tanımı) iş ihtiyacına uyarlanmasıdır. Özelleştirme ise koda müdahale eden geliştirmedir. Özelleştirme bazı durumlarda gereklidir, ancak her biri test, bakım ve sürüm yükseltme yükü getirir.

• Önce süreci değiştirmeyi değerlendirin: standart akış işi karşılıyor mu?
• Sonra konfigürasyonu deneyin: parametre, alan veya iş akışı ayarı yeterli mi?
• Rapor veya entegrasyonla çözülebiliyorsa çekirdeğe dokunmayın.
• Özelleştirmeyi yalnızca yasal zorunluluk veya açık iş değeri varsa onaylayın ve gerekçesini yazın.
• Her özelleştirmenin sahibini, test senaryosunu ve belgesini tanımlayın.

Ortamlar

En az üç ayrı ortam önerilir. Geliştirme ortamı konfigürasyon ve geliştirme için, test ortamı entegrasyon ve kabul testleri için, canlı ortam ise günlük iş için kullanılır. Değişiklikler ortamlar arasında yalnızca kayıtlı ve onaylı bir taşıma yöntemiyle aktarılır.

Veri taşıma planı

Veri taşıma, eski sistemlerdeki ana veri ve açık bakiyelerin yeni sisteme kontrollü biçimde aktarılmasıdır. Taşınacak veri; malzeme, ürün ağacı, cari kartlar gibi ana verilerle açık sipariş, stok ve bakiye gibi açılış verilerinden oluşur. Geçmiş işlemlerin taşınıp taşınmayacağı ayrıca kararlaştırılır.

1. 01
   Kapsam ve eşleme

   Taşınacak nesneleri, kaynak sistemi ve alan eşlemesini belirleyin. Her nesne için bir sahip atayın.

2. 02
   Çıkarma (extract)

   Veriyi kaynak sistemden tekrarlanabilir bir yöntemle çıkarın; elle kopyalamaya dayanmayın.

3. 03
   Temizleme (cleanse)

   Tekrarları, eksik alanları ve geçersiz değerleri kaynak sahibiyle birlikte düzeltin. Pasif kayıtları taşıma dışı bırakın.

4. 04
   Dönüştürme ve yükleme (load)

   Veriyi hedef biçime çevirin ve test ortamına yükleyin. Hata veren kayıtları listeleyip düzeltin.

5. 05
   Mutabakat (reconcile)

   Kayıt sayılarını, stok miktarlarını ve bakiye toplamlarını kaynakla karşılaştırın. Farkları açıklayın ve sahibine onaylatın.

6. 06
   Prova

   Tüm taşımayı en az bir kez, gerçek geçiş sırasına ve süresine yakın koşullarda baştan sona prova edin.

Test aşamaları

Test, sistemin hedef süreçleri doğru yürüttüğünü kanıtlama işidir. Her test aşamasının giriş ve çıkış ölçütleri baştan yazılır; böylece bir aşamanın ne zaman bittiği tartışma konusu olmaz.

Eğitim planı

Eğitim, kullanıcının yeni sistemde kendi işini yapabilmesini sağlar. Etkili bir plan iki katmanlıdır: önce anahtar kullanıcılar derinlemesine eğitilir, ardından onlar ve proje ekibi son kullanıcıları rolüne göre eğitir.

• Anahtar kullanıcı eğitimi: Konfigürasyon mantığı, süreç akışı, sık hatalar ve çözüm yolları. Süreç tasarımıyla birlikte başlar.
• Son kullanıcı eğitimi: Role göre, kendi günlük işlemleri üzerinden ve test ortamında. Canlıya yakın bir tarihte verilir.
• Yönetici bilgilendirmesi: Raporlar, onay adımları ve göstergeler.
• Eğitim materyali: Rol bazlı kısa kullanım kılavuzları, ekran görüntülü adım listeleri ve sık sorulan sorular.
• Pratik ortamı: Kullanıcıların eğitim sonrası deneme yapabileceği ayrı bir alan.

Eğitim, değişim yönetiminin yalnızca bir parçasıdır. Kullanıcılara neyin, neden ve ne zaman değişeceğini proje boyunca düzenli olarak anlatın. Yöneticilerin yeni süreci sahiplendiğini göstermesi, anahtar kullanıcıların birimlerinde ilk danışılacak kişi olması ve kullanıcı geri bildirimlerinin görünür biçimde ele alınması, sistemin benimsenmesini doğrudan etkiler.

Geçiş (cutover) planı ve go/no-go kararı

Geçiş planı, eski sistemin kapatılıp yeni sistemin açıldığı dönemde yapılacak her işi saat, sorumlu ve bağımlılıkla birlikte listeleyen ayrıntılı çalışma planıdır. Plan, prova sırasında gerçek sürelerle test edilir ve geri dönüş adımlarını da içerir.

1. 01
   Değişiklik dondurma

   Belirlenen tarihten sonra konfigürasyon ve ana veri değişikliği yalnızca istisna onayıyla yapılır.

2. 02
   İşlem kapanışı

   Eski sistemde açık işlemler kapatılır veya listelenir; son giriş zamanı tüm birimlere duyurulur.

3. 03
   Son veri taşıma

   Açılış stokları, bakiyeler ve açık belgeler canlı ortama yüklenir ve mutabakatı yapılır.

4. 04
   Duman testi (smoke test)

   Kritik süreçler canlı ortamda kısa senaryolarla denenir: giriş, sipariş, üretim kaydı, çıktı ve entegrasyon.

5. 05
   Go/no-go toplantısı

   Yönlendirme kurulu ölçütleri tek tek gözden geçirir ve geçiş veya geri dönüş kararını yazılı verir.

6. 06
   Açılış ve duyuru

   Kullanıcılara erişim açılır, destek kanalları ve iletişim listesi duyurulur.

Geri dönüş planı

Geri dönüş planı, geçiş sırasında ciddi bir sorun çıkarsa eski sisteme nasıl ve hangi noktaya kadar dönüleceğini tanımlar. Plan; eski sistemin hangi tarihe kadar salt okunur ve kullanılabilir tutulacağını, geçiş sırasında girilen verinin nasıl ele alınacağını, kimin karar vereceğini ve kullanıcılara nasıl duyurulacağını içerir. Geri dönüş adımları da prova sırasında en az bir kez denenmelidir.

Hypercare

Hypercare, canlıya geçişin hemen ardından gelen ve proje ekibinin kullanıcılara yoğun destek verdiği dönemdir. Bu dönemde sorunlar hızla toplanır, önceliklendirilir ve çözülür. Süresi, sistemin kapsamına ve ilk dönem kapanışı gibi kritik olaylara göre baştan belirlenir.

• Sahada ve uzaktan erişilebilir bir destek ekibi kurun; anahtar kullanıcılar ilk destek katmanıdır.
• Tüm talepleri tek bir kayıt aracında toplayın; e-posta ve telefonla gelenleri de kaydedin.
• Günlük kısa bir değerlendirme toplantısıyla açık kayıtları gözden geçirin.
• Tekrar eden sorunları eğitim, belge veya konfigürasyon iyileştirmesine çevirin.
• İlk dönem kapanışını (ay sonu, envanter) proje ekibiyle birlikte yapın.

Yanıt süreleri sözleşmeye ve işin kritikliğine göre birlikte belirlenmelidir. Tablodaki ifadeler bir başlangıç çerçevesidir.

Destek devri ve devreye alma sonrası değerlendirme

Hypercare, kararlaştırılan ölçütler karşılandığında sona erer ve sistem kalıcı destek modeline devredilir. Devir bir tarih değil, bir kabul sürecidir: açık kayıtlar, belgeler ve sorumluluklar yazılı olarak teslim edilir.

Devreye alma sonrası değerlendirme, projenin hedeflerine ne ölçüde ulaştığını ve hangi derslerin çıkarıldığını ele alır. Tüzükte yazılan iş hedefleri, canlı veriyle yeniden ölçülür; iyi işleyen uygulamalar ve tekrar edilmemesi gerekenler sonraki projeler için kayda geçirilir.

Sık yapılan hatalar

• Kapsamı yazılı olarak dondurmadan konfigürasyona başlamak.
• Anahtar kullanıcıları günlük işlerinden ayırmadan projeye atamak.
• Bugünkü süreci olduğu gibi kopyalamak için çok sayıda özelleştirme yapmak.
• Veri temizliğini geçişten hemen önceki haftalara bırakmak.
• UAT'yi proje ekibine yaptırmak; süreç sahiplerinin onayını almamak.
• Geçiş provası yapmadan gerçek geçiş süresini tahmin etmek.
• Canlıya geçişi ay sonu veya yoğun sevkiyat dönemiyle çakıştırmak.
• Hypercare'i plansız bırakmak; talepleri farklı kanallarda kaybetmek.

Kapanış

Başarılı bir devreye alma, yazılımın teknik kurulumundan çok kararların zamanında ve yazılı alınmasına dayanır. Bu listeyi projenizin başında uyarlayın, her aşamanın sonunda gözden geçirin ve go/no-go toplantısına ölçütlerle girin. Böylece canlıya geçiş bir risk günü değil, planlanmış bir adım olur.