BT proje yönetimi, bir bilişim teknolojisi yatırımını (ERP kurulumu, yazılım geliştirme, ağ altyapısı yenileme, e-Dönüşüm geçişi gibi) tanımlı bir kapsam, bütçe ve takvim içinde, ölçülebilir bir iş hedefine ulaştırmak için yürütülen planlama, koordinasyon ve kontrol disiplinidir. Amaç yalnızca “sistemi çalışır hale getirmek” değil; sistemin doğru kullanıcılar tarafından, doğru süreçlerle ve beklenen faydayı üreterek kullanılmasını sağlamaktır. Bir BT projesi teknik olarak kusursuz tamamlansa bile kullanıcılar benimsemiyorsa ya da iş ihtiyacını karşılamıyorsa başarısız sayılır.
Bu yazıda bir BT projesinin kapsam tanımından devreye almaya kadar olan aşamalarını, paydaş ve risk yönetiminin neden kritik olduğunu, projelerin en sık hangi nedenlerle çıkmaza girdiğini ve başarıyı somut olarak nasıl güvence altına alabileceğinizi ele alıyoruz.
BT projeleri neden başarısız olur?
Sektörel araştırmalar uzun yıllardır, BT projelerinin önemli bir bölümünün ya bütçeyi/takvimi aştığını ya da hedeflenen faydayı tam üretemediğini ortaya koyuyor. Başarısızlığın çoğu zaman teknik değil, yönetimsel ve iletişimsel kaynakları vardır:
- Belirsiz veya sürekli değişen kapsam: Ne yapılacağı baştan net yazılmamışsa, herkes kafasındaki farklı projeyi bekler.
- Kapsam kayması (scope creep): “Madem buradayız, şunu da ekleyelim” yaklaşımıyla kapsam denetimsiz büyür; takvim ve bütçe erir.
- Zayıf paydaş katılımı: Sahanın gerçek ihtiyaçlarını bilen kullanıcılar sürece dahil edilmezse, yanlış şey doğru biçimde geliştirilir.
- Gerçekçi olmayan takvim ve bütçe: Baskı altında verilen iyimser tahminler, ilk aksilikte tüm planı çökertir.
- Yetersiz test: Sistem canlıya alındıktan sonra ortaya çıkan hatalar, hem maliyetli hem de güven kırıcıdır.
- Eğitim ve değişim yönetimi eksikliği: Kullanıcılar yeni sisteme hazırlanmazsa, eski alışkanlıklara döner ve yatırım boşa gider.
- Yönetimsel sahiplenme yokluğu: Üst yönetim projeyi sahiplenmiyorsa, kararlar gecikir ve öncelik kaybolur.
Bu nedenlerin ortak paydası, projenin başında atlanan veya hafife alınan adımlardır. İyi haber şu ki, bunların büyük çoğunluğu sistemli bir yönetim yaklaşımıyla önlenebilir.
Bir BT projesinin temel aşamaları nelerdir?
BT projeleri yöntem olarak klasik (şelale) veya çevik (agile) yürütülebilir; ancak yöntemden bağımsız olarak şu temel aşamalar her projede karşımıza çıkar:
- Başlatma ve hedef tanımı: Proje neden yapılıyor? Hangi iş problemini çözüyor? Başarı hangi ölçütle anlaşılacak? Bu sorular yazılı olarak yanıtlanır.
- Analiz ve kapsam belirleme: Mevcut süreçler incelenir, ihtiyaçlar toplanır, dahil olan ve olmayan işler net biçimde listelenir.
- Planlama: Takvim, bütçe, kaynaklar, sorumluluklar ve kilometre taşları belirlenir; riskler önceden tanımlanır.
- Geliştirme / kurulum: Yazılım yapılandırılır veya geliştirilir, altyapı hazırlanır, veriler taşınır.
- Test ve doğrulama: Sistem teknik ve iş kuralları açısından sınanır; kullanıcılar kabul testlerini yürütür.
- Devreye alma (go-live): Sistem kontrollü biçimde canlıya alınır.
- Devir ve iyileştirme: Destek devreye girer, kullanıcı geri bildirimleri toplanır, eksikler giderilir.
Çevik yaklaşımda bu aşamalar tek seferde değil, kısa döngüler (sprint) halinde tekrarlanır; bu da değişen ihtiyaçlara daha hızlı uyum sağlar. Hangi yaklaşımın uygun olduğu projenin belirsizlik düzeyine ve büyüklüğüne göre seçilmelidir.
Proje kapsamını doğru tanımlamak neden bu kadar önemli?
Kapsam, projenin sınırlarını çizen sözleşmedir: Neyin yapılacağını ve aynı ölçüde önemli olarak neyin yapılmayacağını belirler. Net bir kapsam dokümanı olmadan başlayan projeler, ilerledikçe büyüyen bir beklenti yumağına dönüşür.
Kapsamı sağlamlaştırmak için pratik öneriler:
- İhtiyaçları “olmazsa olmaz”, “olması iyi olur” ve “ileriye bırakılabilir” şeklinde önceliklendirin.
- Her gereksinimi ölçülebilir biçimde yazın. “Raporlama hızlı olsun” yerine “aylık satış raporu 5 saniyenin altında üretilsin” gibi.
- Kapsam dışı maddeleri açıkça yazın; sözlü mutabakatlara güvenmeyin.
- Değişiklik talepleri için bir değişiklik yönetimi süreci tanımlayın: Her yeni istek, takvim ve bütçeye etkisiyle birlikte değerlendirilip onaylansın.
ERP gibi geniş kapsamlı projelerde kapsamın iş süreçleriyle birebir eşleşmesi kritiktir. Netsis 3 ERP çözümlerimizde ve proje ve iş zekası hizmetlerimizde süreç analizini bu nedenle kurulumdan önce yapıyoruz.
Paydaş yönetimi projeyi nasıl etkiler?
Paydaş, projenin sonucundan etkilenen veya projeyi etkileyebilen herkestir: Üst yönetim, departman yöneticileri, son kullanıcılar, BT ekibi, dış tedarikçiler ve hatta zaman zaman müşteriler. Paydaş yönetiminin özü, doğru kişileri doğru zamanda sürece dahil etmek ve beklentileri şeffaf biçimde yönetmektir.
Pratikte işe yarayan yaklaşım şudur: Proje başında paydaşlar listelenir, her birinin proje üzerindeki etkisi ve ilgisi değerlendirilir. Yüksek etki ve yüksek ilgiye sahip paydaşlar (genellikle yönetim sponsoru ve anahtar kullanıcılar) yakın iletişimde tutulur. Düzenli ilerleme toplantıları, tek bir doğruluk kaynağı olarak güncellenen proje planı ve net karar mercileri, beklenti çatışmalarını büyük ölçüde önler.
Özellikle proje sponsoru (üst yönetimde projeyi sahiplenen kişi) kritiktir. Kaynak çatışmaları, öncelik kararları ve departmanlar arası tıkanıklıklar çoğu zaman ancak sponsorun müdahalesiyle çözülür.
BT projelerinde risk yönetimi nasıl yapılır?
Risk yönetimi, “bir şeyler ters giderse ne yaparız?” sorusunu proje başında, henüz vakit varken yanıtlamaktır. Riski yok saymak onu ortadan kaldırmaz; yalnızca en kötü anda sürpriz olarak geri gelmesine zemin hazırlar.
Sağlıklı bir risk yönetimi döngüsü dört adımdan oluşur:
| Adım | Ne yapılır | Örnek |
|---|---|---|
| Tanımlama | Olası riskler listelenir | Veri taşımada eski kayıtların tutarsız olması |
| Değerlendirme | Olasılık ve etki puanlanır | Yüksek olasılık, yüksek etki |
| Önlem planı | Azaltıcı veya önleyici aksiyon belirlenir | Geçiş öncesi veri temizliği ve test ortamında deneme |
| İzleme | Risk durumu düzenli gözden geçirilir | Haftalık risk gözden geçirme toplantısı |
BT projelerinde sık görülen riskler arasında veri kaybı, entegrasyon hataları, anahtar personelin ayrılması, dış servis (örneğin GİB e-Dönüşüm veya pazaryeri) API değişiklikleri ve yetersiz yedekleme sayılabilir. Bu risklerin teknik tarafında sağlam bir altyapı belirleyicidir; veri koruma, yedekleme ve sürekliliği için server ve güvenlik hizmetlerimizden ve donanım ve bakım tarafından destek alabilirsiniz.
Test ve devreye alma aşamasında nelere dikkat edilmeli?
Test, projenin canlıya alınmadan önceki son güvenlik ağıdır ve asla atlanmaması gereken aşamadır. İyi bir test stratejisi birkaç katmandan oluşur:
- Fonksiyonel test: Her özellik beklendiği gibi çalışıyor mu?
- Entegrasyon testi: Sistemler birbiriyle doğru veri alışverişi yapıyor mu (ör. ERP ile e-fatura, ERP ile e-ticaret)?
- Kullanıcı kabul testi (UAT): Gerçek kullanıcılar, gerçek senaryolarla sistemi kendi iş akışlarında deniyor mu?
- Yük/performans testi: Sistem, yoğun kullanım altında kabul edilebilir hızda kalıyor mu?
Devreye alma (go-live) ise tek başına bir “düğmeye basma” anı değil, planlı bir geçiştir. Devreye almadan önce şu kontrol listesini gözden geçirin:
- Tüm kabul testleri tamamlandı ve kritik hatalar giderildi mi?
- Veri taşıma doğrulandı, eski ve yeni sistem tutarlılığı kontrol edildi mi?
- Geri dönüş (rollback) planı hazır mı? Bir şey ters giderse eski sisteme dönülebilir mi?
- Kullanıcı eğitimleri tamamlandı, kullanım kılavuzları hazır mı?
- Go-live sonrası ilk günler için destek ekibi ve iletişim kanalı belirlendi mi?
- Yedekler güncel ve geri yükleme test edildi mi?
Geçiş yönteminde aceleci olmayın. Riskli projelerde sistemin tamamını bir gecede değiştirmek yerine kademeli geçiş (önce bir departman veya bir lokasyon) ya da paralel çalışma (eski ve yeni sistemin bir süre birlikte işletilmesi) çoğu zaman daha güvenlidir.
Başarıyı nasıl ölçeriz?
Bir BT projesinin başarısı yalnızca “zamanında ve bütçede bitti mi?” ile ölçülmez. Asıl soru, projenin baştan tanımlanan iş hedefini üretip üretmediğidir. Bu yüzden başarı ölçütleri proje başında, somut ve ölçülebilir biçimde belirlenmelidir: İşlem süresinin kısalması, hata oranının düşmesi, manuel iş yükünün azalması, raporlama hızının artması gibi. Devreye almadan sonra bu göstergeleri belirli aralıklarla ölçmek, hem yatırımın geri dönüşünü görmenizi hem de iyileştirme alanlarını tespit etmenizi sağlar.
Sıkça Sorulan Sorular
Küçük bir işletme için proje yönetimi gereksiz bir formalite değil mi? Hayır. Proje yönetimi, projenin büyüklüğüne göre ölçeklenir. Küçük bir işletmede bu, yüzlerce sayfalık dokümantasyon değil; net bir hedef, yazılı bir kapsam, gerçekçi bir takvim ve düzenli iletişim demektir. Bu minimum disiplin bile, en sık görülen başarısızlık nedenlerini büyük ölçüde önler.
Çevik (agile) mi, klasik (şelale) yöntem mi daha iyi? “Daha iyi” yöntem yoktur; uygun yöntem vardır. Gereksinimleri baştan net ve değişmesi pek olası olmayan projelerde klasik yaklaşım verimlidir. Belirsizliğin yüksek olduğu ve sürekli geri bildirimle olgunlaşacak projelerde çevik yaklaşım avantaj sağlar. Çoğu kurumsal projede ikisinin dengeli bir karması (hibrit) kullanılır.
Kapsam kaymasını (scope creep) nasıl önlerim? Anahtar, başta net bir kapsam yazmak ve sonra her yeni talebi resmi bir değişiklik yönetimi sürecinden geçirmektir. Her ek istek; takvime, bütçeye ve diğer önceliklere etkisiyle birlikte değerlendirilir ve karar mercii tarafından onaylanır. “Küçük bir ekleme” diye geçiştirilen taleplerin toplamı çoğu projeyi raydan çıkarır.
ERP projesi ortalama ne kadar sürer? Süre; işletmenin büyüklüğüne, süreç sayısına, entegrasyon ihtiyaçlarına ve veri taşıma karmaşıklığına göre ciddi biçimde değişir. Bu yüzden sabit bir süre vermek doğru olmaz. Doğru yaklaşım, analiz aşamasından sonra projeye özel gerçekçi bir takvim çıkarmaktır; biz de süreci her zaman ön analizle başlatırız.
Geri dönüş (rollback) planı tam olarak nedir? Devreye alma sırasında ciddi bir sorun çıkarsa, eski çalışan duruma güvenli biçimde dönebilmenizi sağlayan önceden hazırlanmış plandır. Güncel yedekler, eski sistemin bir süre erişilebilir tutulması ve net bir karar eşiği içerir. İyi hazırlanmış bir rollback planı, go-live gününün stresini önemli ölçüde azaltır.
BT projenizi sağlam temeller üzerine kurmak ister misiniz? ERP kurulumu, e-Dönüşüm geçişi, Xenon saha satış projeleri veya özel yazılım (PDKS, Tapu, Desen) ihtiyaçlarınız için Giza Teknoloji ekibine ulaşın: WhatsApp 0532 599 51 12, telefon 0532 599 51 12 veya bilgi@gizateknoloji.com. Detaylı bir değerlendirme için İletişim sayfamızdan yazabilir, firmamızı daha yakından tanımak için Hakkımızda sayfasını ziyaret edebilirsiniz.