ERP canlıya geçtikten sonra ilk 90 gün: hypercare, kullanıcı benimseme ve gösterge takibi

Proje ekibi go-live gününde genelde bir kutlama yapar: aylarca süren demo, veri taşıma ve eğitim turlarından sonra sistem nihayet canlıdır. Ama bu tarih bir bitiş çizgisi değil, asıl sınavın başladığı noktadır. Bir sektör analizine göre ERP projelerinin önemli bir bölümü beklenen yatırım getirisine (ROI) hiç ulaşamıyor — oran, projeden projeye değişmekle birlikte yüzde 55-75 aralığına kadar çıkabildiği bildiriliyor; aynı analiz işletmelerin yaklaşık yarısının (yüzde 51) go-live anında bir tür operasyonel aksama yaşadığını aktarıyor. Bu rakamların kesinliği tartışılabilir ama yönü nettir: proje başarısı go-live tarihinde değil, ondan sonraki haftalarda belli olur.

Bu yazı belirli bir vendor'ı önermiyor; go-live sonrası ilk 90 günde hangi aşamalardan geçileceğini, hypercare döneminin ne zaman biteceğine nasıl karar verileceğini ve hangi göstergelerin izlenmesi gerektiğini tarafsız bir çerçevede topluyor.

Hypercare: destek yoğunluğunu takvimle değil ölçütle kapatmak

Go-live'ı takip eden döneme sektörde "hypercare" denir — proje ekibinin hâlâ yoğun biçimde masa başında olduğu, kullanıcı sorularının anlık karşılandığı, küçük hataların hızla düzeltildiği bir stabilizasyon evresidir. Süresi işletmeden işletmeye değişir; genel eğilim birkaç hafta ile birkaç ay arasında değişen bir aralıktır ve asıl belirleyici, iş sürecinin karmaşıklığıdır.

Yaygın hata, hypercare'in bitişini sabit bir takvim tarihine bağlamaktır ("iki hafta sonra ekip çekiliyor"). Daha sağlıklı yaklaşım, çıkış kriterlerini go-live'dan önce tanımlamaktır: destek talebi hacminin belirlenen bir eşiğin altına inmesi, kritik iş süreçlerinin (fatura kesimi, stok hareketi, tahsilat) ek müdahale gerekmeden tamamlanabilmesi, açık hata kuyruğunun erimesi. Bu ölçütler karşılanmadan ekip erken çekilirse, kullanıcı sistemle baş başa kalır ve küçük bir sorun büyüyerek "sistem çalışmıyor" algısına dönüşebilir; ölçütler karşılandıktan çok sonra ekip hâlâ ordaysa, bu kez maliyet gereksiz uzar ve sorumluluk kimde belli olmaz.

İkisinin ortası pratikte en çok işe yarayan yöntemdir: bir üst sınır tarih (ör. sekiz hafta) belirlenir ama gerçek çıkış, o tarihten önce ölçütler karşılandığında da yapılabilir.

Kullanıcı benimseme: eğitim bitince iş bitmiyor

Go-live öncesi eğitimler genelde "sistemi nasıl kullanırım" sorusuna cevap verir; ama kullanıcı gerçek iş yükü altında, gerçek verilerle çalışmaya başladığında ortaya farklı sorular çıkar. Bu noktada en sık görülen risk, kullanıcının zorlandığı bir adımda eski alışkanlığına — paralel bir Excel tablosuna, eski sistemin bir ekranına, telefonla teyit almaya — geri dönmesidir. Bu geri dönüş fark edilmeden sürerse, sistem "canlı" görünür ama gerçek veri akışının bir kısmı sistemin dışında, kayıt altına alınmadan yürümeye devam eder.

Bunu önlemenin en somut yolu, ilk haftalarda kullanıcı davranışını gözlemlemektir: hangi ekranlar hiç açılmıyor, hangi raporlar hâlâ elle hazırlanıyor, hangi departman soru sormaktan çekiniyor. Sessiz kalan bir departman genelde sorunsuz değil, sistemi kullanmaktan vazgeçmiş bir departmandır. Bu gözlemi yapacak bir "yerel elçi" (her departmandan sistemi iyi öğrenmiş bir kişi) ataması, merkezi destek ekibinin göremediği günlük sürtünmeyi erken yakalar — bu rol genelde proje bütçesine dahil edilmez ama go-live sonrası en ucuz risk azaltma yatırımlarından biridir.

