IT Related Goals

1. Menyelaraskan TI dan strategi bisnis

Metrics: Persentase sasaran dan persyaratan strategis perusahaan yang didukung oleh sasaran strategis TI, tingkat kepuasan pemangku kepentingan dengan cakupan portofolio program dan layanan yang direncanakan, serta persentase penggerak nilai TI yang dipetakan ke penggerak nilai bisnis.

2. Pengiriman layanan TI sesuai dengan kebutuhan bisnis

Metrics: Jumlah gangguan bisnis akibat insiden layanan TI, persentase pemangku kepentingan bisnis puas bahwa penyampaian layanan TI memenuhi tingkat layanan yang disepakati, serta persentase pengguna yang puas dengan kualitas penyampaian layanan TI.

3. Pemberdayaan dan dukungan proses bisnis dengan mengintegrasikan aplikasi dan teknologi ke dalam proses bisnis

Metrics: Jumlah insiden pemrosesan bisnis yang disebabkan oleh kesalahan integrasi teknologi, jumlah perubahan proses bisnis yang perlu ditunda atau dikerjakan ulang karena masalah integrasi teknologi, jumlah program bisnis yang mendukung TI tertunda atau menimbulkan biaya tambahan karena masalah integrasi teknologi, serta jumlah aplikasi atau infrastruktur kritis yang beroperasi secara terisolasi dan tidak terintegrasi.

Process Goals

1. Persyaratan fungsional dan teknis bisnis mencerminkan kebutuhan dan harapan perusahaan

Metrics: Persentase persyaratan yang dikerjakan ulang karena ketidaksesuaian dengan kebutuhan dan harapan perusahaan dan tingkat kepuasan pemangku kepentingan dengan persyaratan.

2. Solusi yang diusulkan memenuhi persyaratan fungsional, teknis, dan kepatuhan bisnis

Metrics: Persentase persyaratan dipenuhi oleh solusi yang diusulkan.

3. Risiko yang terkait dengan persyaratan telah dibahas dalam solusi yang diusulkan

Metric: Jumlah insiden yang tidak teridentifikasi sebagai risiko dan persentase risiko yang tidak berhasil dimitigasi.

4. Persyaratan dan solusi yang diusulkan memenuhi tujuan kasus bisnis (nilai yang diharapkan dan kemungkinan biaya)

Metrics: Persentase tujuan kasus bisnis yang dipenuhi oleh solusi yang diusulkan dan persentase pemangku kepentingan yang tidak menyetujui solusi terkait kasus bisnis

RACI Chart

RACI merupakan singkatan dari responsible, accountable, consulted dan informed. Dalam praktiknya, RACI chart merupakan spreadsheet atau tabel sederhana yang mencantumkan semua stakeholders dalam suatu proyek dan level keterlibatan mereka dalam setiap tugas yang dilambangkan dengan huruf R, A, C atau I. RACI Chart dapat digunakan untuk membantu dalam pengambilan keputusan dan membantu pihak manajemen dalam mengidentifikasikan peran dan tanggung jawab setiap stakeholders. Pembagian tugas yang jelas beserta peran dan tanggung jawabnya merupakan hal yang penting dalam suatu organisasi.

Empat parameter dalam RACI chart:

1. 1. Responsible, yaitu pihak yang melakukan tugas atau pekerjaan.

   2. Accountable, yaitu pihak penanggung jawab dan berwenang untuk memutuskan suatu permasalahan atau perkara.

   3. Consulted, yaitu pihak yang memberikan masukan atau pendapat ketika diperlukan pada suatu tugas.

   4. Informed, yaitu pihak yang perlu mengetahui tindakan dan hasil ataupun keputusan yang telah diambil.

Contohnya pada RACI chart BAI02.01 – Define and maintain business functional and technical requirements. Terdapat Steering Commitee terdapat yang berperan sebagai pihak penanggungjawab (A). Sedangkan Project Management Office berperan sebagai pelaksana tugas (R). Selanjutnya Business Excecutives berperan sebagai pihak yang perlu mengetahui hasil keputusan yang diambil (I). Kemudian yang terakhir ada Chief Risk Officer yang berperan sebagai pihak yang memberikan masukan atau pendapat yang diperlukan (C).

Management Practices

• BAI02.01 – Mendefinisikan dan memelihara persyaratan fungsional dan teknis bisnis

Berdasarkan kasus bisnis, identifikasi, prioritaskan, spesifikasikan, dan setujui informasi bisnis, persyaratan fungsional, teknis, dan kontrol yang mencakup ruang lingkup/pemahaman semua inisiatif yang diperlukan untuk mencapai hasil yang diharapkan dari solusi bisnis yang didukung TI yang diusulkan

Aktivitas yang dilakukan pada practice ini adalah:

1. Menetapkan dan menerapkan definisi persyaratan dan prosedur pemeliharaan dan penyimpanan persyaratan yang sesuai untuk ukuran, kompleksitas, tujuan, dan risiko inisiatif yang sedang dipertimbangkan untuk dilakukan oleh perusahaan.

2. Mengekspresikan persyaratan bisnis dalam hal bagaimana kesenjangan antara kemampuan bisnis saat ini dan yang diinginkan perlu ditangani dan bagaimana peran akan berinteraksi dengan dan menggunakan solusi tersebut.

3. Sepanjang proyek, peroleh, analisis, dan konfirmasikan bahwa semua persyaratan pemangku kepentingan, termasuk kriteria penerimaan yang relevan, dipertimbangkan, ditangkap, diprioritaskan, dan dicatat dengan cara yang dapat dipahami oleh pemangku kepentingan, sponsor bisnis, dan personel implementasi teknis, dengan mengakui bahwa persyaratan tersebut dapat berubah dan akan menjadi lebih rinci saat diimplementasikan.

