| İlhan Kesken, PMP – Proje Ofisi Yöneticisi |
İş Süreçleri Yönetimi (BPM) Projelerinde Risk Yönetimi
Proje Yönetimi deyince bir çoğumuzun aklına bir zaman çizelgesi, görevler, kaynaklar hedef tarihler vs. vs. gibi şeyler geliyor. Eğer proje yönetimi disiplinin formasyonuna sahip değilseniz, riskler listenize ya hiç girmez ya da en sonlarda yer alır.
Oysa anketlerin gösterdiği çarpıcı gerçek gösteriyor ki girişilen her 10 İş Süreçleri Yönetimi (BPM) projesinin 7 ‘si başarısızlık ile sonuçlanıyor.
Bu yüksek oran tek başına, bu projelerde ne yapılması gerektiğine odaklanıldığı oranda ne yapılmaması gerektiğini de düşünmek gerektiğini kanıtlıyor.
Riskler ve Risk Yönetimi (BPM)
Klasik tanımla, risk mümkün olan sonuçların çeşitliliğinin, oluşma olasılıkları ve subjektif etki oranlarının ifade edilmesidir. Bu teoriye uygun matematiksel formül:
Risk = Kazanım veya Kaybın oluşma olasılığı (%) X Etkisinin Büyüklüğü
Proje Yönetim Enstitüsü (Project Management Institute – PMI) riski;
Oluşması kesin olmayan ancak oluştuğunda proje hedefine olumlu ya da olumsuz etkisi olacak bir olay ya da durum olarak tanımlıyor.
Riskler genellikle negatif sonuçlar ile ilişkilendirildiğinden proje problemleri ile karıştırılır. Aslında riskler problem değildir, ancak riskleri potansiyel problemler olarak görmek hata olmaz.
Risk Yönetimi
Risk yönetiminin amacı potansiyel problemleri azaltmak ya da nötralize etmek, fırsatları geliştirmek ve devreye sokmaktır. Risk yönetim yapıları 3 ana safhadan meydana gelir: tanımlama, analiz ve kontrol.
Tanımlama safhası bir uzman grubunun beyin fırtınası çalışmaları ile yürütülür.
Riskler belirsizlikler yüzünden oluşur. Bu nedenle riskleri bir çerçeve içine alıp tam olarak karakterize etmek güç bir iştir. Bunu yapmanın bir yolu etki, olasılık, oluşma zamanı ve diğer riskler ile örtüşme durumu gibi özellikleri tespit ederek kategorize etmektir. Literatürde dört risk yanıtlama stratejisi yer almaktadır:
1. Hafifletme
2. Kurtulma (Avoidance)
3. Transfer etme
4. Kabul etme
| Strateji | Tanım | Örnekler |
| Hafifletme | Riskin oluşma olasılığını ve/veya etkisini azaltmak. Risk sınırlandırma, riskin oluşmasına mâni olamasa da oluşan riskin etkilerini tamponlayarak hafifletme amacını güder. | · Süreç Yönlendirme standartları · Resmileştirilmiş kural dışı durum işleme (exception handling) |
| Kurtulma | Bir risk oluşmadan önce önlem almak ve oluşmasına mâni olmak. Genellikle etkisi daha az olan ya da çözümlenmesi daha zahmetsiz olan başka riskleri kabullenmek yolu ile icra edilir. | · Sürecin yeniden tasarlanması |
| Transfer etme | Riskin oluşması durumunda oluşacak etkiyi bir başka partiye yönlendirmek ya da etkiyi paylaşarak azaltmak. Dış kaynak kullanma ya da sigortalama gibi faaliyetler içerebilir. | · Dış kaynak kullanımı süreci · Sigorta politikaları |
| Kabul etme | Risk bir problem olarak ortaya çıktığında ona ayak uydurmak, adapte olmak. Bu strateji bir acil durum planı gerektirir. | · Hukuki düzenlemelere uygun olmak |
Kurumsal Projelerde Yaygın Risk Sınıflandırmaları
Kurumsal Projelerde risk konusu akademik literatürün ilgisini cezbetmiş bir olgudur. En popüler sınıflandırma riskin yapısını baz alarak yapılan sınıflandırmadır. Tipik olarak bir iş durumu doğal afetler veya olaylar, insanlar ile ilgili riskler, çevresel faktörlerden kaynaklanan riskler tarafından tehdit edilir. Benzer olarak İş Süreci Yönetimi (BPM) alanını hedefleyen projelerde de 3 ana grup düşünülebilir
1. İnsanlardan Kaynaklı Riskler
2. Yönetimden Kaynaklı Riskler
3. Teknik Riskler
Bununla beraber (Davenport, 1993) organizasyonel insan kaynaklarını ve bilişim teknolojilerini (IT) [1] süreç inovasyonunun iki temel sürücüsü olarak konumlandırıyor. Yani bu ikisini iyi yönetmezsek işimiz negatif olarak etkilenebilir anlamına geliyor.
(Scott, 2000) Kurumsal sistem uyarlamaları için geliştirdikleri risk faktörleri modelinde dış çevre değişimleri bağlamına da yer verdiler. Onlara göre riskler, organizasyon içinde iyi yönetildiklerinde ve organizasyonumuz dış çevreden dikte edilen değişikliklere reaksiyon gösterebildiğinde işimizi olumlu olarak etkilerler. (Summer, 2000) Araştırmasında ise risk konteksti daha küçük gruplara ayrılmıştır.
1. Yetenek Dağılımı
2. Yönetim Yapısı ve Strateji
3. Yazılım Sistem Tasarımı
4. Kullanıcıların Dâhiliyeti ve Eğitim
5. Teknoloji Planlaması
6. Proje Yönetimi
7. Sosyal Taahhüt (Social Commitment)
Aşağıdaki tablo yukarıda belirttiğimiz kaynaklar ve araştırmaları baz alarak hazırlanmıştır (zue Muehlen & Rosemann, 2005).
Riskler organizasyon içindeki faktörlerden kaynaklanabilir ya da dış faktörler tarafından oluşturulabilir.
İş Süreci Yönetimi (BPM) projelerinde örnek durumlar; proje ekibinde İş Süreç Yönetimi kültürünün olmaması ya da seçilmiş 3ncü parti yüklenicilerde uygun teknolojinin bulunmaması olabilir. Oluşma olasılığı ‘kesin’ ile ‘imkânsız’ arasında bir noktada olabilir.
Oluşma olasılığı kesin olan riskler için mutlaka hata yakalama ve giderme prosedürlerinin düşünülmüş olması gerekir. Oluşan etkilerin kritik seviyeleri de çok hafif (dokümantasyonlarda hata olması, yönetişim yapısında oluşan ufak aksaklıklar vb.) olabileceği gibi tüm projenin durdurulmasını gerektirecek seviyede de olabilir.
Risklerin hangi alanlarda sonuçlar doğurduğu da sınıflandırma yapılırken kullanılan özelliklerdendir. Riskler durup dururken, ortada hiçbir sebep yokken belirivermezler, çoğu durumda istemli ya da istemsiz yapılmış bir hatanın sonucu olarak vücut bulurlar. Bazen de politika ve prosedürler de risklerin oluşmasına sebep olabilirler, bazen kurum içi çalışma kuralları veya kültürel formasyon riskin ortadan kalkmasını sağlayacak tedbirlerin alınmasını engelleyebilir.
İş Süreçleri Yönetimi (BPM) Projelerine Özel Riskler
İş Süreci Yönetimi projelerinde riskler yaşam döngüsünün fazları içinde oluşabileceği gibi fazlar arası geçişler sırasında da oluşabilirler. Aşağıdaki tabloda bu alanlarda yaygınlaşmış risklerin bir listesini bulabilirsiniz.
Belirlenmiş risklerin büyük bölümü
. Süreç yaşam döngüsünün değişik fazları arasında kullanılan metotların birbiri ile uyumlu olmaması
. Fazlardan ve sonuçlarından kimin sorumlu olduğunun belirli olmaması
. Süreç hedeflerinin doğru belirlenmemiş olması
gibi sebepler nedeni ile hayat bulur. İş Süreci Yönetimi projelerinin yöneticilerinin bunlara dikkat etmesi gerekir.
Bu sınıflandırma yönetimsel açıdan önemlidir çünkü değişik fazlarda aynı türden riskler oluşabilmektedir. Bunları tespit edebilmek için daha detaylı bir risk analizinin yapılması daha fazla fonksiyonel sınıfın ortaya çıkarılması gerekebilir. Bu fonksiyonel sınıflar ortak kök nedenleri (eğitim eksikliği, proje yönetimi yetenekleri eksikliği, seçilmiş teknolojinin uyumsuzluğu vb.) olan riskleri ortak kümelerde toplayıp yönetmeyi kolaylaştırırlar. Tespit edilmiş kök nedenlere müdahale edilerek tek bir müdahale ile birden fazla fazda oluşabilecek problemler engellenmiş olur.
Yaşam Döngüsüne Özel Riskler
| Yaşam Döngüsü Fazları | İş Süreçleri Yönetimine (BPM) Özel Riskler |
| Analiz | · Bir süreç stratejisi olmaksızın analiz yapılması · Süreç hedeflerini ve değerlerini tanımlamada başarısız olma· Teknik konulara gereğinden fazla yoğunlaşma· Analizin yapıldığı dilin gözlemlenen süreç semantiklerini ifade etmekte yetersiz kalması |
| Analiz -> Tasarım | · Analiz çıktılarının tasarıma birebir yansıtılamaması · Tasarıma çevrilirken bilgi veya odak kaybı oluşması |
| Tasarım | · Uyarlama modelleme dilinin istenen süreç semantiklerini desteklememesi · Uyumsuz modelleme teknolojilerinin kullanılması· Süreç tasarımcıları ve süreç paydaşları arasında iletişim eksikliği· Tasarımcıların süreç tasarısı üzerindeki organizasyonel bakış açısını yok sayması, kavrayamaması· Tasarıma Risk (problem) yakalama ve işleme tedbirlerinin konmamış olması· Modellemeyi yapanların farklı seviyelerde soyutlama yapıyor olması. Modelin çok soyut olması ya da çok ayrıntılı olması… |
| Tasarım -> Uyarlama | · Süreç modelinden uyarlama planına geçişte yanlış yorumlamalar yapılması · Modelleme metodu (ya da yaklaşım) ile uyarlama metodunun (ya da yaklaşım) birbiri ile uyumsuz olması |
| Uyarlama | · Uyarlamaya yukarıdan bakılabilen (üst düzey yönetici seviyesi) bir görünüm oluşturulamaması · Yöneticilerde süreç yönetimi bilgisi/kültürü olmaması· Teknik konulara fazla odaklanma· Ulaşılan modelin alt yapıya uyumlu olmaması· Ulaşılan modelin organizasyona (kültürel, yapısal, bölgesel vs.) uyumlu olmaması· Kaynakların transformasyonunun planlanamaması· Süreç paydaşlarında istenen davranış, rol ve sorumluluk değişiminin sağlanamaması· Süreç paydaşlarının yeni tasarımı incelemeye gerek görmeden süreci zaten biliyor olduklarını farz etmeleri |
| İşletme | · Süreç paydaşları arasında ortak bir dil olmaması veya iletişimin hiç olmaması · Süreç paydaşlarının süreç aktivitelerini yerine getirme konusunda direnç göstermesi· Süreç paydaşlarının yeni yapıya alışmasının uzun sürmesi· Süreç paydaşlarının organizasyon sınırları dışındaki iletişimi etkin olarak yapamaması· Süreç paydaşlarının süreç odaklı liderlik ortamında kendini rahat hissetmemesi· Süreç paydaşlarının süreç işlerken farklı farklı kişilerle çalışmak zorunda kalması· Sistemin kararlı bir şekilde çalışmaması· Servis sağlayıcıların işi bırakması· Yeni yasal düzenlemelerin süreci tamamen ya da kısmi olarak yasal olmaktan çıkarması |
| İzleme | · Bir izleme stratejisi düşünülmemiş olması · Paydaşların özel istekleri ya da yasalar nedeni ile süreç saydamlığının azalması ya da yok olması· Paydaşların verdiği yanlış, hatalı geri bildirimler· Oluşan izleme verisini uygun filtreler ile sadeleştirilememesi· Kalite yaklaşımı olmadan izleme yapmak· Tasarımda belirtilen ile izlenen nesneler arasında fark olması |
| İzleme -> Denetim | · İzleme yapan kişilere değerlendirebileceklerinden fazla bilgi gitmesi · Ham denetim datasının anlaşılabilir faydalı raporlara dönüştürülememesi· Farklı kanallardan gelen bilginin anlamlı bir şekilde birleştirilememesi· Oluşan bilginin insanlar tarafından manipüle edilmesine engel olunamaması· Kritik durumların zamanında tespit edilip zamanında tepki verilememesi |
| Denetim | · Denetimde kullanılacak standartların henüz oluşmamış olması · Denetim hedefleri ile tasarım hedeflerinin birbirine uyumlu olmaması· Denetim verisinin yanlış yorumlanması· Denetim verisinin faydalı iş verisine dönüştürülememesi· Değerlendirmeyi stratejik ve dış değişkenlere ilişkili hale getirememe |
| Denetim -> Tasarım | · Geri bildirim mekanizmalarının oluşturulmamış olması · Denetim ve değerlendirme sırasında problemleri tespit etme yetkinliğinden yoksun olunması· Değerlendirme sonuçlarından acil durum planları oluşturma yetkinliğinden yoksun olma |
Aşağıdaki tabloda risk faktörleri için yapılmış bir Risk Sınıflandırması göreceksiniz:
Risk Sınıflandırması
| Risk Faktörü | Tanım |
| Metot | Planlama, tasarım, uyarlama, işletme ve değerlendirme aşamalarında belirlenen yöntemlerin anlaşılmaması veya yanlış uygulanması. |
| İletişim | BPM paydaşları ile süreç kullanıcıları arasında iletişim kurulamaması. Her formdaki iletişim için (sohbet, toplantı, rapor, eğitim vs. vs.) geçerlidir. |
| Bilgi | Aşamalar içindeki durumlar ile ilgili ya da aşamalar arası geçişlerde oluşan durumlar ile ilgili yeterince bilgi oluşmuyor olması. |
| Değişim Yönetimi | Değişiklikleri kayıt altına alıp, yerine getirmek konusunda yetkinlik eksikliği |
| Sistem / Teknoloji | Teknolojinin uygun olmaması ya da insanların teknolojiyi kullanamaması |
| Liderlik / Yönetim | Güçlü liderlik gösterememe ve proje yönetimi pratiklerini doğru uygulayamama |
| Kaynak/Yetenek | İlgili yetenek kümelerine sahip olmama |
| Strateji | Bütün BPM paydaş, fonksiyon ve bileşenlerini dahil eden bir vizyon, hedef ve fonksiyon kümesi oluşturamama |
Riskler ve Risk Sınıfları Eşleştirmesi
| Risk Faktörü | Yaşam Döngüsü Riskleri |
| Metot | · Uygun olmayan süreç analiz ve tasarım yöntemleri [1], [2] · Problemden Çözüme, Çözümden Uyarlamaya transferde uygun olmayan ilişkilendirme yöntemleri [1,2], [2,3]· Uygun olmayan süreç modelleme yöntemleri [2,3]· Uygun olmayan süreç uyarlama yöntemleri [3]· Uygun olmayan değerlendirme yöntemleri [5]· Değerlendirme ve ölçüm yöntemleri arasında tutarsızlık [5],[6]· Uygun olmayan geribildirim mekanizması [5,2] |
| İletişim | · Hedeflerin hatalı iletilmesi [1,2] · Paydaşlar arası iletişim olmaması [Hepsi]· Tasarım ve uyarlamada kimsenin bilmediği kabullenmeler, varsayımlar [1,2,3] |
| Bilgi | · Bilginin yanlış kullanılması [1,2], [4,6], [5] · Yetersiz bilgi [Hepsi]· Geçersiz bilgi [1,2], [2,3], [5,2]· Geçersiz bilgi tercümesi [6,5] |
| Değişim Yönetimi | · İş tanımları ve fonksiyonların değiştirilememesi [1,2] · Değişikliklerin yapılamaması [2]· Problemlerin tespit edilememesi [5,2]· Yapılan değişikliklere reaksiyon gösterilememesi [Hepsi] |
| Sistem / Teknoloji | · Teknolojinin kabul görmemesi [Hepsi] · Teknolojinin düzgün kullanılamaması [Hepsi]· Teknolojinin esnek olmaması [Hepsi]· Teknolojinin uyumlu olmaması [Hepsi]· Teknolojinin ölçeklenebilir olmaması [Hepsi] |
| Liderlik / Yönetim | · Liderlik ve yönetici gücün etkin olmaması [Hepsi] · Yönetimin tutarlı olmaması [Hepsi]· Liderlik ve yönetici gücün hiç olmaması [Hepsi] |
| Kaynak/Yetenek | · Kaynak ve yeteneğin olmaması [Hepsi] · Kaynak ve yeteneğin doğru şekilde kullanılmaması [Hepsi]· Kaynak ve yeteneğin devreye sokulamaması [Hepsi] |
| Strateji | · Strateji tanımının eksik olması [Hepsi] · Strateji tanımının muğlak olması [Hepsi]· Stratejinin tanımlanmamış olması [Hepsi] |
Evet, şimdi kendimize bir sınıflandırma yaptığımıza göre bu kategorileri yaşam döngüsü aşamaları ile ilişkilendirebiliriz. Yukarıdaki tabloda yaşam döngüsü risk örnekleri sonunda bulunan rakamlar yaşam döngüsü aşamalarına işaret etmektedir.
1.Organizasyonel Analiz
2.Tasarım
3.Uyarlama
4.İşletme
5.İzleme
6.Denetim
Tabloyu incelediğimizde Strateji, Kaynak/Yetenek, Liderlik/Yönetim, Sistem/Teknoloji kategorilerindeki riskler tüm yaşam döngüsü aşamalarında etkili oluyorlar. Bu da bu risklerin BPM yaşam döngüsü projesinin ilerleme istikametine dik durdukları anlamına gelir.
Sonuç olarak bir BPM Proje Yöneticisinin proje başlangıcından önce bu tür risklere odaklanmasının mantıklı olduğunu gösterir. Diğer kategorilere giren risklerin azaltılması biraz ertelense de projenin ilerlemesine etkisi nispeten daha hafif olacaktır.
Referanslar
Davenport, T. (1993). Process Innovation. Boston: Business School Press.
Scott, J. V. (2000). Managing Risks in Enterprise Systems Implementations. Communications of the ACM.
Summer, M. (2000). Risk Factors in Enterprise-wide/ERP projects. Journal of Information Technology.
zue Muehlen, M., & Rosemann, M. (2005). Integrating Risks in Business Process Models. Sydney, Australia: Proceedings of the 2005 Australian Conference on Information Systems (ACIS 2005).