İlk 90 günde hangi göstergeler izlenmeli

Sayısal bir "başarı eşiği" her işletme için aynı değildir, ama izlenmesi gereken gösterge kategorileri değişmez:

• Kullanım (adoption): Hangi modüller günlük olarak açılıyor, hangileri hiç kullanılmıyor.
• Süreç tamamlanma süresi: Sipariş girişinden faturaya, satın alma talebinden onaya kadar geçen süre — go-live öncesi süreyle karşılaştırılmalı, ilk haftalarda bir miktar yavaşlama beklenir ama sürekli kötüleşme uyarı işaretidir.
• Veri kalitesi: Zorunlu alanların boş bırakılma oranı, mükerrer kayıt sayısındaki artış — veri taşıma sürecinde temizlenen veri, kullanım sırasında tekrar kirlenebilir.
• Destek talebi hacmi ve türü: Aynı hatanın tekrar tekrar bildirilmesi, tekil bir hata değil bir eğitim veya tasarım eksikliğine işaret eder.
• Finansal kapanış döngüsü: İlk ay/dönem kapanışının ne kadar sürdüğü, eski sistemdeki kapanış süresiyle kıyaslanmalı.

Bu göstergeler haftalık bir kısa toplantıda gözden geçirilmeli — büyük bir rapor değil, "geçen haftaya göre ne değişti" sorusuna cevap veren kısa bir özet yeterlidir.

Sık görülen hatalar

• Proje ekibinin go-live sonrası aynı gün ya da hafta içinde tamamen çekilmesi, hypercare planlanmaması
• Eğitimin yalnızca go-live öncesine sıkıştırılması, sonraki haftalarda "pekiştirme" oturumu yapılmaması
• Kullanıcı şikayetlerinin bireysel biletler olarak ele alınıp örüntü aranmaması (aynı hata beş kişiden geliyorsa bu bir süreç sorunudur, beş ayrı biletlik iş yükü değil)
• Departman bazlı kullanım verisinin izlenmemesi — hangi ekibin sessizce eski yönteme döndüğü aylar sonra fark edilir
• Hypercare'in belirsiz biçimde uzaması, kimin ne zaman sorumluluğu devraldığının netleşmemesi
• Go-live sonrası ilk kapanış döneminde ("ay sonu", "yıl sonu") ekstra destek planlanmaması — sistemin en yoğun test edildiği an genelde ilk mali kapanıştır

Sorun bildirmek cezalandırılmamalı

İlk 90 günde en değerli bilgi kaynağı, sistemle en çok uğraşan kullanıcıların kendisidir — ama bu bilginin yukarı çıkması, ortamın buna izin vermesine bağlı. Bir kullanıcı "bu ekranı anlamadım" ya da "burada eski yöntemi kullanıyorum" dediğinde bu bir performans eksikliği değil, erken uyarı sinyali olarak karşılanmalı. Sorun bildiren kişinin eleştirildiği ya da "sen mi beceremedin" tonuyla karşılandığı bir ortamda geri bildirim hızla kesilir; ekip sorunu çözmek yerine gizlemeyi öğrenir ve proje ekibi asıl sorunları aylar sonra, çok daha büyümüş halde öğrenir.

Bunu yönetmenin pratik bir yolu, ilk haftalarda kısa ve düzenli bir geri bildirim kanalı açmaktır — haftalık on beş dakikalık bir tur, kısa bir anket ya da departman temsilcileriyle sabit bir toplantı saati. Amaç büyük bir memnuniyet anketi değil, "bu hafta nerede takıldınız" sorusuna hızlı cevap almaktır. Bu kanal proje bittikten sonra da bir süre açık tutulmalı; sistemin gerçek anlamda benimsendiğinin en net göstergesi, kullanıcıların sorunu saklamak yerine bildirmeye devam etmesidir.

Sektöre göre değişen risk noktaları