4. Menentukan dan memprioritaskan informasi, persyaratan fungsional dan teknis berdasarkan persyaratan pemangku kepentingan yang telah dikonfirmasi. Menyertakan persyaratan kontrol informasi dalam proses bisnis, proses otomatis, dan lingkungan TI untuk mengatasi risiko informasi dan untuk mematuhi undang-undang, peraturan, dan kontrak komersial.

5. Memvalidasi semua persyaratan melalui pendekatan seperti tinjauan sejawat, validasi model, atau pembuatan prototipe operasional.

6. Mengkonfirmasi penerimaan aspek kunci dari persyaratan, termasuk aturan perusahaan, kontrol informasi, kelangsungan bisnis, kepatuhan hukum dan peraturan, kemampuan audit, ergonomi, pengoperasian dan kegunaan, keamanan, dan dokumentasi pendukung.

7. Melacak dan mengendalikan ruang lingkup, persyaratan, dan perubahan melalui siklus hidup solusi di seluruh proyek seiring dengan berkembangnya pemahaman tentang solusi.

8. Mempertimbangkan persyaratan yang berkaitan dengan kebijakan dan standar perusahaan, arsitektur perusahaan, rencana TI strategis dan taktis, proses bisnis dan TI in-house dan outsourcing, persyaratan keamanan, persyaratan peraturan, kompetensi orang, struktur organisasi, kasus bisnis, dan teknologi yang memungkinkan.

• BAI02.02 – Melakukan studi kelayakan dan merumuskan solusi alternatif

Melakukan studi kelayakan solusi alternatif potensial, nilai kelayakannya dan memilih opsi yang disukai. Jika sesuai, terapkan opsi yang dipilih tersebut sebagai percontohan untuk menentukan kemungkinan perbaikan.

1. Menentukan dan melaksanakan studi kelayakan, percontohan atau solusi kerja dasar yang secara jelas dan ringkas menggambarkan solusi alternatif yang akan memenuhi kebutuhan bisnis dan fungsional. Sertakan evaluasi kelayakan teknologi dan ekonomi mereka.

2. Mengidentifikasi tindakan yang diperlukan untuk akuisisi atau pengembangan solusi berdasarkan arsitektur perusahaan, dan mempertimbangkan batasan ruang lingkup dan/atau waktu dan/atau anggaran.

3. Meninjau solusi alternatif dengan semua pemangku kepentingan dan pilih yang paling sesuai berdasarkan kriteria kelayakan, termasuk risiko dan biaya.

4. Menerjemahkan tindakan yang disukai ke dalam rencana akuisisi/pengembangan tingkat tinggi yang mengidentifikasi sumber daya yang akan digunakan dan tahapan yang membutuhkan keputusan lanjut/tidak lanjut.

• BAI02.03 – Mengelola risiko persyaratan

Melakukan identifikasi, dokumentasi, prioritasisasi, dan mengurangi risiko fungsional, teknis, dan terkait pemrosesan informasi yang terkait dengan persyaratan perusahaan dan solusi yang diusulkan.

Aktivitas yang dilakukan pada practice ini adalah:

1. Mengikut-sertakan pemangku kepentingan untuk membuat daftar potensi kualitas, fungsional, dan persyaratan teknis serta risiko terkait pemrosesan informasi (karena, misalnya, kurangnya keterlibatan pengguna, ekspektasi yang tidak realistis, pengembang menambahkan fungsionalitas yang tidak perlu).

2. Menganalisis dan memprioritaskan risiko kebutuhan menurut probabilitas dan dampak. Jika berlaku, tentukan dampak anggaran dan jadwal.

3. Mengidentifikasi cara untuk mengontrol, menghindari, atau mengurangi risiko persyaratan dalam urutan prioritas

• BAI02.04 – Mendapatkan persetujuan persyaratan dan solusi

Mengkoordinasikan umpan balik dari pemangku kepentingan yang terkena dampak dan pada tahap kunci yang telah ditentukan sebelumnya, dapatkan persetujuan sponsor bisnis atau pemilik produk dan persetujuan persyaratan fungsional dan teknis, studi kelayakan, analisis risiko, dan solusi yang direkomendasikan.

Aktivitas yang dilakukan pada practice ini adalah:

1. Memastikan bahwa sponsor bisnis atau pemilik produk membuat keputusan akhir sehubungan dengan pilihan solusi, pendekatan akuisisi, dan desain tingkat tinggi, sesuai kasus bisnis. Mengkoordinasikan umpan balik dari pemangku kepentingan yang terkena dampak dan dapatkan persetujuan dari otoritas bisnis dan teknis yang sesuai (misalnya, pemilik proses bisnis, arsitek perusahaan, manajer operasi, keamanan) untuk pendekatan yang diusulkan.

2. Mendapatkan ulasan kualitas di seluruh, dan di akhir, setiap tahap proyek utama, iterasi atau rilis untuk menilai hasil terhadap kriteria penerimaan asli.

Related Guidance

Sumber eksternal yang dapat memberikan wawasan lebih lanjut ke dalam proses APO05 ini yaitu:

• ITIL V3 2011

ISACA. COBIT 5: Enabling Processes. 2012. www.isaca.org

Wiki.process-symphony.com. 2 Juni 2019. Requirements Definition Management – BAI02 (COBIT 2019). Diakses pada 18 Oktober 2022, dari https://wiki.process-symphony.com.au/framework/lifecycle/process/requirements-definition-management-bai02-cobit2019/

Glints.com. 25 Januari 2021. RACI Matrix, Cara Pembagian Tugas Efektif untuk Tim yang Lebih Produktif. Diakses pada 18 Oktober 2022, dari https://glints.com/id/lowongan/raci-adalah/

Fithrotuz Zuhroh - 5026211045