SAP Değişiklik Yönetimi

SAP projesinde canlıya geçildikten sonra, genelde her şey bitti diye düşünülür. Aslında asıl süreç bundan sonra başlar. Çünkü genellikle proje kapsamında olmayan, ya da projenin farklı fazlarında planlanan alt projeler devreye alınmak istenir. Bununla birlikte, projede yapılan süreç değişiklikleri bazen uygulamada istenildiği gibi firmaya verim getirmez, bu süreçlerin tekrar tasarlanması gerekebilir. En çok karşılaşılan durum da, istenilen süreç ve ek geliştirmeler yeterli test edilmemesi durumunda, canlıya geçtikten sonra istenildiği gibi çalışmadığının farkına varılır ve  hataların giderilmesi gerekmektedir.

Proje gerçekleştirilirken genelde belirli kurallar vardır, ama canlı kullanım olmadığı için süreç ve ekranları değiştirmek çok büyük problem olmaz. Canlı sonrası ise bu tarz değişiklikler için  uygun bir değişiklik yönetimi prosedürü olmalı ve bu kurallar esnetilmeden net bir şekilde uygulanmalıdır. Unutulmamalıdır ki, canlı sistemde kayıtlı veya açık belgeler ve işlemler bu değişikliklerden olumsuz olarak etkilenebilir.

En sık uygulanan değişiklik yönetim kurallarını sıralamak gerekirse:

• Üçlü sistem : Geliştirme, test ve canlı sistem için üçlü yapının kurulması, canlıdan kopyalanan test sistemi ile kullanıcıların verimli ve gerçeğe uygun veri kümeleriyle test edebilmesi sağlanmalıdır.

• Kullanıcı Kabül: Yukarıdaki maddede belirtildiği üzere, kullanıcılar talep ettikleri değişikliklerin onayını test yaparak vermeleri gerekir. Aksi durumda canlı sisteme alınan kontrolsüz değişiklikler sistemsel sorunlara yol açabilir.

• Etkilenen Süreçlerin çıkartılması: Belki de en sık atlanan kural olmakla birlikte, bazen talep edilen bir değişiklik, aynı departman ya da başka bir departmandaki bir süreci olumsuz etkileyebilir. Analiz sırasında bu detaya zaman ayırmalı ve süreçler sadece değişen kısmı değil, uçtan uca test edilmelidir.

• Değişiklik/Sorun Takibi: Bir sistem üzerinde, yapılan değişiklik talepleri ve hataları takip edilmeli, mümkünse SAP’de alınan requestler bu sistemdeki numaralarla eşleştirilmelidir. Bu sistemde bir arama yapıldığında, bir ekran ya da süreçteki talep edilen değişiklik ve sorunlar listenelebilir olmalıdır.

• Dokümantasyon: Yukarıdaki maddede değişiklikleri takip etmek için bir sistemden bahsetmiştik. Bu sisteme ek olarak, talep edilen değişikliklerin standart bir format ile dokümante edilmesi ve bu sistemde saklanması gerekmektedir.

• Kuvvetler Ayrılığı: Geliştirme ya da uyarlamayı yapan kişi ile bu geliştirmeyi canlı sisteme taşıyan kişilerin farklı olması gerekmektedir. Bu süreç yapılan değişiklikler için bir kontrol mekanizması olarak görülebilir.

• Canlıya Alma Planı: Canlıya alınan bir geliştirme, canlıda soruna yol açabilir, test sistemindeki gibi sistem tepki vermeyebilir. Bu sorunu aşabilmek adına, canlıya alım için belirli günler ve saatler belirlenmeli, özel durumlarda da ( tablo append edilmesi gibi) mesai saatleri sonrası beklenmelidir.

Yukarıdaki maddeler göreceli olabilir, firma ve sistem sorumlularına göre farklı kombinasyonları uygulanabilir, ama ne kadar doğru yönetilirse değişiklik yönetimi, canlı sistemde o kadar az sorunla karşılaşılır. Unutulmamalıdır ki, uzun süreli kesintiler veya sistemsel sorunlar maddi kayıpların yanı sıra, firma ve çalışanlarına itibar kaybı da getirmektedir.