RACI Matrisi Nedir, Nasıl Hazırlanır?
- Fatih Yüksektepe

- 9 Tem
- 8 dakikada okunur

Projelerde işler genellikle aynı sebepten tıkanır: kimin ne yapacağı, kimin karar vereceği belli değildir. Kime danışılacağı, kimin bilgilendirilmesi gerektiği de çoğu zaman havada kalır. Bu belirsizlik uzadıkça proje yavaşlar, aynı iş birkaç kez yapılır ya da hiç kimse yapmaz. Toplantıdan çıkarken “bunu kim üstlenecekti?” sorusuna net bir cevap veremiyorsanız, aslında sorun görev listesinde değil, rol tanımlarındadır. RACI matrisi tam da bu noktada devreye giriyor.
Ben de yıllar içinde yürüttüğüm ya da içinde bulunduğum projelerde bu belirsizliğin nelere mal olduğunu defalarca gördüm. Küçük bir ekipte bile “onu ben yaparım sanmıştım” ya da “kimse bana sormadı, ben de bilmiyordum” cümleleri iş kaybına, gecikmeye, bazen de ekip içi gerginliğe yol açabiliyor. Sorun genelde insanların kötü niyetli ya da tembel olması değil; kimin hangi rolü taşıdığının hiç yazılı hale getirilmemiş olması. RACI, bu görünmez boşluğu kağıda döken basit ama etkili bir araç.
RACI Matrisi Nedir?
RACI, dört rolün baş harflerinden oluşuyor: Responsible, Accountable, Consulted, Informed. Bu dört rolün açılımını ve projede ne anlama geldiğini aşağıdaki tabloda topladım.
Rol | Açılımı | Anlamı |
|---|---|---|
R | Responsible (Sorumlu) | İşi fiilen yapan, görevi uygulayan kişi ya da kişiler. Bir görevde birden fazla Responsible olabilir. |
A | Accountable (Hesap Veren) | Sonuçtan hesap veren, onay makamı olan kişi. Her görevde mutlaka tek kişi olmalı. |
C | Consulted (Danışılan) | Karar alınmadan önce görüşüne başvurulan, iki yönlü iletişim kurulan uzman ya da taraflar. |
I | Informed (Bilgilendirilen) | Süreç ya da sonuçtan haberdar edilmesi yeterli olan, tek yönlü iletişim kurulan kişiler. |
Responsible ile Accountable sık karıştırılır ama aralarındaki fark net: Responsible işi bizzat yapan kişidir, birden fazla kişi olabilir; Accountable ise o işin sonucundan hesap veren, onay makamı olan kişidir ve mutlaka tek kişi olmalıdır. Accountable kişi işi bizzat yapmayabilir ama bir sorun çıktığında ilk aranan, performansı sorgulanan kişi odur. Consulted ile iki yönlü bir iletişim vardır; onlara soru sorulur, onlar da geri bildirim verir. Informed ile ise iletişim tek yönlüdür; bir e-posta ya da güncelleme yeterlidir, onlardan bir onay ya da görüş beklenmez. Bu dört rolü bir tabloya dökünce, projedeki her görev için kimin hangi rolü üstlendiği tek bakışta görülür.
RACI'yi bir organizasyon şemasıyla karıştırmamak gerekir. Organizasyon şeması kimin kime rapor verdiğini gösterir; RACI ise belirli bir görev ya da karar bazında kimin ne yaptığını gösterir. Aynı kişi bir görevde Responsible, başka bir görevde sadece Informed olabilir; hiyerarşideki pozisyonu değişmese de projedeki rolü görevden göreve değişir. Bu yüzden RACI, iş tanımlarının ya da unvanların yerini almaz, onları tamamlar.
Neden Önemlidir?
Bunun neden bu kadar önem taşıdığını anlamak zor değil. Roller netleşince kim ne yapacak, kim karar verecek belli olur; aynı görevi iki kişinin üstlenmesi ya da hiç kimsenin sahiplenmemesi engellenir. Hesap verebilirlik artar, çünkü her işin bir sahibi vardır. Kime danışılacağı, kimin bilgilendirileceği baştan netleştiği için iletişim de kolaylaşır; gereksiz toplantılar ve “bunu neden bana sormadınız” tartışmaları azalır.
Özellikle çok paydaşlı, çapraz fonksiyonlu projelerde bu fayda katlanarak artıyor. Birden fazla departmanın, dış tedarikçilerin ya da müşteri tarafının işin içinde olduğu projelerde herkesin kendi rolünü bilmesi, işin akışını doğrudan etkiliyor. Uzaktan çalışan ya da farklı zaman dilimlerinde bulunan ekiplerde de RACI matrisi, yüz yüze konuşarak halledilebilecek belirsizlikleri yazılı hale getirdiği için özellikle değerli. Kimseye “bunu sen mi yapacaktın, ben mi?” diye soru sormak zorunda kalmadan, tabloya bakmak yeterli oluyor.
RACI matrisinin bir başka faydası da yeni katılan ekip üyeleri için sağladığı netlik. Projeye sonradan dahil olan biri, uzun uzun kim kimdir sorularını sormak yerine tabloya bakarak kimle konuşması, kimden onay alması gerektiğini hızlıca öğrenebiliyor. Bu da özellikle büyüyen ekiplerde ya da personel değişiminin sık yaşandığı projelerde ciddi bir zaman kazancı sağlıyor.
RACI Matrisi Nasıl Hazırlanır?
RACI matrisi hazırlamak aslında birkaç adımdan ibaret, ama her adımın kendi içinde dikkat edilmesi gereken noktaları var. Önce projedeki tüm görevler adım adım listelenir. Burada görevleri ne çok genel (“yazılım geliştirme” gibi tek satır) ne de çok ayrıntılı (her fonksiyonu ayrı satır yapmak) tutmak gerekir; ideal olan, bir kişinin sorumluluğunu net şekilde tarif edebilecek kadar somut ama tabloyu şişirmeyecek kadar öz görev tanımları.
Sonra projede yer alan kişiler ya da roller tabloya eklenir. Küçük ekiplerde isim isim gitmek mümkün, ama büyük organizasyonlarda kişi yerine rol bazlı ilerlemek (örneğin “Proje Yöneticisi”, “BT Güvenlik” gibi) daha sürdürülebilir oluyor; çünkü kişi değişse bile rol aynı kalıyor ve matrisi baştan yazmaya gerek kalmıyor.
Ardından her görev için kimin R, kimin A, kimin C, kimin I olduğu belirlenir. Bu aşamada acele etmemek gerekir; her hücreyi doldururken “bu kişi gerçekten bu işi mi yapıyor, yoksa sadece unvanı öyle olduğu için mi buraya yazıyorum?” sorusunu sormak faydalı. Burada dikkat edilmesi gereken önemli bir nokta var: her görevde tek bir A olmalı; fazla ya da eksik roller varsa matris yeniden dengelenmeli. Bir görevde iki Accountable varsa, kriz anında kimin son sözü söyleyeceği belirsiz kalır; bu da RACI'nin çözmeye çalıştığı sorunu yeniden yaratır.
Son olarak matris ekiple paylaşılır ve roller üzerinde mutabakat sağlanır. Bu adım atlanırsa matris sadece onu hazırlayan kişinin kafasındaki bir belge olarak kalır. Ekiple birlikte gözden geçirmek, kimsenin fazla yük altında kalmadığını, kimsenin de dışarıda bırakılmadığını teyit etmek için önemli bir fırsat. Özellikle Accountable rolüne atanan kişilerin bu sorumluluğu kabul ettiğini açıkça belirtmesi, ileride “ben bunu üstlenmemiştim” tartışmalarının önüne geçiyor.
Örnek RACI Matrisi: Entegratör Bir Bilişim Firmasının Projesi
Konuyu somutlaştırmak için Türkiye IT sektöründen bir örnek üzerinden gidelim. Entegratör bir bilişim firması, kurumsal bir müşterisi için veri merkezi altyapısını modernize edip yeni bir yazılımı bu altyapıyla entegre eden bir proje yürütüyor olsun. Böyle projelerde genelde dört taraf işin içinde olur: entegratör firmanın proje yöneticisi, sistem mühendisi, ağ ve güvenlik uzmanı, bir de müşteri tarafındaki BT sorumlusu. Bu tür projelerde işler genelde altı ana görev etrafında ilerler: kapsam belirleme, altyapı kurulumu, ağ/güvenlik yapılandırması, yazılım entegrasyonu, testler ve devreye alma.
Görev | Proje Yöneticisi | Sistem Mühendisi | Ağ/Güvenlik Uzmanı | Müşteri BT Sorumlusu |
Kapsam ve Gereksinim Analizi | A | R | C | C |
Sunucu ve Depolama Altyapısı Kurulumu | A | R | C | I |
Ağ ve Güvenlik Yapılandırması | A | C | R | I |
Yazılım Entegrasyonu | A | R | C | C |
Güvenlik ve Performans Testleri | A | C | R | C |
Kullanıcı Kabul Testi (UAT) ve Devreye Alma | A | I | I | R |
Kapsam ve gereksinim analizinde proje yöneticisi sürecin sahibi, yani A; sistem mühendisi analizi fiilen yürüten kişi, yani R; ağ/güvenlik uzmanı ve müşteri BT sorumlusu ise görüş bildiriyor, C. Sunucu ve depolama altyapısı kurulumuna geçildiğinde iş yine sistem mühendisine geçiyor, müşteri BT sorumlusu artık sadece bilgilendiriliyor, çünkü bu aşamada onun aktif katkısına ihtiyaç yok. Ağ ve güvenlik yapılandırmasında ise roller değişiyor: artık ağ/güvenlik uzmanı R oluyor, sistem mühendisi danışılan taraf haline geliyor. Testler aşamasında da benzer bir el değişimi var; güvenlik ve performans testlerinde ağ/güvenlik uzmanı işi yürütüyor, sistem mühendisi ona danışmanlık yapıyor.
En kritik aşama ise kullanıcı kabul testi ve devreye alma; burada R rolü müşteri BT sorumlusuna geçiyor, çünkü sistemin gerçekten işe yarayıp yaramadığına dair son sözü söyleyecek olan taraf müşteri. Entegratör firmanın proje yöneticisi ise projenin başından sonuna kadar her aşamada A olarak kalıyor; teslimatın sözleşmeye, zamana ve bütçeye uygun ilerlemesinden o sorumlu. Bu örnek, entegratör-müşteri ilişkisinde RACI'nin neden bu kadar kritik olduğunu gösteriyor: taraflardan biri (entegratör) işi teknik olarak yürütürken, diğer taraf (müşteri) belirli aşamalarda onay ve kabul mercii olarak devreye giriyor; bu geçişlerin baştan netleşmemiş olması, projelerde en çok karşılaşılan gecikme ve anlaşmazlık kaynaklarından biri.
RACI Matrisinin Avantajları
Doğru kurulmuş bir RACI matrisi birkaç şeyi aynı anda sağlıyor. Şeffaflık getiriyor, çünkü herkesin rolü netleşiyor ve kimse “ben bilmiyordum” diyemiyor. Çakışmaları ve belirsizlikleri ortadan kaldırdığı için verimliliği artırıyor; aynı işin iki kişi tarafından tekrar tekrar yapılması ya da hiç yapılmaması riski azalıyor. Kimden onay alınacağı baştan belli olduğu için karar süreçlerini hızlandırıyor; onay bekleyen bir iş, doğru kişiye ilk seferde gidiyor. Sorumluluğu doğru kişilere dağıttığı için de iş yükünü dengeliyor; bir kişinin üstünde çok fazla A rolü birikmesi fark edilip düzeltilebiliyor.
Bunlara ek olarak, RACI matrisi proje sonrası değerlendirmelerde de işe yarıyor. Bir şey yanlış gittiğinde “bu kararı kim vermişti, kime danışılmıştı?” sorusunun cevabı tabloda hazır duruyor; bu da suçlu aramaktan çok, sürecin neresinde aksadığını anlamaya yarıyor. Ekipler zamanla RACI matrisini sadece bir planlama aracı değil, bir öğrenme aracı olarak da kullanmaya başlıyor.
Dikkat Edilmesi Gereken Noktalar
Matrisi hazırlarken birkaç tuzaktan kaçınmakta fayda var. A rolü kesinlikle tek kişide kalmalı; bir işten birden fazla kişi hesap veremez, aksi halde kriz anında “son söz kimin?” sorusu yeniden gündeme gelir. C rolünü gereğinden fazla kişiye dağıtmak da işleri yavaşlatır; herkese danışmaya kalkınca karar alma süreci uzar ve basit kararlar bile haftalar sürebilir. Aynı şekilde I rolünü de abartmamak gerekir; gereksiz yere herkesi her konudan bilgilendirmek zaman kaybından başka bir şey değildir ve önemli bilgiler önemsiz olanların arasında kaybolabilir.
Bir diğer yaygın hata, matrisi tek bir kişinin, genelde proje yöneticisinin, masasında hazırlayıp ekiple hiç paylaşmamak. Bu durumda matris kağıt üzerinde doğru görünse de gerçek hayatta uygulanmıyor, çünkü insanlar kendilerine biçilen rolden haberdar bile değil. Matrisi ekiple birlikte oluşturmak, en azından taslak haliyle paylaşıp geri bildirim almak, uygulanabilirliği ciddi şekilde artırıyor.
Son olarak RACI matrisi bir kere hazırlanıp rafa kaldırılacak bir belge değil; proje ilerledikçe güncellenmesi gereken, yaşayan bir doküman. Yeni bir görev eklendiğinde, bir kişi ekipten ayrıldığında ya da roller değiştiğinde matrisin de güncellenmesi gerekiyor. Güncel tutulmayan bir RACI matrisi, hiç olmamasından bile daha yanıltıcı olabilir; çünkü ekip artık geçerli olmayan bir bilgiye güvenerek hareket eder.
Ekiplerin RACI ile ilk tanıştıklarında yaptığı bir hata da, matrisi doldururken herkesi memnun etmeye çalışmak. Bir görevde beş kişiye birden C rolü vermek, kimseyi dışarıda bırakmamak adına cazip görünse de pratikte kararı yavaşlatan bir kalabalığa dönüşür. Burada asıl soru “kim gücenir” değil, “bu kararı vermek için gerçekten kimin görüşüne ihtiyacım var” olmalı. Aynı mantık I rolü için de geçerli; bir güncellemeyi şirketteki herkese göndermek yerine, gerçekten o bilgiden etkilenecek kişileri seçmek, hem zaman kazandırıyor hem de önemli bilgilerin gürültüye karışmasını önlüyor.
RACI'nin Farklı Versiyonları
RACI'nin zaman içinde birkaç türevi ortaya çıktı. RASCI, RACI'ye bir de “Support” (destek veren) rolünü ekliyor; Responsible kişiye iş sırasında pratik destek sağlayan ama işin sorumluluğunu taşımayan kişileri ayrıca işaretlemek isteyen ekipler bu versiyonu tercih ediyor. DACI ise Driver, Approver, Contributor, Informed rollerinden oluşuyor ve daha çok ürün kararlarında, özellikle teknoloji şirketlerinde kullanılıyor; Driver süreci yürüten kişi, Approver ise RACI'deki Accountable'a benziyor. RACI-VS gibi bazı versiyonlar ise Verifier ve Signer rollerini ekleyerek kalite kontrol ve resmi onay süreçlerini ayrıştırıyor. Hangi versiyonun kullanılacağı, projenin karmaşıklığına ve organizasyonun ihtiyacına göre değişiyor; çoğu ekip için klasik RACI, fazla karmaşıklaştırmadan yeterli netliği sağlıyor.
RACI Matrisi Hangi Araçlarla Tutulur?
Küçük ekipler için basit bir Excel ya da Google Sheets tablosu genelde yeterli oluyor; satırlara görevler, sütunlara kişiler yazılıyor ve hücrelere R, A, C, I harfleri giriliyor. Daha büyük ve karmaşık projelerde Jira, Asana, Monday, Trello gibi proje yönetim araçlarının içine RACI bilgisini görev alanlarına ya da özel etiketlere ekleyen ekipler var. Bazı kurumlar ise RACI matrisini kurumsal wiki sayfalarında (Confluence gibi) tutuyor, böylece hem güncel kalıyor hem de tüm ekip aynı kaynağa erişebiliyor. Araç ne olursa olsun, önemli olan matrisin kolayca erişilebilir olması ve düzenli aralıklarla gözden geçirilmesi.
RACI Matrisinin Sınırları
RACI güçlü bir araç ama her derde deva değil. Çok hızlı hareket eden, sürekli değişen küçük ekiplerde (örneğin üç dört kişilik bir girişim ekibinde) resmi bir RACI matrisi bazen gereğinden fazla bürokrasi gibi hissettirebilir; herkes zaten kimin ne yaptığını biliyorsa tabloya dökmek ekstra bir iş yükü olarak görülebilir. Böyle durumlarda matrisi sadece kritik, riskli ya da çok paydaşlı kararlar için kullanmak, her ufak görev için doldurmamak daha mantıklı olabilir.
RACI ayrıca “nasıl” sorusuna cevap vermiyor; sadece “kim” sorusuna cevap veriyor. Bir görevin hangi yöntemle, hangi standartlarla yapılacağı, hangi araçların kullanılacağı ayrı bir konu ve bunun için süreç dokümanlarına, iş akış şemalarına ya da kontrol listelerine ihtiyaç var. RACI matrisini bu belgelerin yerine değil, tamamlayıcısı olarak düşünmek gerekir. Aksi halde ekip “rolümüz belli ama işi tam olarak nasıl yapacağız?” sorusuyla baş başa kalabilir.
Bir diğer sınırlama, RACI'nin statik bir görüntü sunması. Karmaşık, birbirine bağımlı çok sayıda görevin olduğu büyük programlarda tek bir RACI tablosu her şeyi göstermeye çalışırsa dev ve okunması zor bir tabloya dönüşebilir. Böyle durumlarda projeyi alt parçalara bölüp her parça için ayrı, daha yönetilebilir matrisler hazırlamak; sonra bunları üst düzeyde birleştirmek daha sağlıklı sonuç veriyor.
RACI matrisi, özellikle çok paydaşlı projelerde karmaşayı önlemenin en pratik yollarından biri. Doğru kurulduğunda hem proje yönetiminin kalitesini yükseltiyor hem de ekip içindeki iletişimi güçlendiriyor. Karmaşık bir araç değil; birkaç saat ayırıp doğru sorularla (kim yapıyor, kim onaylıyor, kime danışılıyor, kim bilgileniyor) doldurulan bir tablo. Ama bu basitliğin arkasında, projelerin en çok zaman kaybettiği alanlardan birine, yani belirsizliğe, doğrudan çözüm üreten güçlü bir mantık yatıyor. Bir sonraki projenize başlarken görev listesini çıkardığınız gün, yanına bir de RACI sütunu eklemeyi deneyin; küçük bir alışkanlık gibi görünse de, ilerleyen haftalarda kaç tartışmanın önüne geçtiğini fark edince şaşırabilirsiniz. Ve unutmayın, mükemmel bir matris hazırlamak zorunda değilsiniz; ilk versiyon eksik ya da hatalı olsa bile, ekiple oturup birlikte düzeltmek, hiç böyle bir tartışma yapmamaktan çok daha değerli. Zamanla, matrisi güncellemek ekip için doğal bir refleks haline gelecek ve o zaman RACI artık bir formalite değil, projenin gerçek işleyişini yansıtan canlı bir kılavuz olacaktır.


Yorumlar