Mengenal RACI/RASCI

Dalam organisasi, tentu kita mengenal struktur organisasi.

Dan cara menjalankan organisasi, adalah dengan memetakan peran dan tanggungjawab dari struktur tersebut.

Pada beberapa kesempatan, kami menemukan bahwa pemetaan ini menjadi penting. Karena siapa, mengerjakan apa, dan apa tanggungjawabnya adalah 3 hal yang perlu didefinisikan sejak awal. Pendekatan ini juga dapat digunakan dalam kegiatan manajemen proyek.

Tanpanya, maka suatu proses bisnis tidak akan berjalan sempurna. Saling tumpang tindih atau bahkan terbengkalai sama sekali.

Metode RACI/RASCI

Barangkali di antara kita ada yang pernah mengalami kondisi:

• Eh, itu bukan pekerjaan saya. Itu pekerjaan si X!
• Kegiatan A terlambat dari jadwal. Siapa yang harus mengerjakan laporan akhir?
• Tim pengembang (developer) sudah selesai mengerjakan aplikasi versi awal. Siapa yang harus kontak pengguna (user) untuk ikut hadir dalam pengujiannya (User Acceptance Test / UAT)?
• Dan seterusnya.

Maka pendekatan RACI/RASCI dapat menolong kita untuk terhindar dari kondisi diatas. (Kadang ada organisasi yang menggunakan pendekatan RACI tanpa S)

Apa kepanjangannya?

1. R (Responsible) adalah pihak yang melaksanakan kegiatan (misal kegiatan A)
2. A (Accountable) adalah pihak yang bertanggungjawab terhadap kegiatan A
3. S (Support) adalah pihak yang mendukung kegiatan A
4. C (Consult) adalah pihak yang dikonsultasikan untuk kegiatan A
5. I (Inform) adalah pihak yang diinformasikan terhadap perkembangan kegiatan A

Contoh Implementasi

Mari kita ambil contoh kegiatan pengembangan aplikasi. Dalam kegiatan ini, beberapa peran yang setidaknya ada adalah:

• Analis
• Pemimpin proyek
• Tenaga Ahli / Narasumber (subject matter expert)
• Pengembang (developer)
• Penguji (tester/quality assurance/quality control)
• System Administrator
• Pengguna (user)

Aktivitas yang setidaknya ada adalah:

• Perencanaan dan analisis
• Perancangan (mock-up / prototype)
• Pemrograman (coding)
• Pengujian (testing, UAT, dll)
• Penggelaran (deployment)
• Pemeliharaan (maintenance)

Dari gambar di atas, maka terlihat siapa yang bertanggungjawab terhadap masing-masing aktivitas. Dengan pemetaan seperti ini, diharapkan tidak ada yang saling menyalahkan, tidak peduli atau cuek terhadap aktivitasnya.

• Di beberapa organisasi, peran Pengembang dibagi lagi menjadi lebih spesifik. Misalnya personil/tim yang mengurus User Interface (UI) / User eXperience (UX), Web developer dan mobile developer.

Apakah boleh jika ada lebih dari 1 Responsible per aktivitas?

Boleh saja.

Namun setidaknya pastikan bahwa 1 aktivitas tidak memiliki 2 Accountable. Sebab Akuntabel adalah penanggungjawab. Jika dalam 1 aktivitas ada > 1 penanggungjawab, maka berikutnya ada potensi ketidakjelasan jalur pelaporan pekerjaan.

Kemudian bisa jadi dalam 1 aktivitas, tidak ada S,C,I. Tidak masalah. Namun pastikan selalu ada R dan A dalam setiap aktivitas.

Serta di beberapa organisasi, mereka menghindari peran A dan R dipegang oleh 1 orang yang sama. Karena hal tersebut dapat berarti tidak adanya dual control.

Memeriksa Tabel RASCI

Saat memeriksa tabel RASCI berdasarkan aktivitas, berikut adalah hal-hal yang dapat menjadi perhatian.

• Memeriksa tabel RASCI berbasis peran (vertikal)

• Memeriksa tabel RACI berbasis aktivitas (horizontal)

Apakah aman jika tidak mengikuti RASCI?

RASCI hanya salah satu metode pemetaan peran dan tanggungjawab. Tentu selalu ada alternatif metode lain untuk melakukan pemetaan ini.

Setidaknya, dengan menggunakan RASCI maka pemetaan dan pembagian peran serta tanggungjawab menjadi jelas.

Ujungnya para anggota tim bisa bekerja dengan nyaman (work in peace) serta tidak berakhir dengan saling menyalahkan si A, si B, si C dan seterusnya.

Tetap semangat!