[:id]
STOPPER is 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.
Articles form http://basukirahmad.staff.telkomuniversity.ac.id [:en]STOPPER is IT Governance
A senior IT manager one day said: “Our Director feels IT Governance here is considered STOPPER. Where should he just be the signs? ”
***
If in football, stopper is a position in front of the goalkeeper. His job is to deny the ball who want to go in goals, the last defense before the goalkeeper. It’s an old-fashioned stopper. But this function is much more strategic if it is positioned as a modern libero, such as the legendary Franz Beckenbauer or Lothar Mathaeus. One of the most important reasons Germany could be world champion of 1974 and 1990 is the role of modern libero in both legendary.
But maybe the STOPPER meant by the director was IT Governance which is implemented even a business barrier: IT is slow to follow business needs, there is a critical problem it turns out its long duration of resolutions, dsj.
Some of these things might be the cause:
1. An inappropriate governance structure
There are at least two layers in the governance structure: strategic and operational. At the strategic level, there is a strategy committee and steering committee. This is usually if not effective will have an impact on the direction that is not strong on IT will be taken where. What is happening is that business units make their own IT teams, as a result of the leadership of each business owner no longer trust IT. Though the decision is increasingly making the problem even greater. Or simply: the main leadership pengin IT contribute, but involvement is not adequate.
At the operational level, there may be 2 causes: IT positions in an inadequate organizational structure or inadequate IT organizational structure. Inadequate IT position for example is her position that is not equivalent to other business owner. Inadequate organizational structure of IT there are several more reasons: overlapping jobdesc or insufficient HR skillset.
2. The governance process is too bureaucratic and complex
Although the need for a complex governance process between a complex IT organization is the same, but the shape will be different, the level of complexity will be different. For example OGC (which publishes ITIL) released a book about ITSM for Small & Medium Business. There used to be COBIT Quickstart one of which is intended for Small & Medium Business. For different complexities, ideally the level of complexity of governance programs (policies, standards, procedures and guidelines) should also be different. If a simple organizational level using a governance program is too complex, then the spirit of governance will not be felt, because every day IT people are more preoccupied to pursue compliance with the governance program.
Some of the following can be considered so that our governance program can fit with the complexity of the organization.
1. Start by finding what successful metrics to accomplish
The most convenient conditions are the least regulated conditions. IT people can do their work according to their own desires. But that’s not possible right? Unless we only work alone. Well, the governance program makes the comfort level less. Because it is necessary internal motivation to do it. And that could be with the establishment of the successful metrics. If in the organization, usually this is a KPI that can be correlated with remuneration.
The materials to define these performance metrics can refer to how the IT Balanced Scorecard works. In this framework, performance metrics can be viewed in 3 domains: Strategic, Development and Operational. Please read the paper here: The-Balanced-Scorecard-and-IT-Governance. Or it could use 4 such domains in the origin theory of 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
For example, there is one company that is in the stream of its business processes is a lot of fraud. And they know very well, if implemented the right IT then the fraud was able to be pressed significantly. Then this could be a metric in the strategic domain. Just stay withdrawn, to domain development and operation. So whoever the person in development or operation will know what really pursued with the tired implementation of the governance program.
2. Focus on principles and goals for each domain and process
Every governance process must have principles and main goals. From there can be sought control main like what. Even if out there are many examples of workflows to describe the process, always remember the principles and main goals of each process. For each process should be as simple as possible, but still comply. If we have trouble, just imagine we are in a position to do. Dizziness or not will run like that. Up to make the block diagram, try to be as simple as possible and easy to understand.
Keep focus on the good practice compliance, but do not forget the organizational & human factor !!
3. Create a “Program Governance Map”
If we can make a kind of “Program Governance Map”. This folder will provide high level guidance on the relationship of one SOP with another SOP. What is the sequential sequence between SOPs if any. Where is its parent and its child, if there is a policy structure, standards, procedures and guidelines.
This is important to ensure that IT people do not get lost in the wilds of SOPs. It’s also important to ensure the integration of the entire line of processes in IT. If not, then what happens is the alienation of IT functions. And that’s dangerous ….
4. Bundles, bundles and bundles are as simple as possible
COBIT 5 has 37 processes: 5 governance processes and 5 management processes. The most easy, yes we make 37 SOP. There’s nothing wrong with that. But if you can bundle, bundellah with a more simple presentation. If you can adjust to the functional groups that exist in the organizational structure.
For example: If Project Management and SDLC can be integrated, it will be very helpful. Separated is nice to look at, but difficult to implement. For example the simple thing, that is timeline when the control should go in the phases of the SDLC and should check what? Often SOPs lose meaning from a weak context.
5. Walk-Through before it is authorized
Lastly, before this governance program is passed then do Walk-Throug with that will run. Let’s talk about whatever they are, focusing on ease of implementation but still meet the requirements of good practice compliance.
Articles form http://basukirahmad.staff.telkomuniversity.ac.id[:]
