Categories
Governance/Management of IT

STOPPER itu bernama IT Governance

Seorang manajer TI senior suatu hari mengatakan: “Direktur kami merasa IT Governance di sini dianggap jadi STOPPER. Padahal seharusnya dia hanya menjadi rambu-rambu ya?”

***

Kalau di sepakbola, stopper adalah posisi di depan kiper. Tugasnya adalah menghalau bola yang mau masuk gol, pertahanan terakhir sebelum kiper. Itu fungsi kuno stopper. Tapi fungsi ini jauh lebih strategis jika diposisikan sebagai libero modern, seperti yang diperankan legendaris Franz Beckenbauer atau Lothar Mathaeus. Salah satu sebab terpenting Jerman bisa juara dunia 1974 dan 1990 adalah adanya peran libero modern di kedua legendaris itu.

Tapi mungkin yang dimaksud STOPPER oleh sang direktur tadi adalah IT Governance yang diimplementasikan malah menjadi penghambat bisnis: TI lamban mengikuti kebutuhan bisnis, ada masalah kritikal ternyata lama lama resolusinya, dsj.

Beberapa hal ini mungkin jadi penyebabnya:

1. Struktur governance yang tidak pas

Setidaknya ada 2 layer dalam struktur governance: strategis dan operasional. Pada level strategis, ada strategy committee dan steering committee. Ini biasanya jika tidak efektif akan berdampak terhadap direction yang tidak kuat atas IT mau dibawa kemana. Yang banyak terjadi adalah unit-unit bisnis bikin tim TI sendiri-sendiri, sebagai akibat pimpinan tiap business owner tidak percaya lagi sama TI. Padahal keputusan itu semakin membuat masalah makin besar. Atau sederhananya: pimpinan pokoknya pengin IT memberikan kontribusi, tetapi involvement kurang memadai.

Pada level operasional, kemungkinan ada 2 sebab: posisi TI di struktur organisasi yang tidak memadai atau struktur organisasi TI yang tidak memadai. Posisi TI yang tidak memadai misalnya adalah posisi dia yang tak setara dengan business owner lain. Struktur organisasi TI yang tidak memadai ada beberapa sebab lagi: jobdesc yang tumpang tindih atau skillset SDM yang tidak memadai.

2. Proses governance yang terlalu birokratis dan kompleks

Walaupun kebutuhan akan proses governance antara organisasi TI kompleks dengan sederhana adalah sama, tetapi bentuknya akan berbeda, level kompleksitasnya akan berbeda. Sebagai misal OGC (yang menerbitkan ITIL) merilis buku tentang ITSM for Small & Medium Business. Dulu juga ada COBIT Quickstart yang salah satunya ditujukan untuk Small & Medium Business. Untuk kompleksitas berbeda, idealnya level kompleksitas program governance (kebijakan, standar, prosedur dan panduan) juga harus berbeda. Kalau level organisasi sederhana menggunakan program governance terlalu kompleks, maka ruh governance tidak akan terasa, karena tiap hari orang TI lebih disibukkan untuk ngejar kepatuhan atas program governance tersebut.

Beberapa hal berikut ini dapat dipertimbangkan agar program governance yang kita susun bisa pas dengan kompleksitas organisasi.

1. Memulai dengan mencari metriks sukses apa yang mau dicapai

Kondisi paling nyaman itu adalah kondisi paling tidak diatur. Orang TI bisa melakukan pekerjaannya sesuai dengan keinginannya masing-masing. Tapi itu tidak mungkin kan? Kecuali kalau kita hanya bekerja seorang diri. Nah, program governance membuat kadar kenyamanan itu berkurang. Karena itu dibutukan motivasi internal tersendiri untuk mengerjakannya. Dan itu bisa dengan penetapan metrik sukses itu. Kalau di organisasi, biasanya ini adalah KPI yang bisa dikorelasikan dengan remunerasi.

Bahan untuk menetapkan metrik kinerja ini bisa merujuk kepada cara kerja IT Balanced Scorecard. Di framework ini, metrik kinerja bisa dilihat dalam 3 domain: Strategic, Development dan Operational. Silakan baca papernya di sini: The-Balanced-Scorecard-and-IT-Governance. Atau bisa menggunakan 4 domain seperti di teori asal BSC: http://www.isaca.org/Journal/Past-Issues/2000/Volume-2/Pages/The-IT-Balanced-Scorecard-A-Roadmap-to-Effective-Governance-of-a-Shared-Services-IT-Organization.aspx

Misal ini, ada satu perusahaan yang dalam stream proses bisnisnya banyak fraud. Dan mereka tahu betul, kalau diimplementasikan TI yang benar maka fraud tadi bisa ditekan secara signifikan. Maka ini bisa menjadi metrik di domain strategis. Tinggal ditarik saja, ke domain development dan operation. Jadi siapa pun orang di development atau operation akan tahu apa yang sesungguhnya dikejar dengan capek-capek implementasi program governance itu.

2. Fokus pada prinsip dan tujuan untuk setiap domain dan proses

Setiap proses governance itu pasti punya prinsip dan tujuan utama. Dari sana bisa dicari kontrol utamanya seperti apa. Kalaupun di luaran sana ada banyak contoh workflow untuk mendeskripsikan proses itu, selalu ingat akan prinsip dan tujuan utama setiap proses. Untuk setiap proses harus didesaian sesederhana mungkin, tapi tetap comply. Kalau kita kesulitan, bayangkan saja kita di posisi yang akan mengerjakan. Pusing atau tidak nanti menjalankan seperti itu. Sampai dengan membuat blok diagram, usahakan sesederhana mungkin dan mudah dipahami.

Keep focus on the good practice compliance, but don’t forget the organizational & human factor!! 

3. Buat “Program Governance Map”

Kalau bisa kita buat semacam “Program Governance Map”. Map ini akan memberikan panduan high level tentang hubungan satu SOP dengan SOP lainnya. Bagaimana urutan sekuensial antar SOP jika ada. Mana parent-nya dan mana child-nya, jika ada struktur kebijakan, standar, prosedur dan panduan.

Ini penting untuk memastikan orang-orang TI tidak tersesat di belantara SOP. Ini penting juga untuk memastikan integrasi proses seluruh lini di TI. Kalau tidak, maka yang terjadi malah alienasasi fungsi-fungsi TI. Dan itu berbahaya….

4. Bundel, bundel dan bundel sesederhana mungkin

COBIT 5 punya 37 proses: 5 proses governance dan 5 proses manajemen. Yang paling gampang, ya kita buat 37 SOP. Beres….. Tidak ada yang salah dengan hal itu. Tapi kalau bisa dibundel, bundellah dengan cara penyajian yang lebih sederhana. Kalau bisa sesuaikan dengan kelompok fungsional yang ada di struktur organisasi.

Misal: Kalau Project Management dan SDLC bisa diintegrasikan, itu akan sangat membantu. Dipisahkan itu bagus untuk dilihat, tapi sulit untuk diimplementasikan. Misalnya hal sederhana saja, yaitu timeline kapan kontrol harus masuk di fase-fase SDLC dan harus ngecek apa? Seringkali SOP kehilangan makna dari konteksnya lemah.

5. Walk-Through sebelum disahkan

Yang terakhir, sebelum program governance ini disahkan maka lakukan Walk-Throug dengan yang akan menjalankan. Persilakan ngomong apa pun mereka itu, dengan fokus pada kemudahakan implementasi tapi tetep memenuhi persyaratan good practice compliance.

 

Leave a Reply