TOR Pengadaan Software GRC
Photo by Daniil Komov on Pexels
TOR pengadaan software GRC adalah dokumen acuan yang menjelaskan tujuan, ruang lingkup, kebutuhan fungsional, kebutuhan teknis, keamanan, integrasi, tahapan implementasi, deliverables, serta kriteria penerimaan untuk pengadaan platform Governance, Risk, dan Compliance.
TOR menjadi penting karena pengadaan software GRC tidak hanya membeli aplikasi. Perusahaan sedang menerjemahkan proses Governance, Risk, Compliance, internal control, audit, reporting, dan management oversight ke dalam sistem digital yang akan digunakan lintas fungsi.
TOR yang terlalu umum dapat menghasilkan perbedaan interpretasi antara perusahaan dan penyedia. Sebaliknya, TOR yang terlalu teknis tetapi tidak menjelaskan business process dapat menghasilkan sistem yang lengkap secara fitur namun tidak sesuai dengan operating model organisasi.
Karena itu, TOR perlu menghubungkan tiga lapisan: business requirement, functional requirement, dan technical requirement. Ketiganya kemudian diterjemahkan menjadi acceptance criteria yang dapat diuji saat User Acceptance Test atau UAT.
Artikel ini merupakan cluster dari pembahasan Software GRC Indonesia dan berfokus pada penyusunan TOR atau kerangka kebutuhan pengadaan platform GRC.
Apa Tujuan TOR Pengadaan Software GRC?
Photo by Nemuel Sereti on Pexels
TOR berfungsi sebagai common reference bagi tim bisnis, fungsi GRC, procurement, IT, security, legal, dan calon penyedia.
Dokumen ini setidaknya perlu menjawab:
- masalah bisnis apa yang ingin diselesaikan;
- proses GRC apa yang akan didigitalisasi;
- siapa pengguna dan pemilik proses;
- modul apa yang termasuk scope;
- sistem existing apa yang perlu diintegrasikan;
- data apa yang perlu dimigrasikan;
- standar keamanan apa yang harus dipenuhi;
- bagaimana sistem diuji dan diterima;
- apa saja deliverables penyedia;
- dukungan apa yang diperlukan setelah go-live.
Dengan struktur tersebut, TOR tidak berhenti sebagai dokumen procurement. TOR juga menjadi alat untuk mengendalikan scope dan kualitas implementasi.
Mulai dari Business Problem, Bukan Daftar Fitur
Photo by Pixabay on Pexels
Sebelum menulis fitur, perusahaan perlu menjelaskan current condition dan pain point.
Contoh kebutuhan bisnis yang dapat menjadi dasar pengadaan antara lain:
- risk register masih tersebar di beberapa file;
- konsolidasi risiko lintas unit memerlukan proses manual;
- monitoring KRI belum memiliki early warning otomatis;
- compliance obligation belum terhubung dengan owner dan evidence;
- audit finding dan action plan dikelola terpisah;
- management report membutuhkan rekonsiliasi manual;
- perubahan data dan approval belum memiliki audit trail;
- status remediation sulit dimonitor secara real-time.
Business problem membantu penyedia memahami tujuan implementasi. Dari sini, fitur dapat disusun berdasarkan kebutuhan nyata dan bukan sekadar menyalin daftar modul dari produk tertentu.
Struktur Utama TOR Pengadaan Software GRC
Photo by Daniil Komov on Pexels
Struktur TOR dapat disesuaikan dengan kebijakan procurement masing-masing perusahaan. Namun dari sisi substansi, beberapa bagian berikut sebaiknya tersedia.
1. Latar Belakang
Menjelaskan kondisi existing, masalah utama, kebutuhan digitalisasi, serta alasan perusahaan memerlukan platform GRC terintegrasi.
2. Maksud dan Tujuan
Menjelaskan target yang ingin dicapai, misalnya meningkatkan integrasi data GRC, monitoring, traceability, early warning, atau executive reporting.
3. Ruang Lingkup
Menentukan modul, process, integration, migration, testing, rollout, training, dan support yang termasuk pekerjaan.
4. Functional Requirement
Menjelaskan capability yang harus dapat dijalankan oleh sistem.
5. Technical Requirement
Menjelaskan architecture, database, integration, security, deployment, performance, dan operational requirement.
6. Deliverables
Menetapkan output pada setiap fase.
7. Timeline dan Milestone
Menjelaskan tahap requirement, development, testing, UAT, go-live, dan support.
8. Acceptance Criteria
Menentukan kondisi yang harus dipenuhi agar deliverable dan sistem dapat diterima.
9. Support dan Maintenance
Menjelaskan warranty, hypercare, incident support, change request, dan maintenance.
10. Kualifikasi Penyedia
Menentukan capability yang dibutuhkan dari penyedia tanpa membuat persyaratan yang tidak relevan dengan keberhasilan project.
Ruang Lingkup Fungsional Software GRC
Photo by Daniil Komov on Pexels
Ruang lingkup fungsional sebaiknya mengikuti proses yang benar-benar dibutuhkan perusahaan.
Materi internal RWI mengenai pengembangan sistem GRC mencakup beberapa domain utama:
- Governance dan policy management;
- Enterprise Risk Management;
- Legal dan Compliance;
- Integrated GRC Dashboard;
- workflow dan approval;
- role-based access;
- notification dan escalation;
- audit trail dan evidence tracking;
- integrasi dengan sistem existing melalui API;
- testing, UAT, rollout, dan go-live;
- training, knowledge transfer, dan hypercare.
TOR tidak harus memasukkan seluruh domain dalam satu fase. Perusahaan dapat memprioritaskan modul sesuai maturity dan readiness.
Requirement Modul Enterprise Risk Management
Photo by 李 先生 on Pexels
Jika ERM menjadi bagian scope, TOR dapat meminta kemampuan untuk mengelola:
- risk taxonomy;
- risk appetite dan risk tolerance;
- risk register;
- risk assessment;
- inherent dan residual risk;
- control;
- risk treatment;
- KRI dan threshold;
- Early Warning System;
- top risk dan heatmap;
- loss event;
- risk reporting;
- risk maturity bila diperlukan.
Requirement sebaiknya menjelaskan workflow, owner, approval, status, history, dan evidence. Menulis hanya “tersedia fitur risk register” terlalu umum karena setiap platform dapat menginterpretasikan proses secara berbeda.
Requirement Modul Compliance
Photo by Adriano Ponte Abreu on Pexels
Untuk compliance management, TOR dapat mencakup:
- regulatory inventory;
- compliance obligation;
- applicability assessment;
- compliance risk assessment;
- compliance monitoring;
- policy linkage;
- control dan evidence;
- issue dan corrective action;
- reminder dan escalation;
- compliance reporting.
Requirement yang baik perlu menjelaskan relationship antara regulation, obligation, owner, control, evidence, finding, dan action. Dengan demikian, platform tidak hanya menjadi repository peraturan.
Requirement Internal Control, Audit, dan Assurance
Photo by RDNE Stock project on Pexels
Jika perusahaan ingin membangun GRC yang lebih terintegrasi, TOR dapat menambahkan internal control dan audit.
Internal control dapat mencakup control library, control owner, frequency, evidence, control testing, exception, remediation, dan effectiveness status.
Audit dapat mencakup audit universe, planning, engagement, working paper, testing, finding, recommendation, management response, due date, follow-up, dan reporting.
Scope perlu memperhatikan Three Lines Model GRC agar Lini 1, Lini 2, dan Lini 3 dapat menggunakan sistem sesuai role masing-masing tanpa menghilangkan independensi assurance.
Spesifikasi Teknis yang Perlu Masuk dalam TOR
Photo by Kun Fayakun on Pexels
Spesifikasi teknis perlu cukup jelas untuk memastikan platform dapat beroperasi pada environment perusahaan, tetapi tidak selalu harus mengunci teknologi secara berlebihan jika perusahaan masih membuka opsi solusi.
Area yang dapat dicantumkan meliputi:
- web-based application atau kebutuhan channel lain;
- application architecture;
- database dan data storage;
- deployment model;
- environment development, testing, UAT, dan production;
- browser compatibility;
- API dan integration capability;
- backup dan recovery;
- logging dan monitoring;
- performance dan availability;
- security requirement.
Jika perusahaan telah memiliki technology standard, TOR dapat meminta kompatibilitas dengan standard tersebut. Jika belum, penyedia dapat diminta mengusulkan architecture beserta rationale, dependency, dan requirement infrastructure.
Security Requirement dalam TOR Software GRC
Photo by Muhammed Ensar on Pexels
Software GRC dapat menyimpan informasi sensitif seperti top risk, audit finding, compliance breach, strategic issue, dan weakness control. Karena itu, security requirement perlu menjadi bagian inti TOR.
Requirement dapat mencakup:
- authentication dan Single Sign-On jika diperlukan;
- role-based access control;
- least privilege;
- segregation of duties;
- encryption untuk data sensitif;
- session management;
- audit trail;
- activity log;
- document access control;
- backup dan recovery;
- security testing sebelum go-live;
- vulnerability remediation;
- data retention sesuai kebijakan perusahaan.
TOR sebaiknya membedakan requirement wajib dan requirement tambahan. Hal ini membantu proses evaluasi teknis menjadi lebih objektif.
Integration Requirement dan API
Photo by Zulfugar Karimov on Pexels
GRC platform sering membutuhkan data dari sistem lain. Karena itu, integrasi perlu dijelaskan sejak awal.
TOR dapat mencantumkan daftar sistem yang berpotensi terhubung, jenis data, direction of data flow, frequency, API availability, owner, dan dependency.
Contoh integrasi antara lain:
- HR system untuk user, organization, dan position;
- ERP atau financial system untuk indikator risiko;
- document management system untuk evidence dan policy;
- identity management untuk authentication;
- operational system untuk KRI;
- data warehouse untuk analytics dan reporting.
Requirement integrasi juga sebaiknya mencakup validation, error handling, retry, reconciliation, dan monitoring. Integrasi yang berhasil secara teknis belum tentu menghasilkan data yang reliable jika validation tidak tersedia.
Data Migration dan Data Cleansing
Jika perusahaan memiliki data existing yang akan dipindahkan, TOR perlu menjelaskan scope migrasi.
Data dapat meliputi risk register, policy, control, regulatory obligation, audit finding, action plan, KRI history, user, organization, dan evidence tertentu.
TOR perlu memperjelas:
- periode data yang dimigrasikan;
- format sumber;
- jumlah atau perkiraan volume data;
- mapping field;
- data cleansing responsibility;
- migration trial;
- validation dan reconciliation;
- sign-off hasil migrasi.
Kesalahan umum adalah menganggap data migration sebagai aktivitas copy-paste. Padahal struktur data lama sering tidak sama dengan data model sistem baru.
Non-Functional Requirement
Selain fitur, TOR juga perlu menjelaskan bagaimana sistem harus beroperasi.
Non-functional requirement dapat mencakup:
- performance;
- availability;
- scalability;
- usability;
- maintainability;
- security;
- auditability;
- compatibility;
- reliability;
- backup dan recovery.
Jika memungkinkan, requirement sebaiknya memiliki ukuran yang dapat diuji. Contohnya, bukan hanya “sistem harus cepat”, tetapi kriteria performa yang disepakati pada skenario tertentu.
Deliverables Pengadaan Software GRC
Deliverables perlu disusun berdasarkan fase agar progress dapat dinilai secara objektif.
Output yang dapat diminta antara lain:
- project initiation document;
- current-state assessment;
- business requirement document;
- User Requirement Specification;
- solution blueprint;
- process dan workflow design;
- configuration atau development result;
- integration specification;
- test scenario dan test result;
- UAT document;
- security testing result;
- deployment dan go-live document;
- user manual dan administrator manual;
- training material;
- knowledge transfer;
- hypercare dan warranty report.
Materi internal RWI mengenai implementasi sistem juga menekankan requirement, blueprint, development, testing, UAT, deployment, go-live, training, dan support sebagai rangkaian delivery yang saling terkait.
User Acceptance Test Harus Didefinisikan Sejak TOR
UAT tidak sebaiknya baru dibahas menjelang go-live. Acceptance criteria perlu ditentukan sejak requirement.
TOR dapat meminta penyedia menyusun UAT berdasarkan business scenario yang mewakili process end-to-end.
Contoh skenario:
- risk owner membuat dan mengajukan risk assessment;
- reviewer melakukan challenge;
- approver memberikan persetujuan;
- KRI melewati threshold dan memicu alert;
- compliance owner mengunggah evidence;
- issue dibuat dan diberikan kepada PIC;
- action overdue dieskalasikan;
- management melihat consolidated dashboard;
- audit trail menunjukkan seluruh perubahan.
Hasil UAT perlu memiliki status, evidence, defect, severity, owner, target resolution, dan sign-off.
Kriteria Go-Live
Go-live sebaiknya hanya dilakukan setelah readiness terpenuhi.
Kriteria dapat mencakup:
- critical requirement selesai;
- UAT sign-off diperoleh;
- critical defect ditutup;
- security issue material diselesaikan;
- data migration tervalidasi;
- user dan role tersedia;
- production environment siap;
- backup tersedia;
- training pengguna utama selesai;
- support dan escalation mechanism tersedia.
Dengan kriteria ini, keputusan go-live tidak hanya didasarkan pada tanggal project plan.
Training, Knowledge Transfer, dan Change Management
Software GRC melibatkan banyak user non-IT. Karena itu, TOR perlu memasukkan adoption sebagai bagian pekerjaan.
Training dapat dibedakan untuk administrator, power user, risk owner, compliance owner, auditor, approver, dan management.
Knowledge transfer perlu memastikan tim internal memahami configuration, master data, user administration, reporting, dan troubleshooting dasar.
Change management juga penting karena pengguna mungkin terbiasa menggunakan spreadsheet atau email. Sistem baru harus disertai komunikasi mengenai perubahan proses, role, serta cara kerja baru.
Hypercare, Warranty, SLA, dan Maintenance
Periode setelah go-live sering menjadi fase paling kritis karena user mulai menggunakan sistem dalam kondisi nyata.
TOR dapat meminta:
- hypercare period;
- warranty period;
- helpdesk;
- severity classification;
- response time;
- resolution target;
- bug fixing;
- patch dan update;
- minor enhancement policy;
- change request mechanism;
- maintenance reporting.
SLA perlu membedakan incident, service request, dan enhancement agar ekspektasi kedua pihak jelas.
Kualifikasi Penyedia Software GRC
Persyaratan penyedia sebaiknya berkaitan langsung dengan risiko project.
Area yang dapat dievaluasi antara lain:
- pengalaman implementasi sistem enterprise;
- pemahaman Governance, Risk, dan Compliance;
- capability business analysis;
- capability system development atau configuration;
- integration capability;
- security capability;
- project management;
- testing dan quality assurance;
- training dan support;
- kemampuan melakukan customization bila diperlukan.
Untuk software GRC, kemampuan memahami proses bisnis sama pentingnya dengan kemampuan teknis. Requirement yang salah diterjemahkan dapat menghasilkan aplikasi yang secara teknis berjalan tetapi gagal digunakan.
Kriteria Evaluasi Penawaran
Evaluasi teknis dapat dibangun menggunakan beberapa kategori.
- Functional fit: kesesuaian modul dan workflow;
- Technical fit: architecture, integration, performance, dan deployment;
- Security: access control, audit trail, encryption, dan testing;
- Implementation methodology: requirement, development, UAT, rollout, dan support;
- Team capability: business, GRC, technical, QA, dan project management;
- Scalability: kemampuan mendukung pertumbuhan scope;
- Commercial: biaya implementasi dan total cost of ownership.
Jika perusahaan menggunakan proof of concept atau demo, skenario demo sebaiknya ditentukan oleh perusahaan agar seluruh penyedia diuji pada use case yang sama.
Kesalahan Umum dalam Menyusun TOR Pengadaan Software GRC
1. Menyalin Brosur Produk ke TOR
TOR menjadi daftar fitur tanpa konteks business requirement.
2. Scope Terlalu Luas
Seluruh modul diminta pada fase pertama tanpa mempertimbangkan maturity dan readiness.
3. Acceptance Criteria Tidak Jelas
Perusahaan dan penyedia memiliki interpretasi berbeda mengenai kapan sistem dianggap selesai.
4. Tidak Memasukkan Integration Dependency
Timeline menjadi tidak realistis karena API atau source data belum tersedia.
5. Data Migration Diabaikan
Sistem selesai tetapi data awal belum dapat digunakan.
6. Security Baru Dibahas di Akhir
Perubahan architecture menjadi lebih mahal.
7. Tidak Ada Hypercare
User menghadapi masalah setelah go-live tanpa support mechanism yang cukup.
8. Fokus Hanya pada Harga
Pengadaan software enterprise perlu mempertimbangkan fit, implementability, security, support, dan total cost of ownership.
Contoh Outline TOR Pengadaan Software GRC
Outline berikut dapat digunakan sebagai titik awal dan disesuaikan dengan template procurement perusahaan:
- 1. Latar Belakang;
- 2. Maksud dan Tujuan;
- 3. Kondisi Existing;
- 4. Ruang Lingkup Pekerjaan;
- 5. Functional Requirement;
- 6. Technical Requirement;
- 7. Security Requirement;
- 8. Integration dan Data Migration;
- 9. Testing dan UAT;
- 10. Deliverables;
- 11. Timeline dan Milestone;
- 12. Go-Live dan Hypercare;
- 13. Training dan Knowledge Transfer;
- 14. Warranty, SLA, dan Maintenance;
- 15. Kualifikasi Penyedia;
- 16. Acceptance Criteria;
- 17. Mekanisme Evaluasi.
Outline tersebut tidak harus digunakan secara identik. Yang penting, business requirement dan acceptance criteria dapat ditelusuri sampai deliverable.
Pendekatan RWI Consulting
RWI Consulting membantu perusahaan menyusun kebutuhan pengadaan software GRC dari sisi business process dan implementation readiness.
Pendekatan dapat mencakup current-state assessment, process mapping, requirement gathering, fit-gap analysis, blueprint, functional requirement, technical requirement, integration requirement, UAT scenario, acceptance criteria, dan implementation roadmap.
Tujuannya adalah memastikan TOR tidak hanya cukup untuk proses pengadaan, tetapi juga menjadi fondasi implementasi yang terukur.
Untuk memahami capability platform secara lebih lengkap, lihat Software GRC Indonesia.
FAQ TOR Pengadaan Software GRC
Apa itu TOR pengadaan software GRC?
TOR pengadaan software GRC adalah dokumen acuan yang menjelaskan tujuan, scope, requirement, deliverables, timeline, testing, acceptance, dan support untuk implementasi platform Governance, Risk, dan Compliance.
Apa perbedaan TOR dan RFP software GRC?
TOR biasanya menjelaskan kebutuhan dan ruang lingkup pekerjaan, sedangkan RFP dapat mencakup format permintaan proposal, instruksi penawaran, evaluasi, dan informasi komersial yang lebih luas.
Apa requirement paling penting?
Yang paling penting adalah requirement yang dapat ditelusuri dari business problem sampai acceptance criteria. Daftar fitur tanpa workflow dan objective sering tidak cukup.
Apakah TOR harus menentukan teknologi tertentu?
Tidak selalu. Jika perusahaan memiliki standard technology, requirement dapat ditetapkan. Jika tidak, penyedia dapat diminta mengusulkan architecture yang memenuhi business, security, integration, dan operational requirement.
Apakah UAT harus dicantumkan di TOR?
Ya. UAT dan acceptance criteria sebaiknya ditetapkan sejak awal agar definisi selesai dapat dipahami bersama.
Apakah data migration termasuk scope?
Jika data existing perlu digunakan di sistem baru, migration sebaiknya dimasukkan secara eksplisit beserta mapping, cleansing, validation, dan sign-off.
Apakah TOR perlu memasukkan hypercare?
Ya, terutama untuk platform enterprise. Hypercare membantu memastikan issue awal setelah go-live dapat ditangani cepat.
Apakah seluruh modul GRC harus dibeli sekaligus?
Tidak. Implementasi modular dapat lebih efektif jika disusun berdasarkan priority, maturity, dan readiness organisasi.
TOR yang Baik Mengurangi Risiko Implementasi
TOR pengadaan software GRC bukan sekadar dokumen tender. TOR adalah alat untuk menyelaraskan business, GRC, IT, procurement, security, dan penyedia sebelum project dimulai.
Semakin jelas business requirement, workflow, data, integration, security, deliverables, dan acceptance criteria, semakin kecil risiko salah interpretasi saat implementasi.