İlk 90 günün kritik anı sektöre göre değişir. Üretim yapan işletmelerde en riskli test genelde ilk tam üretim planlaması döngüsüdür — reçete ve iş emri verisinin doğru aktığı ancak gerçek bir üretim turu tamamlandığında anlaşılır. Perakende ve e-ticaret tarafında ise stok ve fiyat senkronizasyonunun kampanya ya da sezon yoğunluğunda nasıl davrandığı asıl sınavdır; bu yüzden go-live tarihinin yoğun satış dönemleriyle çakışmaması ayrıca önemlidir. Çok şubeli ya da holding yapısındaki kurumlarda ise şubeler arası konsolide raporlamanın ilk kez gerçek veriyle çalıştığı an, genelde ilk ayın kapanışıdır.

Vendor'a göre de destek modeli farklılaşır: bazı iş ortakları hypercare'i teklif kapsamına dahil eder, bazılarında bu ayrı bir kalem olarak fiyatlandırılır. Bu ayrımın net olup olmadığı, sözleşme aşamasında imzadan önce kontrol edilmesi gereken maddeler arasında değerlendirilmeli — go-live sonrası destek kapsamı belirsizse, en çok ihtiyaç duyulan haftalarda "bu bizim kapsamımızda değil" cevabıyla karşılaşma riski yükselir. Bulut/SaaS modelinde destek genelde vendor'ın standart hattından, şirket içi kurulumda ise proje danışmanından ya da iç BT ekibinden gelir — bu farkın go-live sonrası hıza etkisini bulut/SaaS ERP karşılaştırma sayfamızda ayrıca ele aldık.

Ne zaman "stabil" denebilir

Sistemin stabil sayılabilmesi için tek bir tarih yoktur; aşağıdaki kontrol listesi çoğu işletme için makul bir eşik oluşturur:

• Destek talebi hacmi go-live sonrası ilk haftalara göre belirgin biçimde düştü mü?
• Kritik süreçler (sipariş, fatura, tahsilat) ek müdahale olmadan uçtan uca tamamlanabiliyor mu?
• En az bir tam mali dönem kapanışı sorunsuz tamamlandı mı?
• Departman bazlı kullanım verisinde "sessiz kalan" bir ekip var mı, varsa nedeni araştırıldı mı?
• Eski sistemdeki paralel çalışmaya (gölge Excel, manuel kayıt) hâlâ ihtiyaç duyuluyor mu?
• Hypercare'den normal destek modeline geçiş sorumluluğu (kim, ne zaman) yazılı olarak netleşti mi?

Bu maddelerin çoğu evetse, proje "canlı" değil gerçek anlamda "yerleşmiş" sayılabilir. Kendi go-live planınızı bu çerçeveyle karşılıklı değerlendirmek isteyen işletmeler için bağımsız bir keşif görüşmesi talep edilebilir; henüz seçim aşamasındaysanız hypercare ve destek kapsamını teklif karşılaştırmasına dahil etmek için uygun ERP bul aracı kullanılabilir. Vendor'lar arası destek modeli farkları Qera ERP ve Birasyo ERP gibi yerli platformlardan SAP Business One gibi küresel ürünlere kadar değişkenlik gösteriyor; bu fark teklif karşılaştırmasında genelde lisans fiyatından daha az konuşulur ama go-live sonrası deneyimi doğrudan belirler.

Kaynaklar

• ERP Software Blog, "ERP Failure Rarely Happens at Go-Live. It Happens Quietly, Afterward." (2026) — ERP projelerinin yüzde 55-75'inin beklenen ROI'ye ulaşamadığı ve işletmelerin yüzde 51'inin go-live anında operasyonel aksama yaşadığı aktarılıyor (erpsoftwareblog.com)
• Panorama Consulting Group, "Your ERP Hypercare Checklist And Post-Go-Live Support Plan" — hypercare çıkışının takvime değil tanımlı ölçütlere (destek hacmi, işlem doğruluğu, hata kuyruğu) bağlanması öneriliyor (panorama-consulting.com)
• ERP'ye geçişte veri taşıma rehberi
• ERP sözleşmesi kontrol listesi