Kurulum ve sonrası: geçiş stratejileri, değişim yönetimi, bakım
Eski sistemden yeniye geçiş (direct, parallel, pilot, phased), değişim yönetimi ve eğitim, sistem desteği, dört bakım türü ve post-implementation review. Finalde 'hangi geçiş stratejisi' ve 'bu hangi bakım türü' soruları kesin.
Sistem test edildi ve hazır. Ama bir sistemin değeri kurulduğu gün değil, kullanıldığı her gün ortaya çıkar. Bu son hafta üç soruyu cevaplar: Eski sistemden yeniye nasıl geçeceğiz? İnsanları değişime nasıl hazırlayacağız? Sistem çalışmaya başladıktan sonra onu nasıl yaşatacağız? Finalde geçiş stratejisi karşılaştırması ve bakım türü sınıflandırması neredeyse kesin gelir.
Altın kurallar:
- Geçişin üç boyutu var: stil (direct, parallel), yer (pilot, phased, simultaneous), modül (whole-system, modular). Bir strateji üçünün birleşimidir.
- Risk ile maliyet ters orantılı: direct ucuz ve riskli, parallel pahalı ve güvenli.
- Teknik olarak doğru sistem, insanlar kullanmazsa başarısızdır. Değişim yönetimi bunun için var.
- Dört bakım türü: corrective, adaptive, perfective, preventive.
Geçiş (conversion)
Geçiş, eski sistemden (manuel ya da bilgisayarlı) yeni sisteme geçme sürecidir. Plan yapılırken veri aktarımı (eski verinin yeni formata çevrilmesi), donanım kurulumu ve kullanıcı eğitimi birlikte düşünülür.
Boyut 1: stil
| Stil | Nasıl | Risk | Maliyet | Süre |
|---|---|---|---|---|
| Direct | Eski kapanır, yeni açılır | Yüksek | Düşük | Kısa |
| Parallel | İkisi bir süre birlikte çalışır, çıktılar karşılaştırılır | Düşük | Yüksek | Uzun |
Direct: eski ======|
yeni |=========>
Parallel: eski ==========|
yeni |=============>
<-ikisi->Boyut 2: yer
| Yer | Nasıl | Risk | Maliyet | Süre |
|---|---|---|---|---|
| Pilot | Önce bir lokasyon, sonra diğerleri | Düşük | Orta | Orta |
| Phased | Lokasyonlar sırayla, gruplar halinde | Orta | Orta | Uzun |
| Simultaneous | Bütün lokasyonlar aynı anda | Yüksek | Orta | Kısa |
Boyut 3: modül
| Modül | Nasıl | Risk | Maliyet | Süre |
|---|---|---|---|---|
| Whole-system | Bütün modüller aynı anda | Yüksek | Düşük | Kısa |
| Modular | Modüller sırayla (önce üyelik, sonra rezervasyon, sonra raporlama) | Düşük | Yüksek | Uzun |
Modular geçiş için modüllerin birbirinden yeterince bağımsız olması gerekir; değilse eski ve yeni modülleri konuşturan geçici “köprü” kodu yazmak gerekir, bu da maliyeti artırır.
Seçim kriterleri
- Risk: Sistem ne kadar kritik? Hata olursa zarar ne? Para, sağlık, güvenlik varsa parallel ya da pilot.
- Maliyet: Bütçe sınırlı mı? Parallel ve modular pahalıdır.
- Süre: Ne kadar sürede bitmeli? Direct ve simultaneous hızlıdır.
Çözümlü örnek: FitHub şubelerine geçiş
Durum: 5 şube. Eski sistem aylık 12,000 TL işletme maliyetine sahip. Turnike sistemi çökerse üyeler salona giremez (yüksek etki). Yönetim 3 ay içinde geçiş istiyor.
Seçenekleri karşılaştır:
| Seçenek | Süre | Ek maliyet | Risk |
|---|---|---|---|
| A. Direct + simultaneous | 1 hafta | Düşük | Çok yüksek: 5 şube aynı anda kilitlenebilir |
| B. Parallel + simultaneous, 3 ay | 3 ay | (12,000 + 8,000) × 3 = 60,000 TL | Düşük, ama her işlem iki kez |
| C. Direct + phased, şube başı 2 hafta | 5 × 2 = 10 hafta | Düşük | Orta: her seferinde bir şube risk altında |
| D. Pilot (3 hafta) + kalan 4 şube simultaneous (1 hafta) | 3 + 1 = 4 hafta | Orta | Düşük-orta: sorunlar pilotta çözülür |
Karar: D. Pilot şubede turnike ve check-in sorunları yakalanır, sonra hızlıca diğer şubelere geçilir. B güvenli ama 60,000 TL ek maliyet ve personel yükü getiriyor; C ise D’ye göre 6 hafta daha uzun.
Değişim yönetimi (change management)
Yeni sistem insanların çalışma biçimini değiştirir. İnsanlar değişime direnir; bu doğaldır.
Roller
| Rol | Kim | Görev |
|---|---|---|
| Sponsor | Değişimi isteyen, yetkisi olan yönetici | Kararı verir, kaynak sağlar, desteğini gösterir |
| Change agent | Değişimi uygulayan (analist, proje ekibi, ya da kurumdan biri) | Kullanıcıları hazırlar, eğitir, destek olur |
| Potential adopters | Sistemi kullanacak kişiler | Değişimin hedefi |
Lewin’in üç aşaması
UNFREEZE -> MOVE -> REFREEZE
eski yeni sist. yeni alışkanlık
alışkanlığı e geçiş, kalıcı: eski
çöz, neden eğitim sistem kalkar,
anlat yeni prosedürDirenç ve çözüm
Direnç, kişisel maliyet-fayda hesabından doğar. Kurum için faydalı sistem, bir kullanıcıya şunları kaybettirebilir: alışılmış yöntem, uzmanlık statüsü (“eski sistemi en iyi ben bilirdim”), kontrol, zaman (öğrenme eforu).
Değişimi motive etmenin iki yolu:
- Informational strategy: Faydaları anlat, kullanıcının kendi işine etkisini göster. Faydası açık olan değişimlerde işe yarar.
- Political strategy: Kurumsal yetkiyle zorunlu kıl. Kullanıcıya doğrudan fayda olmayan ama kurum için gerekli değişimlerde kullanılır.
Değişimi kalıcılaştırmak için: yeni sistemi kullanmayı ödüllendir, eski sistemi kaldır (geri dönüş yolu kalmasın), prosedürleri ve performans ölçütlerini güncelle.
Eğitim (training)
Eğitimin odağı “sistem ne yapar” değil, “kullanıcı işini yeni sistemle nasıl yapar” olmalıdır. Yani fonksiyon değil, görev odaklı.
| Yöntem | Artı | Eksi |
|---|---|---|
| Classroom | Çok kişi, etkileşim | Esnek değil, herkes aynı hızda |
| One-on-one | Kişiye özel, etkili | Pahalı, yavaş |
| Computer-based (video, interaktif) | Ucuz, kişinin hızında, tekrar izlenebilir | Soru sorma zor, motivasyon düşük olabilir |
Kurulum sonrası faaliyetler
Sistem desteği (system support)
- Online support: Online help, SSS, bilgi bankası, kullanıcı forumları.
- Help desk (level 1): Basit ve sık sorunlar (“şifremi unuttum”, “üyeliği nasıl dondururum”).
- Level 2 support: Uzman destek; level 1’in çözemediği teknik sorunlar.
- Çözülemeyen ve gerçek hata ya da yeni ihtiyaç olan durumlar change request olur.
Sistem bakımı (system maintenance)
Bakım, sistemi kurulumdan sonra değiştirme sürecidir. Değişiklik istekleri dört kaynaktan gelir: kullanıcılar (problem raporu, öneri), help desk, sistem geliştiricileri (bilinen eksikler), iş ortamı (yasal değişiklik, yeni strateji). Her change request önceliklendirilir; büyük olanlar küçük bir proje gibi SDLC’den geçer.
| Bakım türü | Neden | FitHub örneği |
|---|---|---|
| Corrective | Hata düzeltme | Kesme işareti içeren isimde çökme düzeltildi |
| Adaptive | Ortam değişti | KDV oranı değişti; yeni mobil işletim sistemi sürümüne uyum |
| Perfective | Yeni özellik, performans, kullanılabilirlik | “PDF olarak dışa aktar” eklendi; rapor 2 kat hızlandı |
| Preventive | Gelecekteki sorunları önlemek | Kod refactor edildi; desteği bitecek kütüphane değiştirildi |
TUZAK · adaptive ile perfective. Kullanıcı “yeni özellik istiyorum” diyorsa perfective. Dışarıdaki bir şey (yasa, platform, ortak sistem) değiştiği için sistem uyarlanıyorsa adaptive. Soru: “Değişikliği kim tetikledi, kullanıcı isteği mi dış ortam mı?”
Proje değerlendirme (project assessment)
İki parçalı post-implementation review:
Project team review: Ekip kendi sürecini değerlendirir. Tahminler (function point, takvim) ne kadar tuttu? Hangi teknikler işe yaradı? Hangi hatalar tekrarlanmamalı? Sonuçlar kurumun bilgi birikimine eklenir; bir sonraki projenin tahminleri daha iyi olur.
System review: Sistem vaat edilen değeri sağladı mı? 2. haftadaki fizibilite çalışmasındaki fayda ve maliyetler gerçekleşenlerle karşılaştırılır:
| Kalem | Fizibilitede | Gerçekleşen (yıl 1) |
|---|---|---|
| Fayda | 70,000 TL | 64,000 TL |
| İşletme maliyeti | 20,000 TL | 23,500 TL |
| Net | 50,000 TL | 40,500 TL |
Fark analiz edilir: fayda neden düşük kaldı (benimseme yavaş mı?), maliyet neden yüksek (bulut faturası mı?). Böylece döngü kapanır: değerlendirme yeni bir system request’e (yeni sürüm, bakım projesi) dönüşebilir.
Sık yapılan hatalar
| Yanlış düşünce | Doğrusu |
|---|---|
| Parallel = en ucuz | En pahalı, en güvenli |
| Pilot = phased | Pilot önce tek yer, phased yerleri sırayla |
| Direct her zaman kötüdür | Düşük riskli, küçük sistemlerde mantıklı |
| Eğitim fonksiyonları anlatır | Görevleri anlatır: işini nasıl yapacaksın |
| Direnç kötü niyettir | Kişisel maliyet-fayda hesabıdır; yönetilir |
| Yasal değişiklik = perfective | Adaptive |
| Refactoring = corrective | Preventive (hata düzeltmiyor, önlüyor) |
| Proje kurulumla biter | Destek, bakım ve değerlendirme devam eder |
Kendini test et
Sınavdaki gibi İngilizce sorular. Önce kâğıt kalemle çöz, sonra cevabı aç.
Which conversion style turns off the old system and starts the new one at the same moment?
- Parallel
- Direct
- Pilot
- Phased
Cevabı göster
Direct conversion: eski sistem kapanır, yeni sistem açılır. En ucuz ve en hızlıdır ama en risklidir: yeni sistem çökerse geri dönülecek çalışan sistem yoktur.
Which conversion has the lowest risk but the highest cost, and why?
Cevabı göster
Paralel geçişte bir süre iki sistem birden çalışır, çıktılar karşılaştırılır. Yeni sistem hata yaparsa eski sistem devam eder (düşük risk). Ama her işlem iki kez yapılır, ek personel ve iki sistemin işletme maliyeti vardır (yüksek maliyet).
The old system costs 12,000 TL per month to run and parallel running needs 8,000 TL per month of extra staff. Parallel conversion lasts 3 months. What is the extra cost of running the old system during conversion?
Cevabı göster
Aylık ek maliyet 12,000 + 8,000 = 20,000 TL. 3 ay × 20,000 = 60,000 TL. Bu tutar, direct geçişin riskine karşı ödenen bir sigorta gibidir.
A gym chain installs the new system in one branch first, fixes problems, then rolls it out to the remaining branches. Which location strategy is this?
- Simultaneous
- Pilot
- Modular
- Direct
Cevabı göster
Pilot conversion: bir lokasyonda dene, sorunları çöz, sonra diğerlerine yay. Phased (aşamalı) ise lokasyonları sırayla, gruplar halinde dönüştürmektir. Simultaneous hepsini aynı anda dönüştürür.
Classify the maintenance type: 'The tax rate changed by law; the invoice module must use the new rate.'
- Corrective
- Adaptive
- Perfective
- Preventive
Cevabı göster
Adaptive maintenance sistemi değişen ortama uyarlar: yasa, işletim sistemi, dış API, iş kuralı değişikliği. Sistemde hata yok; dünya değişti.
Classify: (a) a crash when a member's name contains an apostrophe is fixed, (b) a new 'export to PDF' feature is added, (c) old code is refactored to make future changes easier.
Cevabı göster
Corrective: hata düzeltme. Perfective: yeni özellik ya da performans/kullanılabilirlik iyileştirmesi. Preventive: gelecekte sorun çıkmasın diye yapılan iş (refactoring, belge güncelleme, eskiyen kütüphaneyi değiştirme).
In Lewin's change model, what are the three stages?
Cevabı göster
Unfreeze: mevcut alışkanlıkları çöz, değişimin gerekçesini anlat. Move: yeni sisteme geçiş, eğitim. Refreeze: yeni alışkanlıkları kalıcılaştır (eski sistemi kaldır, yeni prosedürleri resmileştir).
Who is the person in an organization who wants the change and has the authority to make it happen, and who is the person who leads the change effort day to day?
Cevabı göster
Sponsor değişimi isteyen ve yetkisi olan kişidir (genelde üst yönetici). Change agent değişimi uygulayan, kullanıcılara destek olan kişidir (çoğu zaman analist ya da proje ekibi). Potential adopters değişimden etkilenen, sistemi kullanacak kişilerdir.
Why might users resist a new system even if it is better for the organization?
Cevabı göster
Direnç, kurumsal değil bireysel maliyet-fayda hesabından doğar. Kurum için iyi olan bir sistem, bir kullanıcının işini zorlaştırabilir ya da gücünü azaltabilir. Değişim yönetimi bu algıyı eğitim, iletişim ve teşvikle değiştirir.
A pilot branch takes 3 weeks, then the remaining 4 branches convert simultaneously in 1 week. Compared with a phased rollout of 2 weeks per branch for 5 branches, how much time is saved?
Cevabı göster
Pilot + eşzamanlı: 3 + 1 = 4 hafta. Aşamalı: 5 × 2 = 10 hafta. Fark 6 hafta. Ama eşzamanlı kısımda 4 şube aynı anda risk taşır; pilotun dersleri bu riski azaltır.
What are the two parts of project assessment after installation?
Cevabı göster
Project team review: ekip ne öğrendi, takvim ve tahminler ne kadar doğruydu, gelecekte ne farklı yapılır. System review: sistem beklenen faydayı sağladı mı; 2. haftadaki fizibilitedeki fayda ve maliyetler gerçekleşenlerle karşılaştırılır.
A user calls because she forgot how to freeze a membership. Who should handle this first?
- The development team
- The help desk (level 1 support)
- The project sponsor
- The database administrator
Cevabı göster
Destek katmanlıdır. Level 1 (help desk) sık sorulan ve basit sorunları çözer. Çözemediklerini level 2'ye (uzman destek) iletir. Gerçek bir hata ise change request olarak bakım ekibine gider.
Doğrulama: Geçiş maliyeti ve süre örnekleri node ile hesaplandı (verify/SEN2022/14.mjs). Geçiş stratejileri, değişim yönetimi (Lewin modeli), bakım türleri ve proje değerlendirme soruları standart tanımlarla (Dennis, Wixom ve Tegarden çerçevesi ve yaygın yazılım bakımı sınıflandırması) karşılaştırıldı.