Catatan Kuliah RPL Bisnis | Halaman 1
Catatan Kuliah RPL Bisnis | Halaman 2 Kata Pengantar Puji syukur ke hadirat Tuhan Yang Maha Esa karena catatan kuliah ini dapat disusun sebagai bahan belajar pendamping untuk mata kuliah Rekayasa Perangkat Lunak untuk Bisnis. Dokumen ini dikembangkan dari materi perkuliahan Pertemuan 9 sampai Pertemuan 15, kemudian dielaborasi menjadi uraian akademik yang lebih lengkap, sistematis, dan dapat digunakan untuk membaca hubungan antara konsep teknis perangkat lunak dan kebutuhan strategis organisasi bisnis. Ruang lingkup catatan ini mencakup sistem ERP, CRM, dan integrasi enterprise; manajemen proyek perangkat lunak bisnis; kualitas perangkat lunak dan software testing enterprise; keamanan perangkat lunak dan compliance; monitoring, controlling, change management, dan evaluasi proyek; AI/ML dan Generative AI untuk solusi bisnis; serta transformasi digital dan IT governance. Ketujuh topik tersebut saling berhubungan karena perangkat lunak bisnis tidak hanya harus dibangun, tetapi juga harus bernilai, aman, andal, terukur, patuh, dan berkelanjutan. Penyusunan catatan ini menggunakan gaya buku ajar ringkas tetapi mendalam. Setiap bab memuat capaian pembelajaran, elaborasi konsep, pendalaman materi, visualisasi, pemetaan materi, implikasi bisnis, studi kasus, dan refleksi. Dengan struktur tersebut, mahasiswa diharapkan tidak hanya menghafal istilah, tetapi mampu menganalisis situasi, mengevaluasi risiko, memilih pendekatan yang tepat, dan menghubungkan desain perangkat lunak dengan outcome organisasi. Catatan ini masih dapat dikembangkan lebih lanjut melalui diskusi kelas, studi kasus lokal, proyek kelompok, serta pembacaan referensi akademik dan praktik industri. Semoga dokumen ini membantu mahasiswa memahami Rekayasa Perangkat Lunak untuk Bisnis sebagai disiplin yang memadukan teknik, manajemen, tata kelola, dan pemikiran strategis. Bogor, July 2026
Catatan Kuliah RPL Bisnis | Halaman 3 Daftar Isi Kata Pengantar ........................................................................................................ 2 Daftar Isi.................................................................................................................. 3 Daftar Gambar ......................................................................................................... 9 Daftar Tabel .......................................................................................................... 10 Glosarium .............................................................................................................. 13 Bab 1. Sistem ERP, CRM, Dan Integrasi Enterprise ............................................ 16 Elaborasi Konsep .............................................................................................. 16 Uraian Materi Rinci........................................................................................... 16 Enterprise System Sebagai Tulang Punggung Organisasi ............................ 16 ERP, CRM, Dan Aliran Data Bisnis ............................................................. 17 Arsitektur Integrasi Dan Tantangannya ........................................................ 17 Pendalaman Materi Per Unit ............................................................................. 17 Unit 1.1. Pemetaan Proses Bisnis Enterprise ................................................ 18 Checklist Analisis ......................................................................................... 19 Unit 1.2. ERP Sebagai Sistem Operasi Internal Bisnis ................................. 20 Checklist Analisis ......................................................................................... 21 Unit 1.3. CRM Sebagai Sistem Relasi Dan Pengalaman Pelanggan ............ 22 Checklist Analisis ......................................................................................... 23 Unit 1.4. Integrasi Data ERP-CRM .............................................................. 24 Checklist Analisis ......................................................................................... 25 Unit 1.5. Enterprise Application Integration ................................................. 26 Checklist Analisis ......................................................................................... 27 Unit 1.6. Cloud ERP Dan Cloud CRM ......................................................... 28 Checklist Analisis ......................................................................................... 29 Unit 1.7. Governance Integrasi Enterprise .................................................... 30 Checklist Analisis ......................................................................................... 31 Visualisasi Konsep ............................................................................................ 32 Pemetaan Materi................................................................................................ 32 Implikasi Untuk Bisnis...................................................................................... 32 Studi Kasus Dan Refleksi ................................................................................. 33
Catatan Kuliah RPL Bisnis | Halaman 4 Bab 2. Manajemen Proyek Perangkat Lunak Bisnis ............................................. 34 Elaborasi Konsep .............................................................................................. 34 Uraian Materi Rinci........................................................................................... 34 Project Charter, Scope, Dan Baseline ........................................................... 34 WBS Dan Estimasi Effort ............................................................................. 34 Risk, ROI, Dan Keputusan Manajerial ......................................................... 35 Pendalaman Materi Per Unit ............................................................................. 35 Unit 2.1. Inisiasi Proyek Dan Business Case ................................................ 36 Checklist Analisis ......................................................................................... 37 Unit 2.2. Work Breakdown Structure ........................................................... 38 Checklist Analisis ......................................................................................... 39 Unit 2.3. Estimasi Effort Dengan COCOMO Dan Pendekatan Modern....... 40 Checklist Analisis ......................................................................................... 41 Unit 2.4. Perencanaan Jadwal Dan Sumber Daya ......................................... 42 Checklist Analisis ......................................................................................... 43 Unit 2.5. Manajemen Risiko Proyek Software.............................................. 44 Checklist Analisis ......................................................................................... 45 Unit 2.6. ROI Dan Evaluasi Kelayakan Investasi TI .................................... 46 Checklist Analisis ......................................................................................... 47 Unit 2.7. Agile Project Management Untuk Bisnis....................................... 48 Checklist Analisis ......................................................................................... 49 Visualisasi Konsep ............................................................................................ 50 Pemetaan Materi................................................................................................ 50 Implikasi Untuk Bisnis...................................................................................... 50 Studi Kasus Dan Refleksi ................................................................................. 51 Bab 3. Kualitas Perangkat Lunak Dan Software Testing Enterprise .................... 52 Elaborasi Konsep .............................................................................................. 52 Uraian Materi Rinci........................................................................................... 52 Kualitas Sebagai Atribut Multidimensi ......................................................... 52 Strategi Testing Enterprise ............................................................................ 53 Metrics Dan Continuous Improvement ......................................................... 53 Pendalaman Materi Per Unit ............................................................................. 53
Catatan Kuliah RPL Bisnis | Halaman 5 Unit 3.1. Kualitas Sebagai Kesesuaian Terhadap Kebutuhan Bisnis ............ 54 Checklist Analisis ......................................................................................... 55 Unit 3.2. Model Kualitas ISO/IEC 25010 ..................................................... 56 Checklist Analisis ......................................................................................... 57 Unit 3.3. Perencanaan Testing Enterprise ..................................................... 58 Checklist Analisis ......................................................................................... 59 Unit 3.4. Test Case Dan Test Scenario Berbasis Proses Bisnis .................... 60 Checklist Analisis ......................................................................................... 61 Unit 3.5. Automation Testing Dan CI/CD .................................................... 62 Checklist Analisis ......................................................................................... 63 Unit 3.6. Performance Dan Reliability Testing ............................................. 64 Checklist Analisis ......................................................................................... 65 Unit 3.7. Quality Assurance Dan Audit Software ......................................... 66 Checklist Analisis ......................................................................................... 67 Visualisasi Konsep ............................................................................................ 68 Pemetaan Materi................................................................................................ 68 Implikasi Untuk Bisnis...................................................................................... 69 Studi Kasus Dan Refleksi ................................................................................. 69 Bab 4. Keamanan Perangkat Lunak Dan Compliance Bisnis ............................... 70 Elaborasi Konsep .............................................................................................. 70 Uraian Materi Rinci........................................................................................... 70 Keamanan Sebagai Kebutuhan Bisnis .......................................................... 70 OWASP Dan Secure Coding ........................................................................ 71 Privacy Dan Tata Kelola Keamanan ............................................................. 71 Pendalaman Materi Per Unit ............................................................................. 71 Unit 4.1. Prinsip Dasar Keamanan Software Bisnis ..................................... 72 Checklist Analisis ......................................................................................... 73 Unit 4.2. Threat, Vulnerability, Risk, Dan Control ....................................... 74 Checklist Analisis ......................................................................................... 75 Unit 4.3. Secure SDLC.................................................................................. 76 Checklist Analisis ......................................................................................... 77 Unit 4.4. OWASP Top 10 Dalam Aplikasi Bisnis ........................................ 78
Catatan Kuliah RPL Bisnis | Halaman 6 Checklist Analisis ......................................................................................... 79 Unit 4.5. GDPR Dan Perlindungan Data Pribadi .......................................... 80 Checklist Analisis ......................................................................................... 81 Unit 4.6. ISO/IEC 27001 Dan ISMS............................................................. 82 Checklist Analisis ......................................................................................... 83 Unit 4.7. Security Operations Dan Compliance Monitoring......................... 84 Checklist Analisis ......................................................................................... 85 Visualisasi Konsep ............................................................................................ 86 Pemetaan Materi................................................................................................ 86 Implikasi Untuk Bisnis...................................................................................... 86 Studi Kasus Dan Refleksi ................................................................................. 87 Bab 5. Monitoring, Controlling, Change Management, Dan Evaluasi Kinerja Proyek ................................................................................................................... 88 Elaborasi Konsep .............................................................................................. 88 Uraian Materi Rinci........................................................................................... 88 Baseline Sebagai Alat Kontrol ...................................................................... 88 EVM, Status Report, Dan Dashboard ........................................................... 89 Integrated Change Control ............................................................................ 89 Pendalaman Materi Per Unit ............................................................................. 89 Unit 5.1. Monitoring Sebagai Pengumpulan Fakta Proyek .......................... 90 Checklist Analisis ......................................................................................... 91 Unit 5.2. Controlling Terhadap Baseline ...................................................... 92 Checklist Analisis ......................................................................................... 93 Unit 5.3. Earned Value Management ............................................................ 94 Checklist Analisis ......................................................................................... 95 Unit 5.4. Issue Management Dan Eskalasi.................................................... 96 Checklist Analisis ......................................................................................... 97 Unit 5.5. Integrated Change Control ............................................................. 98 Checklist Analisis ......................................................................................... 99 Unit 5.6. Project Performance Review ........................................................ 100 Checklist Analisis ....................................................................................... 101 Unit 5.7. Dashboard Kontrol Proyek SI ...................................................... 102
Catatan Kuliah RPL Bisnis | Halaman 7 Checklist Analisis ....................................................................................... 103 Visualisasi Konsep .......................................................................................... 104 Pemetaan Materi.............................................................................................. 104 Implikasi Untuk Bisnis.................................................................................... 105 Studi Kasus Dan Refleksi ............................................................................... 105 Bab 6. AI/ML Dan Generative AI Untuk Solusi Bisnis...................................... 106 Elaborasi Konsep ............................................................................................ 106 Uraian Materi Rinci......................................................................................... 106 Memilih Masalah Yang Tepat Untuk AI .................................................... 106 Data, Model, Dan Aplikasi.......................................................................... 107 GenAI, RAG, Guardrail, Dan Operasi ........................................................ 107 Pendalaman Materi Per Unit ........................................................................... 107 Unit 6.1. Business Understanding Untuk Solusi AI.................................... 108 Checklist Analisis ....................................................................................... 109 Unit 6.2. Data Understanding Dan Data Readiness .................................... 110 Checklist Analisis ....................................................................................... 111 Unit 6.3. Pemilihan Model AI/ML.............................................................. 112 Checklist Analisis ....................................................................................... 113 Unit 6.4. Generative AI Dan Arsitektur RAG............................................. 114 Checklist Analisis ....................................................................................... 115 Unit 6.5. Prompt Engineering Untuk Produktivitas Bisnis ......................... 116 Checklist Analisis ....................................................................................... 117 Unit 6.6. Human-in-the-loop Dan Pengalaman Pengguna .......................... 118 Checklist Analisis ....................................................................................... 119 Unit 6.7. MLOps Dan LLMOps.................................................................. 120 Checklist Analisis ....................................................................................... 121 Visualisasi Konsep .......................................................................................... 122 Pemetaan Materi.............................................................................................. 122 Implikasi Untuk Bisnis.................................................................................... 122 Studi Kasus Dan Refleksi ............................................................................... 123 Bab 7. Transformasi Digital Dan IT Governance ............................................... 124 Elaborasi Konsep ............................................................................................ 124
Catatan Kuliah RPL Bisnis | Halaman 8 Uraian Materi Rinci......................................................................................... 124 Transformasi Digital Sebagai Perubahan Organisasi .................................. 124 COBIT Dan ITIL Sebagai Pasangan Governance-service .......................... 125 Roadmap, Risiko, Dan KPI ......................................................................... 125 Pendalaman Materi Per Unit ........................................................................... 125 Unit 7.1. Transformasi Digital Dan Value Bisnis ....................................... 126 Checklist Analisis ....................................................................................... 127 Unit 7.2. Arsitektur Enterprise Dalam RPL Bisnis ..................................... 128 Checklist Analisis ....................................................................................... 129 Unit 7.3. COBIT 2019 Untuk Governance ................................................. 130 Checklist Analisis ....................................................................................... 131 Unit 7.4. ITIL 4 Untuk Service Management ............................................. 132 Checklist Analisis ....................................................................................... 133 Unit 7.5. Integrasi COBIT, ITIL, Dan RPL ................................................ 134 Checklist Analisis ....................................................................................... 135 Unit 7.6. Risiko Transformasi Digital ......................................................... 136 Checklist Analisis ....................................................................................... 137 Unit 7.7. KPI Governance Dan Continuous Improvement ......................... 138 Checklist Analisis ....................................................................................... 139 Visualisasi Konsep .......................................................................................... 140 Pemetaan Materi.............................................................................................. 140 Implikasi Untuk Bisnis.................................................................................... 140 Studi Kasus Dan Refleksi ............................................................................... 141 Penutup................................................................................................................ 142 Referensi Inti Dari Materi ................................................................................... 142
Catatan Kuliah RPL Bisnis | Halaman 9 Daftar Gambar Gambar 1. Integrasi ERP, CRM, dan Enterprise Application Integration 32 Gambar 2. Logika Manajemen Proyek Perangkat Lunak Bisnis 50 Gambar 3. ISO 25010 sebagai Jembatan Kualitas dan Testing 68 Gambar 4. Secure SDLC dan Lapisan Compliance 86 Gambar 5. Siklus Monitoring, Controlling, dan Change Management 104 Gambar 6. Arsitektur Solusi AI/ML dan Generative AI untuk Bisnis 122 Gambar 7. Integrasi Transformasi Digital, COBIT, ITIL, dan RPL Bisnis 140
Catatan Kuliah RPL Bisnis | Halaman 10 Daftar Tabel Tabel 1.1. Pemetaan materi sistem erp, crm, dan integrasi enterprise 32 Tabel 1.2. Telaah pendalaman: pemetaan proses bisnis enterprise 18 Tabel 1.3. Telaah pendalaman: erp sebagai sistem operasi internal bisnis 20 Tabel 1.4. Telaah pendalaman: crm sebagai sistem relasi dan pengalaman pelanggan 22 Tabel 1.5. Telaah pendalaman: integrasi data erp-crm 24 Tabel 1.6. Telaah pendalaman: enterprise application integration 26 Tabel 1.7. Telaah pendalaman: cloud erp dan cloud crm 28 Tabel 1.8. Telaah pendalaman: governance integrasi enterprise 30 Tabel 2.1. Pemetaan materi manajemen proyek perangkat lunak bisnis 50 Tabel 2.2. Telaah pendalaman: inisiasi proyek dan business case 36 Tabel 2.3. Telaah pendalaman: work breakdown structure 38 Tabel 2.4. Telaah pendalaman: estimasi effort dengan cocomo dan pendekatan modern 40 Tabel 2.5. Telaah pendalaman: perencanaan jadwal dan sumber daya 42 Tabel 2.6. Telaah pendalaman: manajemen risiko proyek software 44 Tabel 2.7. Telaah pendalaman: roi dan evaluasi kelayakan investasi ti 46 Tabel 2.8. Telaah pendalaman: agile project management untuk bisnis 48 Tabel 3.1. Pemetaan materi kualitas perangkat lunak dan software testing enterprise 68 Tabel 3.2. Telaah pendalaman: kualitas sebagai kesesuaian terhadap kebutuhan bisnis 54 Tabel 3.3. Telaah pendalaman: model kualitas iso/iec 25010 56 Tabel 3.4. Telaah pendalaman: perencanaan testing enterprise 58 Tabel 3.5. Telaah pendalaman: test case dan test scenario berbasis proses bisnis 60 Tabel 3.6. Telaah pendalaman: automation testing dan ci/cd 62 Tabel 3.7. Telaah pendalaman: performance dan reliability testing 64 Tabel 3.8. Telaah pendalaman: quality assurance dan audit software 66
Catatan Kuliah RPL Bisnis | Halaman 11 Tabel 4.1. Pemetaan materi keamanan perangkat lunak dan compliance bisnis 86 Tabel 4.2. Telaah pendalaman: prinsip dasar keamanan software bisnis 72 Tabel 4.3. Telaah pendalaman: threat, vulnerability, risk, dan control 74 Tabel 4.4. Telaah pendalaman: secure sdlc 76 Tabel 4.5. Telaah pendalaman: owasp top 10 dalam aplikasi bisnis 78 Tabel 4.6. Telaah pendalaman: gdpr dan perlindungan data pribadi 80 Tabel 4.7. Telaah pendalaman: iso/iec 27001 dan isms 82 Tabel 4.8. Telaah pendalaman: security operations dan compliance monitoring 84 Tabel 5.1. Pemetaan materi monitoring, controlling, change management, dan evaluasi kinerja proyek 104 Tabel 5.2. Telaah pendalaman: monitoring sebagai pengumpulan fakta proyek 90 Tabel 5.3. Telaah pendalaman: controlling terhadap baseline 92 Tabel 5.4. Telaah pendalaman: earned value management 94 Tabel 5.5. Telaah pendalaman: issue management dan eskalasi 96 Tabel 5.6. Telaah pendalaman: integrated change control 98 Tabel 5.7. Telaah pendalaman: project performance review 100 Tabel 5.8. Telaah pendalaman: dashboard kontrol proyek si 102 Tabel 6.1. Pemetaan materi ai/ml dan generative ai untuk solusi bisnis 122 Tabel 6.2. Telaah pendalaman: business understanding untuk solusi ai 108 Tabel 6.3. Telaah pendalaman: data understanding dan data readiness 110 Tabel 6.4. Telaah pendalaman: pemilihan model ai/ml 112 Tabel 6.5. Telaah pendalaman: generative ai dan arsitektur rag 114 Tabel 6.6. Telaah pendalaman: prompt engineering untuk produktivitas bisnis 116 Tabel 6.7. Telaah pendalaman: human-in-the-loop dan pengalaman pengguna 118 Tabel 6.8. Telaah pendalaman: mlops dan llmops 120 Tabel 7.1. Pemetaan materi transformasi digital dan it governance 140 Tabel 7.2. Telaah pendalaman: transformasi digital dan value bisnis 126
Catatan Kuliah RPL Bisnis | Halaman 12 Tabel 7.3. Telaah pendalaman: arsitektur enterprise dalam rpl bisnis 128 Tabel 7.4. Telaah pendalaman: cobit 2019 untuk governance 130 Tabel 7.5. Telaah pendalaman: itil 4 untuk service management 132 Tabel 7.6. Telaah pendalaman: integrasi cobit, itil, dan rpl 134 Tabel 7.7. Telaah pendalaman: risiko transformasi digital 136 Tabel 7.8. Telaah pendalaman: kpi governance dan continuous improvement 138
Catatan Kuliah RPL Bisnis | Halaman 13 Glosarium Istilah Pengertian Ringkas Acceptance Criteria Kriteria yang menyatakan kondisi suatu kebutuhan atau deliverable dianggap diterima oleh pengguna atau pemilik bisnis. Agile Pendekatan pengembangan iteratif dan inkremental yang menekankan kolaborasi, adaptasi, dan pengiriman nilai secara bertahap. API Antarmuka pemrograman aplikasi yang memungkinkan sistem saling bertukar data atau layanan secara terstandar. Baseline Rencana ruang lingkup, jadwal, biaya, atau mutu yang telah disetujui dan menjadi pembanding pelaksanaan proyek. Change Control Board Forum pengambilan keputusan perubahan proyek yang menilai dampak perubahan terhadap scope, biaya, jadwal, mutu, dan risiko. CI/CD Praktik continuous integration dan continuous delivery/deployment untuk membangun, menguji, dan merilis software secara berulang. COBIT Kerangka tata kelola dan manajemen enterprise IT yang berfokus pada value, risk, resource, kontrol, dan kinerja. COCOMO Model estimasi biaya dan effort perangkat lunak yang menggunakan ukuran dan karakteristik proyek sebagai dasar perhitungan. CRM Customer Relationship Management, sistem dan proses untuk mengelola relasi, interaksi, layanan, dan analitik pelanggan. Data Governance Pengelolaan kebijakan, peran, kualitas, akses, keamanan, dan siklus hidup data dalam organisasi. DevOps Pendekatan kolaboratif antara development dan operations untuk mempercepat delivery software tanpa mengorbankan kualitas dan reliabilitas. EAI Enterprise Application Integration, pendekatan integrasi berbagai aplikasi enterprise agar dapat bertukar data dan proses. ERP Enterprise Resource Planning, sistem terpadu untuk mengelola proses internal seperti keuangan, SDM, inventory, produksi, dan pengadaan.
Catatan Kuliah RPL Bisnis | Halaman 14 Istilah Pengertian Ringkas EVM Earned Value Management, teknik pengendalian proyek yang membandingkan planned value, earned value, dan actual cost. GDPR Regulasi perlindungan data pribadi Uni Eropa yang menekankan lawful basis, transparansi, hak subjek data, dan data minimization. Generative AI Jenis AI yang menghasilkan konten baru seperti teks, gambar, kode, ringkasan, atau dialog berdasarkan pola yang dipelajari. Guardrail Batasan teknis dan kebijakan yang mengarahkan sistem AI agar output-nya aman, relevan, dan sesuai konteks. Human-in-the- Loop Desain sistem yang tetap melibatkan manusia untuk verifikasi, koreksi, atau keputusan kritis. ISMS Information Security Management System, sistem manajemen keamanan informasi yang mencakup kebijakan, risiko, kontrol, audit, dan perbaikan. ISO/IEC 25010 Standar model kualitas software yang memuat karakteristik seperti functional suitability, reliability, performance, security, dan maintainability. ISO/IEC 27001 Standar sistem manajemen keamanan informasi untuk mengelola risiko keamanan secara terstruktur. IT Governance Tata kelola TI untuk memastikan teknologi selaras dengan strategi bisnis, memberi nilai, mengelola risiko, dan memakai sumber daya dengan tepat. ITIL Kerangka praktik manajemen layanan TI yang berfokus pada service value, incident, problem, change, request, dan continual improvement. KPI Key Performance Indicator, indikator utama untuk menilai kinerja proses, proyek, layanan, atau outcome bisnis. LLMOps Praktik operasi dan tata kelola aplikasi berbasis model bahasa besar, termasuk monitoring prompt, biaya, latency, evaluasi, dan keamanan. MLOps Praktik pengelolaan siklus hidup model machine learning dari data, training, deployment, monitoring, sampai retraining. OWASP Komunitas dan sumber terbuka keamanan aplikasi yang menyediakan panduan seperti OWASP Top 10.
Catatan Kuliah RPL Bisnis | Halaman 15 Istilah Pengertian Ringkas Privacy by Design Prinsip bahwa perlindungan data pribadi harus dirancang sejak awal dalam arsitektur, proses, dan default sistem. RAG Retrieval-Augmented Generation, pola GenAI yang mengambil pengetahuan dari sumber eksternal sebelum menghasilkan jawaban. Regression Testing Pengujian ulang untuk memastikan perubahan baru tidak merusak fungsi yang sebelumnya berjalan. Risk Register Daftar risiko proyek atau sistem yang memuat penyebab, dampak, probabilitas, owner, mitigasi, dan status. Secure SDLC Siklus pengembangan software yang memasukkan keamanan sejak requirement, desain, implementasi, testing, deployment, dan operasi. Service Value System Model ITIL yang menjelaskan bagaimana komponen organisasi dan aktivitas layanan menciptakan nilai. SLA Service Level Agreement, kesepakatan tingkat layanan seperti availability, response time, dan waktu pemulihan. TDD Test Driven Development, praktik menulis test terlebih dahulu sebelum implementasi kode. Threat Modeling Teknik mengidentifikasi ancaman, aset, alur data, kelemahan, dan mitigasi keamanan sejak tahap desain. UAT User Acceptance Testing, pengujian oleh pengguna atau perwakilan bisnis untuk memvalidasi kesesuaian sistem dengan kebutuhan. WBS Work Breakdown Structure, pemecahan pekerjaan proyek menjadi deliverable dan paket kerja yang lebih mudah dikelola.
Catatan Kuliah RPL Bisnis | Halaman 16 Bab 1. Sistem ERP, CRM, Dan Integrasi Enterprise Pertemuan 9 Fokus pembelajaran Memahami ERP dan CRM sebagai fondasi sistem informasi enterprise. | Menganalisis kebutuhan integrasi data lintas fungsi bisnis. | Mengevaluasi manfaat, risiko, dan tantangan implementasi ERP/CRM. Elaborasi Konsep Enterprise system adalah sistem informasi terintegrasi yang menghubungkan proses, data, aplikasi, dan aktor organisasi. Dalam konteks bisnis, integrasi ini penting karena keputusan manajerial sering membutuhkan data lintas departemen, bukan data yang terisolasi dalam silo. ERP berfokus pada efisiensi operasi internal, seperti keuangan, SDM, pengadaan, inventory, produksi, dan distribusi. CRM berfokus pada pengelolaan hubungan pelanggan, mulai dari penjualan, pemasaran, layanan, analitik, sampai program loyalitas. Nilai bisnis terbesar muncul ketika ERP dan CRM tidak berjalan sendiri-sendiri. Integrasi keduanya membuat organisasi dapat menelusuri hubungan antara permintaan pelanggan, ketersediaan persediaan, proses penjualan, layanan purna jual, dan laporan kinerja bisnis. Uraian Materi Rinci Enterprise System Sebagai Tulang Punggung Organisasi Dalam organisasi modern, proses bisnis jarang berdiri sendiri. Penjualan memerlukan data persediaan, produksi membutuhkan proyeksi permintaan, keuangan memerlukan bukti transaksi, dan manajemen membutuhkan laporan terpadu. Enterprise system menjawab kebutuhan ini dengan menyediakan platform yang menyatukan proses, data, dan pengambilan keputusan. Masalah utama sebelum integrasi biasanya berupa data ganda, format data berbeda, proses manual antar departemen, dan keterlambatan laporan. Kondisi ini menimbulkan risiko keputusan yang terlambat atau tidak akurat. Karena itu, integrasi enterprise perlu dilihat sebagai keputusan strategis, bukan sekadar proyek instalasi aplikasi.
Catatan Kuliah RPL Bisnis | Halaman 17 ERP, CRM, Dan Aliran Data Bisnis ERP mengelola proses internal yang bersifat transaksional dan operasional. Contohnya adalah pencatatan pembelian, pengelolaan inventory, perencanaan produksi, payroll, general ledger, dan laporan keuangan. Kekuatan ERP terletak pada standardisasi proses serta basis data terpusat. CRM mengelola relasi pelanggan sepanjang siklus hidup pelanggan: prospek, penawaran, penjualan, layanan, keluhan, retensi, dan loyalitas. CRM menjadi penting karena nilai bisnis tidak hanya ditentukan oleh efisiensi internal, tetapi juga oleh kemampuan memahami dan mempertahankan pelanggan. Integrasi ERP dan CRM membuat data pelanggan, transaksi, stok, piutang, dan layanan dapat mengalir secara konsisten. Misalnya, ketika pelanggan melakukan pemesanan di CRM, ERP dapat memeriksa stok, menghasilkan dokumen penjualan, memicu pengiriman, dan memperbarui laporan keuangan. Arsitektur Integrasi Dan Tantangannya Integrasi dapat dilakukan melalui database integration, API, middleware, message broker, enterprise service bus, atau kombinasi beberapa pendekatan. API cocok untuk pertukaran layanan yang terstandar, sedangkan message broker berguna ketika sistem harus memproses pesan secara asinkron dan tahan terhadap lonjakan beban. Tantangan teknis meliputi pemetaan struktur data, sinkronisasi real-time, keamanan akses, audit trail, error handling, dan kualitas data historis. Tantangan organisasi meliputi perubahan proses kerja, pelatihan pengguna, resistensi budaya, serta kebutuhan sponsor manajemen yang kuat. Pendalaman Materi Per Unit Bagian ini memperluas materi menjadi unit-unit belajar yang dapat digunakan untuk diskusi kelas, kajian mandiri, atau pengembangan tugas proyek. Setiap unit menghubungkan konsep teknis dengan artefak rekayasa, risiko, metrik, dan keputusan bisnis.
Catatan Kuliah RPL Bisnis | Halaman 18 Unit 1.1. Pemetaan Proses Bisnis Enterprise Unit ini membahas pemetaan proses bisnis enterprise sebagai bagian penting dari topik sistem erp, crm, dan integrasi enterprise. Sudut pandang utamanya adalah proses lintas fungsi, pemilik proses, data input-output, dan titik keputusan. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah pemetaan proses order-to-cash pada perusahaan retail yang menghubungkan penjualan, stok, pengiriman, penagihan, dan layanan pelanggan. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi process map, SIPOC, katalog proses, dan matriks pemilik proses. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah proses lama yang tidak terdokumentasi dapat dipindahkan apa adanya ke sistem baru sehingga inefisiensi ikut terdigitalisasi. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 1.2. Telaah pendalaman: pemetaan proses bisnis enterprise. Dimensi Uraian Analitis Fokus konsep proses lintas fungsi, pemilik proses, data input-output, dan titik keputusan Contoh penerapan pemetaan proses order-to-cash pada perusahaan retail yang menghubungkan penjualan, stok, pengiriman, penagihan, dan layanan pelanggan Artefak utama process map, SIPOC, katalog proses, dan matriks pemilik proses
Catatan Kuliah RPL Bisnis | Halaman 19 Dimensi Uraian Analitis Risiko penting proses lama yang tidak terdokumentasi dapat dipindahkan apa adanya ke sistem baru sehingga inefisiensi ikut terdigitalisasi Metrik evaluasi cycle time, error transaksi, jumlah handoff manual, dan tingkat otomasi proses Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti cycle time, error transaksi, jumlah handoff manual, dan tingkat otomasi proses untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 20 Unit 1.2. ERP Sebagai Sistem Operasi Internal Bisnis Unit ini membahas erp sebagai sistem operasi internal bisnis sebagai bagian penting dari topik sistem erp, crm, dan integrasi enterprise. Sudut pandang utamanya adalah modul keuangan, pengadaan, inventory, produksi, SDM, dan pelaporan yang memakai basis data terpusat. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah penggunaan ERP untuk mengendalikan stok, pembelian, pembayaran vendor, dan laporan laba rugi harian. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi daftar modul, chart of accounts, master data, dan role access matrix. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah master data tidak konsisten membuat laporan lintas modul menjadi tidak dapat dipercaya. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 1.3. Telaah pendalaman: erp sebagai sistem operasi internal bisnis. Dimensi Uraian Analitis Fokus konsep modul keuangan, pengadaan, inventory, produksi, SDM, dan pelaporan yang memakai basis data terpusat Contoh penerapan penggunaan ERP untuk mengendalikan stok, pembelian, pembayaran vendor, dan laporan laba rugi harian Artefak utama daftar modul, chart of accounts, master data, dan role access matrix Risiko penting master data tidak konsisten membuat laporan lintas modul menjadi tidak dapat dipercaya
Catatan Kuliah RPL Bisnis | Halaman 21 Dimensi Uraian Analitis Metrik evaluasi akurasi stok, waktu closing, jumlah transaksi koreksi, dan kepatuhan prosedur Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti akurasi stok, waktu closing, jumlah transaksi koreksi, dan kepatuhan prosedur untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 22 Unit 1.3. CRM Sebagai Sistem Relasi Dan Pengalaman Pelanggan Unit ini membahas crm sebagai sistem relasi dan pengalaman pelanggan sebagai bagian penting dari topik sistem erp, crm, dan integrasi enterprise. Sudut pandang utamanya adalah siklus pelanggan dari prospek sampai loyalitas, termasuk sales, marketing, service, dan customer analytics. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah CRM cloud untuk memantau pipeline penjualan, riwayat interaksi, segmentasi pelanggan, dan keluhan pasca pembelian. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi customer journey map, lead scoring model, service script, dan dashboard pelanggan. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah data pelanggan tersebar atau tidak diperbarui menyebabkan personalisasi layanan gagal. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 1.4. Telaah pendalaman: crm sebagai sistem relasi dan pengalaman pelanggan. Dimensi Uraian Analitis Fokus konsep siklus pelanggan dari prospek sampai loyalitas, termasuk sales, marketing, service, dan customer analytics Contoh penerapan CRM cloud untuk memantau pipeline penjualan, riwayat interaksi, segmentasi pelanggan, dan keluhan pasca pembelian Artefak utama customer journey map, lead scoring model, service script, dan dashboard pelanggan Risiko data pelanggan tersebar atau tidak diperbarui menyebabkan
Catatan Kuliah RPL Bisnis | Halaman 23 Dimensi Uraian Analitis penting personalisasi layanan gagal Metrik evaluasi conversion rate, retention rate, customer satisfaction, dan response time layanan Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti conversion rate, retention rate, customer satisfaction, dan response time layanan untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 24 Unit 1.4. Integrasi Data ERP-CRM Unit ini membahas integrasi data erp-crm sebagai bagian penting dari topik sistem erp, crm, dan integrasi enterprise. Sudut pandang utamanya adalah sinkronisasi pelanggan, produk, stok, pesanan, invoice, pembayaran, dan tiket layanan. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah ketika sales membuat order pada CRM, ERP memvalidasi stok, membuat invoice, dan memperbarui status pengiriman. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi data dictionary, mapping field, API contract, dan integration test log. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah perbedaan definisi data antar sistem menimbulkan duplikasi dan kesalahan laporan. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 1.5. Telaah pendalaman: integrasi data erp-crm. Dimensi Uraian Analitis Fokus konsep sinkronisasi pelanggan, produk, stok, pesanan, invoice, pembayaran, dan tiket layanan Contoh penerapan ketika sales membuat order pada CRM, ERP memvalidasi stok, membuat invoice, dan memperbarui status pengiriman Artefak utama data dictionary, mapping field, API contract, dan integration test log Risiko penting perbedaan definisi data antar sistem menimbulkan duplikasi dan kesalahan laporan
Catatan Kuliah RPL Bisnis | Halaman 25 Metrik evaluasi latency sinkronisasi, jumlah error API, data completeness, dan reconciliation rate Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti latency sinkronisasi, jumlah error API, data completeness, dan reconciliation rate untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 26 Unit 1.5. Enterprise Application Integration Unit ini membahas enterprise application integration sebagai bagian penting dari topik sistem erp, crm, dan integrasi enterprise. Sudut pandang utamanya adalah middleware, API gateway, ESB, message broker, web service, dan event-driven architecture. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah integrasi ERP, e-commerce, payment gateway, warehouse management, dan CRM melalui API gateway dan message queue. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi arsitektur integrasi, sequence diagram, katalog API, dan runbook integrasi. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah single point of failure pada middleware dapat menghentikan banyak layanan sekaligus. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 1.6. Telaah pendalaman: enterprise application integration. Dimensi Uraian Analitis Fokus konsep middleware, API gateway, ESB, message broker, web service, dan event-driven architecture Contoh penerapan integrasi ERP, e-commerce, payment gateway, warehouse management, dan CRM melalui API gateway dan message queue Artefak utama arsitektur integrasi, sequence diagram, katalog API, dan runbook integrasi Risiko single point of failure pada middleware dapat menghentikan
Catatan Kuliah RPL Bisnis | Halaman 27 Dimensi Uraian Analitis penting banyak layanan sekaligus Metrik evaluasi API uptime, throughput pesan, retry success rate, dan mean time to recovery Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti API uptime, throughput pesan, retry success rate, dan mean time to recovery untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 28 Unit 1.6. Cloud ERP Dan Cloud CRM Unit ini membahas cloud erp dan cloud crm sebagai bagian penting dari topik sistem erp, crm, dan integrasi enterprise. Sudut pandang utamanya adalah model SaaS, skalabilitas, biaya langganan, konfigurasi, keamanan cloud, dan integrasi eksternal. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah organisasi menggunakan SaaS CRM agar cabang dan tim lapangan dapat mengakses data pelanggan dari perangkat mobile. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi cloud readiness assessment, konfigurasi tenant, SLA vendor, dan kontrol akses. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah vendor lock-in dan konfigurasi yang tidak terdokumentasi menyulitkan migrasi atau audit. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 1.7. Telaah pendalaman: cloud erp dan cloud crm. Dimensi Uraian Analitis Fokus konsep model SaaS, skalabilitas, biaya langganan, konfigurasi, keamanan cloud, dan integrasi eksternal Contoh penerapan organisasi menggunakan SaaS CRM agar cabang dan tim lapangan dapat mengakses data pelanggan dari perangkat mobile Artefak utama cloud readiness assessment, konfigurasi tenant, SLA vendor, dan kontrol akses Risiko vendor lock-in dan konfigurasi yang tidak terdokumentasi
Catatan Kuliah RPL Bisnis | Halaman 29 Dimensi Uraian Analitis penting menyulitkan migrasi atau audit Metrik evaluasi availability, biaya per pengguna, adoption rate, dan incident layanan cloud Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti availability, biaya per pengguna, adoption rate, dan incident layanan cloud untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 30 Unit 1.7. Governance Integrasi Enterprise Unit ini membahas governance integrasi enterprise sebagai bagian penting dari topik sistem erp, crm, dan integrasi enterprise. Sudut pandang utamanya adalah kepemilikan data, standar integrasi, keamanan, audit trail, perubahan skema, dan prioritas bisnis. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah komite data menetapkan definisi pelanggan aktif agar laporan ERP, CRM, dan dashboard eksekutif konsisten. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi data governance charter, RACI, kebijakan akses, dan log audit. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah tanpa governance, integrasi berkembang sporadis dan sulit dipelihara. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 1.8. Telaah pendalaman: governance integrasi enterprise. Dimensi Uraian Analitis Fokus konsep kepemilikan data, standar integrasi, keamanan, audit trail, perubahan skema, dan prioritas bisnis Contoh penerapan komite data menetapkan definisi pelanggan aktif agar laporan ERP, CRM, dan dashboard eksekutif konsisten Artefak utama data governance charter, RACI, kebijakan akses, dan log audit Risiko penting tanpa governance, integrasi berkembang sporadis dan sulit dipelihara
Catatan Kuliah RPL Bisnis | Halaman 31 Dimensi Uraian Analitis Metrik evaluasi jumlah konflik definisi data, temuan audit, kepatuhan akses, dan waktu penyelesaian isu data Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti jumlah konflik definisi data, temuan audit, kepatuhan akses, dan waktu penyelesaian isu data untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 32 Visualisasi Konsep Gambar 1. Visualisasi ringkas sistem erp, crm, dan integrasi enterprise. Pemetaan Materi Tabel 1.1. Pemetaan materi sistem erp, crm, dan integrasi enterprise. Aspek ERP CRM Implikasi Bisnis Fokus Operasi internal Pelanggan dan pasar Keduanya harus dipadukan agar operasi mampu merespons kebutuhan pelanggan. Data utama Transaksi, stok, keuangan, produksi Prospek, pelanggan, interaksi, keluhan Integrasi data mengurangi duplikasi dan mempercepat keputusan. Ukuran sukses Efisiensi, akurasi, produktivitas Retensi, kepuasan, konversi Manajemen perlu menilai outcome operasional dan outcome pelanggan. Risiko Migrasi data, biaya, perubahan proses Kualitas data pelanggan, adopsi pengguna Change management menjadi faktor keberhasilan implementasi. Implikasi Untuk Bisnis • Keputusan teknis perlu diterjemahkan menjadi dampak pada biaya, risiko, mutu layanan, kepuasan pengguna, dan nilai strategis organisasi.
Catatan Kuliah RPL Bisnis | Halaman 33 • Dokumentasi requirement, desain, testing, risiko, dan perubahan harus diperlakukan sebagai artefak manajerial, bukan administrasi tambahan. • Keberhasilan software bisnis bergantung pada keselarasan antara proses, data, pengguna, teknologi, dan tata kelola. Studi Kasus Dan Refleksi Studi kasus Perusahaan retail yang mengintegrasikan ERP dan CRM dapat menampilkan stok real-time kepada tim penjualan, memicu rekomendasi produk berdasarkan riwayat pelanggan, dan menghasilkan laporan profitabilitas per segmen pelanggan. Risiko utamanya adalah kualitas data lama, resistensi pengguna, dan keamanan akses antar sistem. • Apa keputusan desain yang paling menentukan keberhasilan kasus tersebut? • Risiko apa yang harus dimasukkan ke risk register sejak awal? • Metrik apa yang dapat dipakai untuk membuktikan manfaat bisnisnya?
Catatan Kuliah RPL Bisnis | Halaman 34 Bab 2. Manajemen Proyek Perangkat Lunak Bisnis Pertemuan 10 Fokus pembelajaran Menyusun WBS sebagai dasar perencanaan proyek perangkat lunak bisnis. | Memahami estimasi effort, biaya, dan durasi dengan COCOMO. | Menghubungkan risiko proyek dengan ROI dan kelayakan bisnis. Elaborasi Konsep Manajemen proyek perangkat lunak bisnis bertujuan memastikan proyek memiliki ruang lingkup yang jelas, sumber daya yang realistis, kontrol risiko yang memadai, dan manfaat bisnis yang dapat dibuktikan. WBS memecah proyek menjadi paket kerja yang lebih kecil sehingga tim dapat mengestimasi, menugaskan, menjadwalkan, dan memantau pekerjaan. Untuk proyek ERP/CRM, WBS biasanya mencakup analisis kebutuhan, desain proses, konfigurasi, migrasi data, integrasi, testing, pelatihan, dan deployment. COCOMO memperkenalkan cara berpikir kuantitatif dalam estimasi. Walaupun ukuran KLOC tidak selalu mudah diterapkan pada sistem modern berbasis konfigurasi, prinsipnya tetap berguna: kompleksitas, pengalaman tim, integrasi, dan kualitas requirement memengaruhi effort. Uraian Materi Rinci Project Charter, Scope, Dan Baseline Sebelum WBS dibuat, proyek perlu memiliki project charter atau dokumen inisiasi yang menjelaskan tujuan, sponsor, ruang lingkup awal, asumsi, batasan, manfaat bisnis, dan kriteria sukses. Dokumen ini menjadi dasar legitimasi proyek dan membantu mencegah perbedaan tafsir antara tim teknis dan pemilik bisnis. Scope perlu didefinisikan dalam bentuk deliverable yang dapat diverifikasi. Contohnya bukan hanya 'membuat sistem CRM', tetapi modul prospek, pipeline penjualan, dashboard sales, integrasi email, migrasi data pelanggan, dan laporan performa. Semakin jelas scope, semakin mudah proyek dikendalikan. WBS Dan Estimasi Effort WBS memecah pekerjaan menjadi bagian yang lebih kecil agar estimasi menjadi lebih masuk akal. Pada level atas terdapat fase seperti analisis, desain,
Catatan Kuliah RPL Bisnis | Halaman 35 implementasi, testing, deployment, dan training. Pada level lebih rinci, setiap fase dipecah menjadi aktivitas yang memiliki owner, durasi, output, dan dependensi. COCOMO mengajarkan bahwa effort dipengaruhi oleh ukuran software, kompleksitas, keandalan yang diminta, pengalaman tim, tool, dan lingkungan pengembangan. Untuk proyek bisnis modern, estimasi tidak selalu berbasis KLOC; organisasi dapat mengombinasikan story point, function point, use case point, atau estimasi berbasis paket kerja. Risk, ROI, Dan Keputusan Manajerial Risk management perlu dilakukan sejak awal karena proyek software bisnis rentan terhadap perubahan kebutuhan, ketergantungan vendor, integrasi sulit, data tidak bersih, jadwal ketat, dan keterbatasan kompetensi pengguna. Risiko harus memiliki probabilitas, dampak, owner, strategi mitigasi, dan indikator pemicu. ROI membantu menghubungkan proyek software dengan manfaat bisnis. Benefit dapat berupa penghematan biaya, peningkatan pendapatan, pengurangan waktu proses, penurunan error, kepatuhan regulasi, atau peningkatan kepuasan pelanggan. ROI yang baik harus menyebutkan asumsi, periode evaluasi, dan manfaat yang dapat diukur. Pendalaman Materi Per Unit Bagian ini memperluas materi menjadi unit-unit belajar yang dapat digunakan untuk diskusi kelas, kajian mandiri, atau pengembangan tugas proyek. Setiap unit menghubungkan konsep teknis dengan artefak rekayasa, risiko, metrik, dan keputusan bisnis.
Catatan Kuliah RPL Bisnis | Halaman 36 Unit 2.1. Inisiasi Proyek Dan Business Case Unit ini membahas inisiasi proyek dan business case sebagai bagian penting dari topik manajemen proyek perangkat lunak bisnis. Sudut pandang utamanya adalah masalah bisnis, sponsor, manfaat, constraint, asumsi, dan ukuran keberhasilan. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah perusahaan menginisiasi proyek CRM untuk menurunkan kehilangan prospek dan mempercepat follow-up sales. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi project charter, business case, stakeholder register, dan benefit statement. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah proyek dimulai karena tren teknologi, bukan karena masalah bisnis yang jelas. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 2.2. Telaah pendalaman: inisiasi proyek dan business case. Dimensi Uraian Analitis Fokus konsep masalah bisnis, sponsor, manfaat, constraint, asumsi, dan ukuran keberhasilan Contoh penerapan perusahaan menginisiasi proyek CRM untuk menurunkan kehilangan prospek dan mempercepat follow-up sales Artefak utama project charter, business case, stakeholder register, dan benefit statement Risiko penting proyek dimulai karena tren teknologi, bukan karena masalah bisnis yang jelas
Catatan Kuliah RPL Bisnis | Halaman 37 Dimensi Uraian Analitis Metrik evaluasi kelengkapan charter, clarity of scope, sponsor commitment, dan benefit confidence Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti kelengkapan charter, clarity of scope, sponsor commitment, dan benefit confidence untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 38 Unit 2.2. Work Breakdown Structure Unit ini membahas work breakdown structure sebagai bagian penting dari topik manajemen proyek perangkat lunak bisnis. Sudut pandang utamanya adalah deliverable, paket kerja, dependensi, owner, dan acceptance criteria. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah WBS proyek ERP memisahkan analisis proses, konfigurasi modul, migrasi data, integrasi, UAT, training, dan go-live. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi WBS dictionary, responsibility matrix, dan work package sheet. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah WBS terlalu umum membuat estimasi dan kontrol proyek menjadi lemah. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 2.3. Telaah pendalaman: work breakdown structure. Dimensi Uraian Analitis Fokus konsep deliverable, paket kerja, dependensi, owner, dan acceptance criteria Contoh penerapan WBS proyek ERP memisahkan analisis proses, konfigurasi modul, migrasi data, integrasi, UAT, training, dan go-live Artefak utama WBS dictionary, responsibility matrix, dan work package sheet Risiko penting WBS terlalu umum membuat estimasi dan kontrol proyek menjadi lemah
Catatan Kuliah RPL Bisnis | Halaman 39 Dimensi Uraian Analitis Metrik evaluasi jumlah work package jelas, estimasi per paket, dan persentase deliverable tervalidasi Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti jumlah work package jelas, estimasi per paket, dan persentase deliverable tervalidasi untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 40 Unit 2.3. Estimasi Effort Dengan COCOMO Dan Pendekatan Modern Unit ini membahas estimasi effort dengan cocomo dan pendekatan modern sebagai bagian penting dari topik manajemen proyek perangkat lunak bisnis. Sudut pandang utamanya adalah ukuran software, kompleksitas, mode proyek, pengalaman tim, tool, dan risiko integrasi. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah estimasi modul reporting dilakukan dengan membandingkan jumlah fungsi, sumber data, dan kompleksitas aturan bisnis. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi estimation sheet, asumsi estimasi, dan basis of estimate. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah estimasi politis yang terlalu optimistis menyebabkan keterlambatan dan penurunan mutu. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 2.4. Telaah pendalaman: estimasi effort dengan cocomo dan pendekatan modern. Dimensi Uraian Analitis Fokus konsep ukuran software, kompleksitas, mode proyek, pengalaman tim, tool, dan risiko integrasi Contoh penerapan estimasi modul reporting dilakukan dengan membandingkan jumlah fungsi, sumber data, dan kompleksitas aturan bisnis Artefak utama estimation sheet, asumsi estimasi, dan basis of estimate Risiko penting estimasi politis yang terlalu optimistis menyebabkan keterlambatan dan penurunan mutu
Catatan Kuliah RPL Bisnis | Halaman 41 Dimensi Uraian Analitis Metrik evaluasi estimate variance, velocity, effort actual vs planned, dan schedule confidence Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti estimate variance, velocity, effort actual vs planned, dan schedule confidence untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 42 Unit 2.4. Perencanaan Jadwal Dan Sumber Daya Unit ini membahas perencanaan jadwal dan sumber daya sebagai bagian penting dari topik manajemen proyek perangkat lunak bisnis. Sudut pandang utamanya adalah milestone, critical path, kapasitas tim, dependency, kalender kerja, dan rencana vendor. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah tim membagi pekerjaan sprint untuk modul inventory sambil menunggu API vendor payment siap diuji. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi Gantt chart, sprint plan, resource plan, dan dependency log. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah ketergantungan eksternal yang tidak dipantau dapat menghambat seluruh jadwal. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 2.5. Telaah pendalaman: perencanaan jadwal dan sumber daya. Dimensi Uraian Analitis Fokus konsep milestone, critical path, kapasitas tim, dependency, kalender kerja, dan rencana vendor Contoh penerapan tim membagi pekerjaan sprint untuk modul inventory sambil menunggu API vendor payment siap diuji Artefak utama Gantt chart, sprint plan, resource plan, dan dependency log Risiko penting ketergantungan eksternal yang tidak dipantau dapat menghambat seluruh jadwal
Catatan Kuliah RPL Bisnis | Halaman 43 Dimensi Uraian Analitis Metrik evaluasi milestone achievement, blocked days, resource utilization, dan lead time task Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti milestone achievement, blocked days, resource utilization, dan lead time task untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 44 Unit 2.5. Manajemen Risiko Proyek Software Unit ini membahas manajemen risiko proyek software sebagai bagian penting dari topik manajemen proyek perangkat lunak bisnis. Sudut pandang utamanya adalah identifikasi risiko teknis, bisnis, organisasi, jadwal, biaya, keamanan, dan adopsi. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah risiko migrasi data pelanggan dimitigasi dengan profiling data, cleansing, dry run, dan fallback plan. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi risk register, risk matrix, mitigation plan, dan contingency plan. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah risiko dicatat tetapi tidak memiliki owner dan indikator pemicu. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 2.6. Telaah pendalaman: manajemen risiko proyek software. Dimensi Uraian Analitis Fokus konsep identifikasi risiko teknis, bisnis, organisasi, jadwal, biaya, keamanan, dan adopsi Contoh penerapan risiko migrasi data pelanggan dimitigasi dengan profiling data, cleansing, dry run, dan fallback plan Artefak utama risk register, risk matrix, mitigation plan, dan contingency plan Risiko penting risiko dicatat tetapi tidak memiliki owner dan indikator pemicu
Catatan Kuliah RPL Bisnis | Halaman 45 Dimensi Uraian Analitis Metrik evaluasi jumlah risiko high, aging risk, mitigation completion, dan residual risk Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti jumlah risiko high, aging risk, mitigation completion, dan residual risk untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 46 Unit 2.6. ROI Dan Evaluasi Kelayakan Investasi TI Unit ini membahas roi dan evaluasi kelayakan investasi ti sebagai bagian penting dari topik manajemen proyek perangkat lunak bisnis. Sudut pandang utamanya adalah benefit finansial dan nonfinansial, biaya langsung, biaya perubahan, payback, dan nilai strategis. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah CRM dinilai dari peningkatan konversi, pengurangan waktu administrasi, dan peningkatan retensi pelanggan. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi ROI worksheet, benefit map, cost model, dan benefit realization plan. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah manfaat tidak diukur setelah go-live sehingga keberhasilan proyek sulit dibuktikan. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 2.7. Telaah pendalaman: roi dan evaluasi kelayakan investasi ti. Dimensi Uraian Analitis Fokus konsep benefit finansial dan nonfinansial, biaya langsung, biaya perubahan, payback, dan nilai strategis Contoh penerapan CRM dinilai dari peningkatan konversi, pengurangan waktu administrasi, dan peningkatan retensi pelanggan Artefak utama ROI worksheet, benefit map, cost model, dan benefit realization plan Risiko penting manfaat tidak diukur setelah go-live sehingga keberhasilan proyek sulit dibuktikan
Catatan Kuliah RPL Bisnis | Halaman 47 Dimensi Uraian Analitis Metrik evaluasi ROI aktual, payback period, adoption rate, dan productivity gain Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti ROI aktual, payback period, adoption rate, dan productivity gain untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 48 Unit 2.7. Agile Project Management Untuk Bisnis Unit ini membahas agile project management untuk bisnis sebagai bagian penting dari topik manajemen proyek perangkat lunak bisnis. Sudut pandang utamanya adalah iterasi, backlog, prioritas nilai, feedback pengguna, incremental delivery, dan adaptasi. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah fitur dashboard penjualan dirilis bertahap agar manajer sales dapat memberi umpan balik sejak sprint awal. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi product backlog, sprint goal, burndown chart, dan review notes. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah Agile disalahpahami sebagai tanpa dokumentasi dan tanpa kontrol scope. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 2.8. Telaah pendalaman: agile project management untuk bisnis. Dimensi Uraian Analitis Fokus konsep iterasi, backlog, prioritas nilai, feedback pengguna, incremental delivery, dan adaptasi Contoh penerapan fitur dashboard penjualan dirilis bertahap agar manajer sales dapat memberi umpan balik sejak sprint awal Artefak utama product backlog, sprint goal, burndown chart, dan review notes Risiko penting Agile disalahpahami sebagai tanpa dokumentasi dan tanpa kontrol scope
Catatan Kuliah RPL Bisnis | Halaman 49 Dimensi Uraian Analitis Metrik evaluasi velocity stability, sprint predictability, defect leakage, dan value delivered Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti velocity stability, sprint predictability, defect leakage, dan value delivered untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 50 Visualisasi Konsep Gambar 2. Visualisasi ringkas manajemen proyek perangkat lunak bisnis. Pemetaan Materi Tabel 2.1. Pemetaan materi manajemen proyek perangkat lunak bisnis. Komponen Pertanyaan Kunci Output yang Diharapkan WBS Pekerjaan apa saja yang harus diselesaikan? Daftar deliverable dan paket kerja yang dapat ditugaskan. Estimasi Berapa effort, biaya, dan durasi yang realistis? Estimasi berbasis asumsi, ukuran, kompleksitas, dan sumber daya. Risiko Apa yang dapat menggagalkan proyek? Risk register, prioritas risiko, strategi mitigasi. ROI Apakah manfaat bisnis melebihi biaya? Perbandingan benefit, cost, payback, dan nilai strategis. Implikasi Untuk Bisnis • Keputusan teknis perlu diterjemahkan menjadi dampak pada biaya, risiko, mutu layanan, kepuasan pengguna, dan nilai strategis organisasi. • Dokumentasi requirement, desain, testing, risiko, dan perubahan harus diperlakukan sebagai artefak manajerial, bukan administrasi tambahan. • Keberhasilan software bisnis bergantung pada keselarasan antara proses, data, pengguna, teknologi, dan tata kelola.
Catatan Kuliah RPL Bisnis | Halaman 51 Studi Kasus Dan Refleksi Studi kasus Dalam proyek CRM cloud, WBS dapat memisahkan pekerjaan discovery, konfigurasi pipeline penjualan, integrasi email, migrasi data pelanggan, UAT, dan training. Risiko utama meliputi data tidak bersih, perubahan kebutuhan, integrasi API, dan adopsi sales team. ROI dihitung dari peningkatan konversi, efisiensi follow-up, dan pengurangan pekerjaan manual. • Apa keputusan desain yang paling menentukan keberhasilan kasus tersebut? • Risiko apa yang harus dimasukkan ke risk register sejak awal? • Metrik apa yang dapat dipakai untuk membuktikan manfaat bisnisnya?
Catatan Kuliah RPL Bisnis | Halaman 52 Bab 3. Kualitas Perangkat Lunak Dan Software Testing Enterprise Pertemuan 11 Fokus pembelajaran Menjelaskan kualitas perangkat lunak dengan kerangka ISO/IEC 25010. | Merancang pengujian enterprise yang mencakup fungsi dan non-fungsi. | Menggunakan metrik kualitas untuk evaluasi dan perbaikan berkelanjutan. Elaborasi Konsep Kualitas perangkat lunak tidak cukup dimaknai sebagai bebas bug. Untuk sistem bisnis, kualitas berarti perangkat lunak memenuhi kebutuhan pengguna, aman, andal, cepat, mudah digunakan, mudah dipelihara, dan mampu beroperasi di lingkungan enterprise. ISO/IEC 25010 menyediakan delapan karakteristik kualitas: functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, dan portability. Setiap karakteristik perlu diterjemahkan menjadi kriteria penerimaan dan test case. Testing adalah mekanisme untuk mengumpulkan bukti kualitas. Unit testing memeriksa komponen kecil, integration testing memeriksa hubungan antar modul, system testing memeriksa sistem utuh, regression testing menjaga agar perubahan tidak merusak fungsi lama, dan acceptance testing memastikan kebutuhan bisnis terpenuhi. Uraian Materi Rinci Kualitas Sebagai Atribut Multidimensi Dalam konteks enterprise, software yang benar secara fungsi belum tentu berkualitas jika lambat, sulit digunakan, tidak aman, atau sulit dipelihara. Karena itu, kualitas harus dirumuskan dalam requirement fungsional dan non-fungsional. Requirement non-fungsional perlu dibuat terukur, misalnya response time maksimal, availability minimum, atau batas jumlah defect kritis. ISO/IEC 25010 membantu organisasi menilai kualitas secara sistematis. Model ini membuat tim tidak hanya bertanya 'apakah fitur berjalan?', tetapi juga 'apakah fitur efisien, aman, kompatibel, dapat dipakai, andal, mudah dirawat, dan portabel?'.
Catatan Kuliah RPL Bisnis | Halaman 53 Strategi Testing Enterprise Testing enterprise perlu disusun berlapis. Unit testing menjaga kualitas komponen kecil; integration testing memastikan modul saling berkomunikasi; system testing memeriksa proses end-to-end; acceptance testing memvalidasi kebutuhan bisnis; regression testing menjaga stabilitas ketika ada perubahan. Test case yang baik memiliki precondition, data uji, langkah pengujian, expected result, actual result, status, dan bukti. Test scenario digunakan untuk menggambarkan alur bisnis yang lebih panjang, misalnya proses order-to-cash dari pembuatan pesanan sampai pencatatan pembayaran. Metrics Dan Continuous Improvement Metrik seperti defect density, code coverage, mean time to failure, response time, throughput, dan jumlah vulnerability membantu tim membuat keputusan berbasis bukti. Metrik tidak boleh dipakai secara mekanis; angka coverage tinggi tidak otomatis berarti kualitas tinggi jika test case tidak relevan dengan risiko bisnis. Dalam Agile dan DevOps, testing bergeser ke arah continuous testing. Artinya, pengujian dijalankan berulang dalam pipeline CI/CD, hasilnya dipantau, dan feedback digunakan untuk memperbaiki requirement, desain, kode, dan proses kerja tim. Pendalaman Materi Per Unit Bagian ini memperluas materi menjadi unit-unit belajar yang dapat digunakan untuk diskusi kelas, kajian mandiri, atau pengembangan tugas proyek. Setiap unit menghubungkan konsep teknis dengan artefak rekayasa, risiko, metrik, dan keputusan bisnis.
Catatan Kuliah RPL Bisnis | Halaman 54 Unit 3.1. Kualitas Sebagai Kesesuaian Terhadap Kebutuhan Bisnis Unit ini membahas kualitas sebagai kesesuaian terhadap kebutuhan bisnis sebagai bagian penting dari topik kualitas perangkat lunak dan software testing enterprise. Sudut pandang utamanya adalah kebutuhan fungsional, kebutuhan non- fungsional, ekspektasi pengguna, dan risiko operasional. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah sistem pembayaran dianggap berkualitas bila transaksi benar, cepat, aman, mudah digunakan, dan dapat diaudit. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi quality requirement, acceptance criteria, quality plan, dan traceability matrix. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah kualitas direduksi menjadi bebas bug sehingga aspek performa dan keamanan terabaikan. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 3.2. Telaah pendalaman: kualitas sebagai kesesuaian terhadap kebutuhan bisnis. Dimensi Uraian Analitis Fokus konsep kebutuhan fungsional, kebutuhan non-fungsional, ekspektasi pengguna, dan risiko operasional Contoh penerapan sistem pembayaran dianggap berkualitas bila transaksi benar, cepat, aman, mudah digunakan, dan dapat diaudit Artefak utama quality requirement, acceptance criteria, quality plan, dan traceability matrix Risiko kualitas direduksi menjadi bebas bug sehingga aspek performa
Catatan Kuliah RPL Bisnis | Halaman 55 Dimensi Uraian Analitis penting dan keamanan terabaikan Metrik evaluasi defect severity, user satisfaction, availability, dan compliance finding Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti defect severity, user satisfaction, availability, dan compliance finding untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 56 Unit 3.2. Model Kualitas ISO/IEC 25010 Unit ini membahas model kualitas iso/iec 25010 sebagai bagian penting dari topik kualitas perangkat lunak dan software testing enterprise. Sudut pandang utamanya adalah functional suitability, reliability, performance efficiency, usability, security, compatibility, maintainability, dan portability. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah aplikasi CRM dievaluasi bukan hanya dari fitur kontak, tetapi juga keamanan akses, kemudahan penggunaan, dan integrasi mobile. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi quality model mapping, checklist ISO 25010, dan quality scorecard. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah karakteristik kualitas tidak diterjemahkan menjadi testable requirement. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 3.3. Telaah pendalaman: model kualitas iso/iec 25010. Dimensi Uraian Analitis Fokus konsep functional suitability, reliability, performance efficiency, usability, security, compatibility, maintainability, dan portability Contoh penerapan aplikasi CRM dievaluasi bukan hanya dari fitur kontak, tetapi juga keamanan akses, kemudahan penggunaan, dan integrasi mobile Artefak utama quality model mapping, checklist ISO 25010, dan quality scorecard
Catatan Kuliah RPL Bisnis | Halaman 57 Dimensi Uraian Analitis Risiko penting karakteristik kualitas tidak diterjemahkan menjadi testable requirement Metrik evaluasi quality attribute coverage, requirement volatility, dan acceptance pass rate Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti quality attribute coverage, requirement volatility, dan acceptance pass rate untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 58 Unit 3.3. Perencanaan Testing Enterprise Unit ini membahas perencanaan testing enterprise sebagai bagian penting dari topik kualitas perangkat lunak dan software testing enterprise. Sudut pandang utamanya adalah test strategy, test level, test type, test environment, data uji, dan jadwal eksekusi. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah tim menyusun rencana uji ERP dari unit testing, integration testing, system testing, sampai UAT. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi test plan, test scenario, test case repository, dan environment checklist. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah environment uji berbeda dari production sehingga defect kritis baru muncul setelah go-live. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 3.4. Telaah pendalaman: perencanaan testing enterprise. Dimensi Uraian Analitis Fokus konsep test strategy, test level, test type, test environment, data uji, dan jadwal eksekusi Contoh penerapan tim menyusun rencana uji ERP dari unit testing, integration testing, system testing, sampai UAT Artefak utama test plan, test scenario, test case repository, dan environment checklist Risiko penting environment uji berbeda dari production sehingga defect kritis baru muncul setelah go-live
Catatan Kuliah RPL Bisnis | Halaman 59 Dimensi Uraian Analitis Metrik evaluasi test execution rate, blocked test, defect discovery rate, dan environment readiness Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti test execution rate, blocked test, defect discovery rate, dan environment readiness untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 60 Unit 3.4. Test Case Dan Test Scenario Berbasis Proses Bisnis Unit ini membahas test case dan test scenario berbasis proses bisnis sebagai bagian penting dari topik kualitas perangkat lunak dan software testing enterprise. Sudut pandang utamanya adalah alur utama, variasi, exception, validasi data, dan expected result. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah skenario order-to-cash mencakup order, stok, diskon, invoice, pembayaran, retur, dan laporan. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi test case, test data set, evidence screenshot, dan defect report. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah test case hanya memeriksa happy path dan mengabaikan exception bisnis. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 3.5. Telaah pendalaman: test case dan test scenario berbasis proses bisnis. Dimensi Uraian Analitis Fokus konsep alur utama, variasi, exception, validasi data, dan expected result Contoh penerapan skenario order-to-cash mencakup order, stok, diskon, invoice, pembayaran, retur, dan laporan Artefak utama test case, test data set, evidence screenshot, dan defect report Risiko penting test case hanya memeriksa happy path dan mengabaikan exception bisnis
Catatan Kuliah RPL Bisnis | Halaman 61 Dimensi Uraian Analitis Metrik evaluasi scenario coverage, pass rate, defect severity, dan retest success Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti scenario coverage, pass rate, defect severity, dan retest success untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 62 Unit 3.5. Automation Testing Dan CI/CD Unit ini membahas automation testing dan ci/cd sebagai bagian penting dari topik kualitas perangkat lunak dan software testing enterprise. Sudut pandang utamanya adalah unit test, API test, UI regression, performance baseline, dan pipeline quality gate. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah setiap perubahan API CRM menjalankan regression test otomatis sebelum deployment ke staging. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi pipeline configuration, automated test suite, dan quality gate report. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah automation rapuh dan sering gagal karena data uji tidak stabil. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 3.6. Telaah pendalaman: automation testing dan ci/cd. Dimensi Uraian Analitis Fokus konsep unit test, API test, UI regression, performance baseline, dan pipeline quality gate Contoh penerapan setiap perubahan API CRM menjalankan regression test otomatis sebelum deployment ke staging Artefak pipeline configuration, automated test suite, dan quality gate
Catatan Kuliah RPL Bisnis | Halaman 63 utama report Risiko penting automation rapuh dan sering gagal karena data uji tidak stabil Metrik evaluasi automation pass rate, flaky test rate, build failure, dan deployment frequency Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti automation pass rate, flaky test rate, build failure, dan deployment frequency untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 64 Unit 3.6. Performance Dan Reliability Testing Unit ini membahas performance dan reliability testing sebagai bagian penting dari topik kualitas perangkat lunak dan software testing enterprise. Sudut pandang utamanya adalah response time, throughput, concurrency, failover, recovery, dan capacity planning. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah sistem e-commerce diuji menghadapi lonjakan transaksi saat kampanye promosi. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi load test script, capacity model, monitoring dashboard, dan incident simulation log. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah kapasitas tidak diuji sebelum puncak transaksi bisnis. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 3.7. Telaah pendalaman: performance dan reliability testing. Dimensi Uraian Analitis Fokus konsep response time, throughput, concurrency, failover, recovery, dan capacity planning Contoh penerapan sistem e-commerce diuji menghadapi lonjakan transaksi saat kampanye promosi Artefak utama load test script, capacity model, monitoring dashboard, dan incident simulation log
Catatan Kuliah RPL Bisnis | Halaman 65 Risiko penting kapasitas tidak diuji sebelum puncak transaksi bisnis Metrik evaluasi p95 response time, throughput, error rate, availability, dan recovery time Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti p95 response time, throughput, error rate, availability, dan recovery time untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 66 Unit 3.7. Quality Assurance Dan Audit Software Unit ini membahas quality assurance dan audit software sebagai bagian penting dari topik kualitas perangkat lunak dan software testing enterprise. Sudut pandang utamanya adalah review kode, audit konfigurasi, independent testing, root cause analysis, dan continuous improvement. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah defect berulang pada modul billing dianalisis untuk memperbaiki requirement, desain, dan test case. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi QA report, root cause analysis, action item log, dan lessons learned. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah QA hanya menjadi pemeriksaan akhir, bukan praktik berkelanjutan. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 3.8. Telaah pendalaman: quality assurance dan audit software. Dimensi Uraian Analitis Fokus konsep review kode, audit konfigurasi, independent testing, root cause analysis, dan continuous improvement Contoh penerapan defect berulang pada modul billing dianalisis untuk memperbaiki requirement, desain, dan test case Artefak QA report, root cause analysis, action item log, dan lessons
Catatan Kuliah RPL Bisnis | Halaman 67 utama learned Risiko penting QA hanya menjadi pemeriksaan akhir, bukan praktik berkelanjutan Metrik evaluasi defect recurrence, review finding closure, audit score, dan improvement completion Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti defect recurrence, review finding closure, audit score, dan improvement completion untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 68 Visualisasi Konsep Gambar 3. Visualisasi ringkas kualitas perangkat lunak dan software testing enterprise. Pemetaan Materi Tabel 3.1. Pemetaan materi kualitas perangkat lunak dan software testing enterprise. Karakteristik Contoh Indikator Contoh Pengujian Functional suitability Fungsi sesuai requirement Uji alur transaksi, validasi aturan bisnis. Performance efficiency Response time, throughput Load test, stress test, endurance test. Security Jumlah vulnerability, kontrol akses SAST, DAST, penetration testing. Reliability MTTF, error rate, availability Failover test, recovery test, monitoring error. Maintainability Kompleksitas kode, coverage, modularitas Code review, static analysis, regression suite.
Catatan Kuliah RPL Bisnis | Halaman 69 Implikasi Untuk Bisnis • Keputusan teknis perlu diterjemahkan menjadi dampak pada biaya, risiko, mutu layanan, kepuasan pengguna, dan nilai strategis organisasi. • Dokumentasi requirement, desain, testing, risiko, dan perubahan harus diperlakukan sebagai artefak manajerial, bukan administrasi tambahan. • Keberhasilan software bisnis bergantung pada keselarasan antara proses, data, pengguna, teknologi, dan tata kelola. Studi Kasus Dan Refleksi Studi kasus Pada ERP, pengujian integrasi modul keuangan dan inventory harus memastikan transaksi penjualan mengurangi stok, membentuk jurnal akuntansi, dan memperbarui laporan. Pada CRM, pengujian harus memastikan data pelanggan konsisten dari formulir prospek sampai layanan purna jual. • Apa keputusan desain yang paling menentukan keberhasilan kasus tersebut? • Risiko apa yang harus dimasukkan ke risk register sejak awal? • Metrik apa yang dapat dipakai untuk membuktikan manfaat bisnisnya?
Catatan Kuliah RPL Bisnis | Halaman 70 Bab 4. Keamanan Perangkat Lunak Dan Compliance Bisnis Pertemuan 12 Fokus pembelajaran Memahami keamanan perangkat lunak sebagai bagian dari kualitas dan tata kelola bisnis. | Mengidentifikasi risiko aplikasi dengan OWASP dan konsep threat, vulnerability, risk, control. | Menghubungkan privacy by design, GDPR, dan ISO/IEC 27001 dalam rancangan software. Elaborasi Konsep Keamanan perangkat lunak bisnis berangkat dari perlindungan data, transaksi, reputasi, dan keberlanjutan operasional. Serangan terhadap aplikasi dapat menyebabkan downtime, kebocoran data pelanggan, manipulasi transaksi, dan kehilangan kepercayaan. Secure SDLC menempatkan kontrol keamanan sejak requirement sampai operasi. Kebutuhan keamanan ditentukan di awal, desain menggunakan threat modeling, implementasi menerapkan secure coding, testing menggunakan vulnerability scanning dan penetration testing, sedangkan deployment membutuhkan hardening dan monitoring. OWASP membantu memprioritaskan risiko teknis aplikasi. GDPR menekankan perlindungan data pribadi dan hak subjek data. ISO/IEC 27001 memberi kerangka sistem manajemen keamanan informasi agar kontrol tidak hanya teknis, tetapi juga mencakup kebijakan, orang, proses, dan audit. Uraian Materi Rinci Keamanan Sebagai Kebutuhan Bisnis Keamanan perangkat lunak tidak boleh diposisikan sebagai pekerjaan tambahan di akhir proyek. Aplikasi bisnis memproses data pelanggan, transaksi, kontrak, informasi keuangan, dan rahasia operasional. Ketika aplikasi gagal menjaga confidentiality, integrity, dan availability, dampaknya langsung terasa pada kerugian finansial, reputasi, dan kepatuhan. Konsep threat, vulnerability, risk, dan control membantu analisis keamanan menjadi terstruktur. Threat adalah sumber ancaman, vulnerability adalah kelemahan, risk adalah kombinasi kemungkinan dan dampak, sedangkan control adalah mekanisme pencegahan, deteksi, koreksi, atau pemulihan.
Catatan Kuliah RPL Bisnis | Halaman 71 OWASP Dan Secure Coding OWASP Top 10 dapat digunakan sebagai checklist awal untuk menilai risiko aplikasi web. Broken access control, injection, security misconfiguration, vulnerable components, dan authentication failure sering muncul karena desain akses yang lemah, validasi input buruk, konfigurasi tidak aman, atau dependency tidak diperbarui. Secure coding menuntut praktik seperti validasi input, output encoding, parameterized query, least privilege, session management yang benar, logging yang aman, dan pengelolaan secret. Code review dan static analysis membantu menemukan kelemahan sebelum aplikasi masuk production. Privacy Dan Tata Kelola Keamanan GDPR dan prinsip perlindungan data pribadi mengajarkan bahwa software harus mengumpulkan data seperlunya, menjelaskan tujuan pemrosesan, membatasi akses, mengatur retensi, dan menyediakan mekanisme hak pengguna. Privacy by design berarti aspek privasi dirancang sejak awal, bukan ditempel setelah sistem jadi. ISO/IEC 27001 memperluas keamanan dari level aplikasi ke level sistem manajemen. Di dalamnya terdapat kebijakan, peran, risk assessment, treatment plan, awareness, audit, supplier management, business continuity, dan continual improvement. Dengan demikian keamanan menjadi tanggung jawab organisasi, bukan hanya programmer. Pendalaman Materi Per Unit Bagian ini memperluas materi menjadi unit-unit belajar yang dapat digunakan untuk diskusi kelas, kajian mandiri, atau pengembangan tugas proyek. Setiap unit menghubungkan konsep teknis dengan artefak rekayasa, risiko, metrik, dan keputusan bisnis.
Catatan Kuliah RPL Bisnis | Halaman 72 Unit 4.1. Prinsip Dasar Keamanan Software Bisnis Unit ini membahas prinsip dasar keamanan software bisnis sebagai bagian penting dari topik keamanan perangkat lunak dan compliance bisnis. Sudut pandang utamanya adalah confidentiality, integrity, availability, authentication, authorization, accountability, dan non-repudiation. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah portal pelanggan harus memastikan hanya pemilik akun yang dapat melihat invoice dan riwayat transaksi. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi security requirement, access model, dan control catalog. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah akses terlalu luas menyebabkan data sensitif terlihat oleh pengguna yang tidak berwenang. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 4.2. Telaah pendalaman: prinsip dasar keamanan software bisnis. Dimensi Uraian Analitis Fokus konsep confidentiality, integrity, availability, authentication, authorization, accountability, dan non-repudiation Contoh penerapan portal pelanggan harus memastikan hanya pemilik akun yang dapat melihat invoice dan riwayat transaksi Artefak utama security requirement, access model, dan control catalog
Catatan Kuliah RPL Bisnis | Halaman 73 Risiko penting akses terlalu luas menyebabkan data sensitif terlihat oleh pengguna yang tidak berwenang Metrik evaluasi access violation, audit finding, security incident, dan privilege review completion Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti access violation, audit finding, security incident, dan privilege review completion untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 74 Unit 4.2. Threat, Vulnerability, Risk, Dan Control Unit ini membahas threat, vulnerability, risk, dan control sebagai bagian penting dari topik keamanan perangkat lunak dan compliance bisnis. Sudut pandang utamanya adalah ancaman, kelemahan, kemungkinan, dampak, kontrol pencegahan, deteksi, dan pemulihan. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah API tanpa rate limit berisiko disalahgunakan untuk scraping data pelanggan. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi threat model, risk register, dan control matrix. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah tim langsung membeli tool keamanan tanpa memahami risiko paling kritis. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 4.3. Telaah pendalaman: threat, vulnerability, risk, dan control. Dimensi Uraian Analitis Fokus konsep ancaman, kelemahan, kemungkinan, dampak, kontrol pencegahan, deteksi, dan pemulihan Contoh penerapan API tanpa rate limit berisiko disalahgunakan untuk scraping data pelanggan Artefak utama threat model, risk register, dan control matrix Risiko tim langsung membeli tool keamanan tanpa memahami risiko
Catatan Kuliah RPL Bisnis | Halaman 75 penting paling kritis Metrik evaluasi risk score reduction, control effectiveness, dan incident trend Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti risk score reduction, control effectiveness, dan incident trend untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 76 Unit 4.3. Secure SDLC Unit ini membahas secure sdlc sebagai bagian penting dari topik keamanan perangkat lunak dan compliance bisnis. Sudut pandang utamanya adalah security requirement, secure design, secure coding, security testing, hardening, monitoring, dan incident response. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah fitur login dirancang dengan MFA, lockout policy, password hashing, dan logging yang aman. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi secure SDLC checklist, design review, SAST/DAST report, dan hardening guide. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah keamanan diuji hanya menjelang go- live sehingga biaya perbaikan meningkat. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 4.4. Telaah pendalaman: secure sdlc. Dimensi Uraian Analitis Fokus konsep security requirement, secure design, secure coding, security testing, hardening, monitoring, dan incident response Contoh penerapan fitur login dirancang dengan MFA, lockout policy, password hashing, dan logging yang aman Artefak secure SDLC checklist, design review, SAST/DAST report,
Catatan Kuliah RPL Bisnis | Halaman 77 utama dan hardening guide Risiko penting keamanan diuji hanya menjelang go-live sehingga biaya perbaikan meningkat Metrik evaluasi security defect density, remediation time, dan security gate pass rate Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti security defect density, remediation time, dan security gate pass rate untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 78 Unit 4.4. OWASP Top 10 Dalam Aplikasi Bisnis Unit ini membahas owasp top 10 dalam aplikasi bisnis sebagai bagian penting dari topik keamanan perangkat lunak dan compliance bisnis. Sudut pandang utamanya adalah broken access control, injection, insecure design, misconfiguration, vulnerable components, dan logging failure. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah user biasa dapat mengubah parameter URL untuk membuka invoice pelanggan lain. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi OWASP checklist, penetration test report, dan remediation backlog. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah risiko OWASP dianggap urusan teknis saja, padahal dampaknya bisnis dan hukum. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 4.5. Telaah pendalaman: owasp top 10 dalam aplikasi bisnis. Dimensi Uraian Analitis Fokus konsep broken access control, injection, insecure design, misconfiguration, vulnerable components, dan logging failure Contoh penerapan user biasa dapat mengubah parameter URL untuk membuka invoice pelanggan lain Artefak OWASP checklist, penetration test report, dan remediation
Catatan Kuliah RPL Bisnis | Halaman 79 utama backlog Risiko penting risiko OWASP dianggap urusan teknis saja, padahal dampaknya bisnis dan hukum Metrik evaluasi critical vulnerability count, remediation SLA, dan retest pass rate Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti critical vulnerability count, remediation SLA, dan retest pass rate untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 80 Unit 4.5. GDPR Dan Perlindungan Data Pribadi Unit ini membahas gdpr dan perlindungan data pribadi sebagai bagian penting dari topik keamanan perangkat lunak dan compliance bisnis. Sudut pandang utamanya adalah lawfulness, fairness, transparency, purpose limitation, data minimization, accuracy, storage limitation, integrity, dan confidentiality. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah aplikasi marketing hanya menyimpan data yang diperlukan untuk kampanye yang disetujui pelanggan. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi data inventory, consent record, DPIA, dan retention policy. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah data dikumpulkan berlebihan tanpa tujuan yang jelas dan sulit dihapus saat diminta. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 4.6. Telaah pendalaman: gdpr dan perlindungan data pribadi. Dimensi Uraian Analitis Fokus konsep lawfulness, fairness, transparency, purpose limitation, data minimization, accuracy, storage limitation, integrity, dan confidentiality Contoh penerapan aplikasi marketing hanya menyimpan data yang diperlukan untuk kampanye yang disetujui pelanggan
Catatan Kuliah RPL Bisnis | Halaman 81 Artefak utama data inventory, consent record, DPIA, dan retention policy Risiko penting data dikumpulkan berlebihan tanpa tujuan yang jelas dan sulit dihapus saat diminta Metrik evaluasi privacy request completion, data retention compliance, dan consent validity Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti privacy request completion, data retention compliance, dan consent validity untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 82 Unit 4.6. ISO/IEC 27001 Dan ISMS Unit ini membahas iso/iec 27001 dan isms sebagai bagian penting dari topik keamanan perangkat lunak dan compliance bisnis. Sudut pandang utamanya adalah konteks organisasi, kepemimpinan, risk treatment, support, operation, performance evaluation, dan improvement. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah organisasi menetapkan kebijakan akses, audit berkala, awareness, dan prosedur incident response. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi ISMS scope, risk treatment plan, statement of applicability, dan audit report. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah kontrol keamanan ada di dokumen tetapi tidak dijalankan dalam operasi harian. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 4.7. Telaah pendalaman: iso/iec 27001 dan isms. Dimensi Uraian Analitis Fokus konsep konteks organisasi, kepemimpinan, risk treatment, support, operation, performance evaluation, dan improvement Contoh penerapan organisasi menetapkan kebijakan akses, audit berkala, awareness, dan prosedur incident response Artefak ISMS scope, risk treatment plan, statement of applicability,
Catatan Kuliah RPL Bisnis | Halaman 83 utama dan audit report Risiko penting kontrol keamanan ada di dokumen tetapi tidak dijalankan dalam operasi harian Metrik evaluasi audit nonconformity, control maturity, training completion, dan incident response time Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti audit nonconformity, control maturity, training completion, dan incident response time untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 84 Unit 4.7. Security Operations Dan Compliance Monitoring Unit ini membahas security operations dan compliance monitoring sebagai bagian penting dari topik keamanan perangkat lunak dan compliance bisnis. Sudut pandang utamanya adalah logging, SIEM, alerting, vulnerability management, patching, backup, dan business continuity. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah tim operasi memantau percobaan login gagal, perubahan privilege, dan anomali transaksi. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi runbook SOC, patch calendar, backup test record, dan compliance dashboard. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah log tidak lengkap membuat investigasi insiden lambat dan tidak akurat. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 4.8. Telaah pendalaman: security operations dan compliance monitoring. Dimensi Uraian Analitis Fokus konsep logging, SIEM, alerting, vulnerability management, patching, backup, dan business continuity Contoh penerapan tim operasi memantau percobaan login gagal, perubahan privilege, dan anomali transaksi Artefak runbook SOC, patch calendar, backup test record, dan
Catatan Kuliah RPL Bisnis | Halaman 85 utama compliance dashboard Risiko penting log tidak lengkap membuat investigasi insiden lambat dan tidak akurat Metrik evaluasi mean time to detect, mean time to respond, patch compliance, dan backup success rate Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti mean time to detect, mean time to respond, patch compliance, dan backup success rate untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 86 Visualisasi Konsep Gambar 4. Visualisasi ringkas keamanan perangkat lunak dan compliance bisnis. Pemetaan Materi Tabel 4.1. Pemetaan materi keamanan perangkat lunak dan compliance bisnis. Kerangka Fokus Contoh Penerapan dalam RPL Bisnis OWASP Risiko teknis aplikasi RBAC, input validation, parameterized query, patch dependency. GDPR Pemrosesan dan perlindungan data pribadi Data minimization, consent, retensi data, hak akses dan koreksi. ISO/IEC 27001 ISMS dan tata kelola keamanan informasi Risk treatment, audit, awareness, supplier control, incident response. Secure SDLC Integrasi keamanan dalam proses rekayasa Security requirement, threat modeling, secure coding, SAST/DAST. Implikasi Untuk Bisnis • Keputusan teknis perlu diterjemahkan menjadi dampak pada biaya, risiko, mutu layanan, kepuasan pengguna, dan nilai strategis organisasi.
Catatan Kuliah RPL Bisnis | Halaman 87 • Dokumentasi requirement, desain, testing, risiko, dan perubahan harus diperlakukan sebagai artefak manajerial, bukan administrasi tambahan. • Keberhasilan software bisnis bergantung pada keselarasan antara proses, data, pengguna, teknologi, dan tata kelola. Studi Kasus Dan Refleksi Studi kasus Kasus CRM dan e-commerce dengan API tidak aman menunjukkan hubungan langsung antara kelemahan teknis dan kerugian bisnis. Analisisnya perlu mencakup broken access control, kemungkinan kebocoran data pribadi, kontrol ISO 27001 yang relevan, serta rencana mitigasi teknis dan organisasi. • Apa keputusan desain yang paling menentukan keberhasilan kasus tersebut? • Risiko apa yang harus dimasukkan ke risk register sejak awal? • Metrik apa yang dapat dipakai untuk membuktikan manfaat bisnisnya?
Catatan Kuliah RPL Bisnis | Halaman 88 Bab 5. Monitoring, Controlling, Change Management, Dan Evaluasi Kinerja Proyek Pertemuan 13 Fokus pembelajaran Membedakan monitoring, controlling, dan evaluasi proyek sistem informasi. | Menganalisis deviasi scope, jadwal, biaya, mutu, risiko, dan stakeholder. | Menyusun mekanisme change control dan evaluasi kinerja berbasis data. Elaborasi Konsep Monitoring berarti mengumpulkan data aktual proyek; controlling berarti membandingkan data aktual dengan baseline dan mengambil tindakan korektif. Tanpa baseline scope, jadwal, biaya, dan mutu, proyek sulit dikendalikan karena tidak ada titik pembanding yang disepakati. Change management penting karena proyek sistem informasi hampir selalu menghadapi perubahan kebutuhan, regulasi, prioritas bisnis, atau temuan teknis. Setiap change request perlu dianalisis dampaknya terhadap scope, schedule, cost, quality, risk, dan stakeholder. Evaluasi kinerja proyek tidak hanya menilai apakah proyek selesai, tetapi juga apakah deliverable lengkap, kualitas diterima, pengguna mengadopsi sistem, manfaat bisnis tercapai, dan pelajaran proyek terdokumentasi. Uraian Materi Rinci Baseline Sebagai Alat Kontrol Baseline adalah rencana yang telah disetujui dan dijadikan pembanding pelaksanaan proyek. Scope baseline menjelaskan deliverable dan acceptance criteria; schedule baseline menjelaskan jadwal dan milestone; cost baseline menjelaskan anggaran; quality baseline menjelaskan standar mutu yang harus dicapai. Tanpa baseline, status proyek mudah menjadi opini. Dengan baseline, manajer proyek dapat mengatakan secara objektif apakah proyek on track, at risk, atau off track. Data aktual kemudian dibandingkan dengan baseline untuk menentukan corrective action atau preventive action.
Catatan Kuliah RPL Bisnis | Halaman 89 EVM, Status Report, Dan Dashboard Earned Value Management membantu membaca kesehatan proyek melalui Planned Value, Earned Value, dan Actual Cost. Cost Variance menunjukkan selisih nilai pekerjaan selesai dengan biaya aktual, sedangkan Schedule Variance menunjukkan selisih nilai pekerjaan selesai dengan nilai rencana. CPI dan SPI membantu membaca efisiensi biaya dan jadwal. Status report sebaiknya ringkas tetapi kaya keputusan. Isi pentingnya meliputi status RAG, progres milestone, isu utama, risiko, dependency, perubahan, keputusan yang dibutuhkan, dan rencana periode berikutnya. Dashboard proyek yang baik menampilkan tren, bukan hanya angka terakhir. Integrated Change Control Change request perlu diajukan secara tertulis, dianalisis dampaknya, dibahas oleh pihak berwenang, lalu diputuskan sebagai approved, rejected, atau deferred. Dalam proyek SI, perubahan kecil pada requirement dapat berdampak pada database, integrasi, UI, testing, training, dokumentasi, biaya, dan jadwal. Change Control Board tidak harus besar, tetapi harus mewakili sponsor, project manager, business owner, technical lead, quality/security, dan pihak lain yang terdampak. Keputusan CCB menjaga agar perubahan tidak menjadi scope creep yang merusak manfaat dan disiplin proyek. Pendalaman Materi Per Unit Bagian ini memperluas materi menjadi unit-unit belajar yang dapat digunakan untuk diskusi kelas, kajian mandiri, atau pengembangan tugas proyek. Setiap unit menghubungkan konsep teknis dengan artefak rekayasa, risiko, metrik, dan keputusan bisnis.
Catatan Kuliah RPL Bisnis | Halaman 90 Unit 5.1. Monitoring Sebagai Pengumpulan Fakta Proyek Unit ini membahas monitoring sebagai pengumpulan fakta proyek sebagai bagian penting dari topik monitoring, controlling, change management, dan evaluasi kinerja proyek. Sudut pandang utamanya adalah status pekerjaan, deliverable, jadwal, biaya, risiko, isu, dependency, dan kualitas. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah project manager mengumpulkan status sprint, defect, burn rate, dan kesiapan UAT setiap minggu. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi status log, progress report, issue log, dan dashboard RAG. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah laporan proyek hanya berisi aktivitas, bukan fakta keputusan dan deviasi. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 5.2. Telaah pendalaman: monitoring sebagai pengumpulan fakta proyek. Dimensi Uraian Analitis Fokus konsep status pekerjaan, deliverable, jadwal, biaya, risiko, isu, dependency, dan kualitas Contoh penerapan project manager mengumpulkan status sprint, defect, burn rate, dan kesiapan UAT setiap minggu Artefak status log, progress report, issue log, dan dashboard RAG
Catatan Kuliah RPL Bisnis | Halaman 91 utama Risiko penting laporan proyek hanya berisi aktivitas, bukan fakta keputusan dan deviasi Metrik evaluasi report timeliness, data completeness, RAG accuracy, dan issue aging Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti report timeliness, data completeness, RAG accuracy, dan issue aging untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 92 Unit 5.2. Controlling Terhadap Baseline Unit ini membahas controlling terhadap baseline sebagai bagian penting dari topik monitoring, controlling, change management, dan evaluasi kinerja proyek. Sudut pandang utamanya adalah perbandingan aktual dengan scope, schedule, cost, quality, dan risk baseline. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah keterlambatan modul migrasi data dibandingkan dengan jadwal baseline memicu corrective action. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi baseline document, variance report, dan corrective action plan. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah baseline sering diubah tanpa mekanisme persetujuan sehingga kontrol kehilangan makna. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 5.3. Telaah pendalaman: controlling terhadap baseline. Dimensi Uraian Analitis Fokus konsep perbandingan aktual dengan scope, schedule, cost, quality, dan risk baseline Contoh penerapan keterlambatan modul migrasi data dibandingkan dengan jadwal baseline memicu corrective action Artefak baseline document, variance report, dan corrective action plan
Catatan Kuliah RPL Bisnis | Halaman 93 utama Risiko penting baseline sering diubah tanpa mekanisme persetujuan sehingga kontrol kehilangan makna Metrik evaluasi schedule variance, cost variance, scope change count, dan quality variance Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti schedule variance, cost variance, scope change count, dan quality variance untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 94 Unit 5.3. Earned Value Management Unit ini membahas earned value management sebagai bagian penting dari topik monitoring, controlling, change management, dan evaluasi kinerja proyek. Sudut pandang utamanya adalah planned value, earned value, actual cost, cost variance, schedule variance, CPI, dan SPI. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah proyek bernilai Rp500 juta dievaluasi dari pekerjaan yang benar-benar selesai, bukan dari biaya yang sudah keluar. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi EVM worksheet, milestone value map, dan performance trend chart. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah tim salah menganggap pekerjaan hampir selesai padahal deliverable belum diterima. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 5.4. Telaah pendalaman: earned value management. Dimensi Uraian Analitis Fokus konsep planned value, earned value, actual cost, cost variance, schedule variance, CPI, dan SPI Contoh penerapan proyek bernilai Rp500 juta dievaluasi dari pekerjaan yang benar-benar selesai, bukan dari biaya yang sudah keluar Artefak EVM worksheet, milestone value map, dan performance trend
Catatan Kuliah RPL Bisnis | Halaman 95 utama chart Risiko penting tim salah menganggap pekerjaan hampir selesai padahal deliverable belum diterima Metrik evaluasi CPI, SPI, CV, SV, dan estimate at completion Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti CPI, SPI, CV, SV, dan estimate at completion untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 96 Unit 5.4. Issue Management Dan Eskalasi Unit ini membahas issue management dan eskalasi sebagai bagian penting dari topik monitoring, controlling, change management, dan evaluasi kinerja proyek. Sudut pandang utamanya adalah identifikasi isu, owner, prioritas, akar masalah, target selesai, eskalasi, dan bukti penutupan. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah isu data mahasiswa lama error tinggi ditangani dengan root cause analysis dan validasi sampling. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi issue register, RCA note, action item log, dan closure evidence. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah isu dibiarkan menjadi risiko besar karena tidak ada owner yang jelas. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 5.5. Telaah pendalaman: issue management dan eskalasi. Dimensi Uraian Analitis Fokus konsep identifikasi isu, owner, prioritas, akar masalah, target selesai, eskalasi, dan bukti penutupan Contoh penerapan isu data mahasiswa lama error tinggi ditangani dengan root cause analysis dan validasi sampling Artefak issue register, RCA note, action item log, dan closure evidence
Catatan Kuliah RPL Bisnis | Halaman 97 utama Risiko penting isu dibiarkan menjadi risiko besar karena tidak ada owner yang jelas Metrik evaluasi issue aging, overdue issue, escalation count, dan closure quality Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti issue aging, overdue issue, escalation count, dan closure quality untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 98 Unit 5.5. Integrated Change Control Unit ini membahas integrated change control sebagai bagian penting dari topik monitoring, controlling, change management, dan evaluasi kinerja proyek. Sudut pandang utamanya adalah submit, assess, review, approve/reject/defer, implement, communicate, dan update baseline. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah permintaan laporan tambahan sebelum go-live dianalisis terhadap jadwal, biaya, testing, dan manfaat. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi change request form, impact analysis, CCB decision, dan change log. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah semua permintaan user diterima tanpa prioritas sehingga scope creep terjadi. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 5.6. Telaah pendalaman: integrated change control. Dimensi Uraian Analitis Fokus konsep submit, assess, review, approve/reject/defer, implement, communicate, dan update baseline Contoh penerapan permintaan laporan tambahan sebelum go-live dianalisis terhadap jadwal, biaya, testing, dan manfaat Artefak change request form, impact analysis, CCB decision, dan
Catatan Kuliah RPL Bisnis | Halaman 99 utama change log Risiko penting semua permintaan user diterima tanpa prioritas sehingga scope creep terjadi Metrik evaluasi change approval rate, cycle time change, scope growth, dan rework effort Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti change approval rate, cycle time change, scope growth, dan rework effort untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 100 Unit 5.6. Project Performance Review Unit ini membahas project performance review sebagai bagian penting dari topik monitoring, controlling, change management, dan evaluasi kinerja proyek. Sudut pandang utamanya adalah evaluasi proses, output, outcome, stakeholder, risiko, dan lesson learned. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah setelah go-live ERP, tim mengevaluasi deliverable, defect, adopsi pengguna, dan manfaat proses. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi performance review report, benefit realization review, dan lessons learned. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah review dilakukan hanya sebagai formalitas tanpa tindak lanjut. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 5.7. Telaah pendalaman: project performance review. Dimensi Uraian Analitis Fokus konsep evaluasi proses, output, outcome, stakeholder, risiko, dan lesson learned Contoh penerapan setelah go-live ERP, tim mengevaluasi deliverable, defect, adopsi pengguna, dan manfaat proses Artefak performance review report, benefit realization review, dan
Catatan Kuliah RPL Bisnis | Halaman 101 utama lessons learned Risiko penting review dilakukan hanya sebagai formalitas tanpa tindak lanjut Metrik evaluasi benefit realization, stakeholder satisfaction, defect leakage, dan action closure Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti benefit realization, stakeholder satisfaction, defect leakage, dan action closure untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 102 Unit 5.7. Dashboard Kontrol Proyek SI Unit ini membahas dashboard kontrol proyek si sebagai bagian penting dari topik monitoring, controlling, change management, dan evaluasi kinerja proyek. Sudut pandang utamanya adalah indikator tren, status RAG, keputusan yang dibutuhkan, risiko utama, dan dependency kritis. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah dashboard menampilkan progres, budget utilization, defect critical, change request, dan kesiapan training. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi dashboard specification, KPI dictionary, dan governance cadence. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah dashboard terlalu ramai sehingga tidak membantu prioritas manajemen. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 5.8. Telaah pendalaman: dashboard kontrol proyek si. Dimensi Uraian Analitis Fokus konsep indikator tren, status RAG, keputusan yang dibutuhkan, risiko utama, dan dependency kritis Contoh penerapan dashboard menampilkan progres, budget utilization, defect critical, change request, dan kesiapan training Artefak dashboard specification, KPI dictionary, dan governance
Catatan Kuliah RPL Bisnis | Halaman 103 utama cadence Risiko penting dashboard terlalu ramai sehingga tidak membantu prioritas manajemen Metrik evaluasi dashboard usage, decision lead time, KPI freshness, dan executive action rate Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti dashboard usage, decision lead time, KPI freshness, dan executive action rate untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 104 Visualisasi Konsep Gambar 5. Visualisasi ringkas monitoring, controlling, change management, dan evaluasi kinerja proyek. Pemetaan Materi Tabel 5.1. Pemetaan materi monitoring, controlling, change management, dan evaluasi kinerja proyek. Area Kontrol Contoh KPI Tindakan jika Deviasi Schedule Milestone, lead time, delay Replan sprint, eskalasi dependency, tambah kapasitas selektif. Cost Budget variance, burn rate Review scope, negosiasi vendor, prioritisasi fitur. Quality Defect density, acceptance rate Regression testing, root cause analysis, perbaikan test case. Risk/Issue Jumlah risiko high, umur isu Mitigasi aktif, owner jelas, eskalasi CCB. Benefit Adopsi pengguna, efisiensi proses Training tambahan, redesign proses, komunikasi perubahan.
Catatan Kuliah RPL Bisnis | Halaman 105 Implikasi Untuk Bisnis • Keputusan teknis perlu diterjemahkan menjadi dampak pada biaya, risiko, mutu layanan, kepuasan pengguna, dan nilai strategis organisasi. • Dokumentasi requirement, desain, testing, risiko, dan perubahan harus diperlakukan sebagai artefak manajerial, bukan administrasi tambahan. • Keberhasilan software bisnis bergantung pada keselarasan antara proses, data, pengguna, teknologi, dan tata kelola. Studi Kasus Dan Refleksi Studi kasus Jika UAT terlambat dua minggu karena perubahan requirement, project manager harus memisahkan defect dari enhancement, membuat change request, menilai dampak jadwal dan biaya, meminta keputusan CCB, lalu memperbarui baseline hanya bila perubahan disetujui. • Apa keputusan desain yang paling menentukan keberhasilan kasus tersebut? • Risiko apa yang harus dimasukkan ke risk register sejak awal? • Metrik apa yang dapat dipakai untuk membuktikan manfaat bisnisnya?
Catatan Kuliah RPL Bisnis | Halaman 106 Bab 6. AI/ML Dan Generative AI Untuk Solusi Bisnis Pertemuan 14 Fokus pembelajaran Membedakan AI, ML, Deep Learning, dan Generative AI dalam konteks RPL Bisnis. | Menganalisis kapan masalah bisnis layak diselesaikan dengan AI. | Merancang alur solusi AI dari data, model, aplikasi, evaluasi, sampai deployment. Elaborasi Konsep AI adalah payung besar sistem cerdas; ML adalah pendekatan yang membuat model belajar dari data; Deep Learning menggunakan jaringan saraf kompleks; Generative AI menghasilkan konten baru seperti teks, kode, ringkasan, atau dialog. Dalam RPL Bisnis, AI bukan tujuan akhir, melainkan komponen solusi software yang harus bernilai, aman, dan dapat diaudit. Masalah bisnis cocok untuk AI ketika tersedia data yang cukup, terdapat pola berulang, nilai bisnisnya jelas, output dapat diukur, dan risikonya dapat dikendalikan. Jika kriteria ini tidak terpenuhi, otomasi biasa atau analitik sederhana mungkin lebih tepat. Solusi GenAI modern sering menggunakan arsitektur UI, prompt layer, LLM, RAG, guardrail, dan human-in-the-loop. RAG membantu menghubungkan model dengan dokumen organisasi, sedangkan guardrail dan review manusia mengurangi risiko halusinasi, kebocoran data, dan keputusan keliru. Uraian Materi Rinci Memilih Masalah Yang Tepat Untuk AI Tidak semua masalah bisnis membutuhkan AI. AI cocok ketika ada data yang cukup, pola historis yang dapat dipelajari, nilai bisnis yang jelas, metrik evaluasi yang terukur, dan risiko yang dapat dikendalikan. Jika proses hanya membutuhkan aturan sederhana, workflow automation biasa sering lebih murah dan lebih mudah diaudit. Analisis awal perlu mencakup tujuan bisnis, stakeholder, proses yang terdampak, sumber data, kualitas data, constraint regulasi, dan definisi sukses. Tanpa definisi sukses, proyek AI dapat terlihat canggih tetapi gagal memberi outcome nyata.
Catatan Kuliah RPL Bisnis | Halaman 107 Data, Model, Dan Aplikasi Data adalah fondasi solusi AI. Sumbernya dapat berasal dari ERP, CRM, transaksi, log aplikasi, dokumen, survei, atau data eksternal. Kualitas data mencakup kelengkapan, akurasi, konsistensi, representativitas, label, dan bias. Data governance mengatur akses, retensi, keamanan, dan kepatuhan. Pemilihan model mengikuti jenis masalah: klasifikasi untuk kategori, regresi untuk nilai numerik, clustering untuk segmentasi, rekomendasi untuk preferensi, dan generative AI untuk produksi teks, kode, ringkasan, atau dialog. Model harus dihubungkan ke aplikasi melalui API, UI, workflow, dan kontrol operasional. GenAI, RAG, Guardrail, Dan Operasi Pada aplikasi GenAI, prompt engineering membantu menentukan peran, konteks, format keluaran, contoh, dan mekanisme verifikasi. RAG menghubungkan LLM dengan sumber pengetahuan organisasi sehingga jawaban lebih relevan dan dapat ditelusuri ke dokumen. Risiko GenAI mencakup hallucination, bias, kebocoran data, prompt injection, output tidak pantas, dan ketergantungan berlebihan. Karena itu diperlukan guardrail, human-in-the-loop, logging, evaluasi groundedness, serta LLMOps untuk memantau biaya, latency, kualitas, drift, dan perubahan prompt/model. Pendalaman Materi Per Unit Bagian ini memperluas materi menjadi unit-unit belajar yang dapat digunakan untuk diskusi kelas, kajian mandiri, atau pengembangan tugas proyek. Setiap unit menghubungkan konsep teknis dengan artefak rekayasa, risiko, metrik, dan keputusan bisnis.
Catatan Kuliah RPL Bisnis | Halaman 108 Unit 6.1. Business Understanding Untuk Solusi AI Unit ini membahas business understanding untuk solusi ai sebagai bagian penting dari topik ai/ml dan generative ai untuk solusi bisnis. Sudut pandang utamanya adalah masalah bisnis, nilai, stakeholder, proses, metrik, risiko, dan batasan keputusan. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah organisasi ingin menurunkan churn pelanggan dengan model prediksi dan intervensi layanan. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi AI opportunity canvas, stakeholder map, dan success metric definition. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah AI dipilih karena tren, bukan karena masalah memiliki data dan pola yang layak dipelajari. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 6.2. Telaah pendalaman: business understanding untuk solusi ai. Dimensi Uraian Analitis Fokus konsep masalah bisnis, nilai, stakeholder, proses, metrik, risiko, dan batasan keputusan Contoh penerapan organisasi ingin menurunkan churn pelanggan dengan model prediksi dan intervensi layanan Artefak AI opportunity canvas, stakeholder map, dan success metric
Catatan Kuliah RPL Bisnis | Halaman 109 utama definition Risiko penting AI dipilih karena tren, bukan karena masalah memiliki data dan pola yang layak dipelajari Metrik evaluasi business impact, conversion uplift, churn reduction, dan model adoption Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti business impact, conversion uplift, churn reduction, dan model adoption untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 110 Unit 6.2. Data Understanding Dan Data Readiness Unit ini membahas data understanding dan data readiness sebagai bagian penting dari topik ai/ml dan generative ai untuk solusi bisnis. Sudut pandang utamanya adalah sumber data, kualitas, label, bias, representativitas, privasi, dan akses. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah data CRM, transaksi, dan tiket layanan digabung untuk memprediksi pelanggan berisiko churn. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi data inventory, data quality report, data lineage, dan privacy assessment. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah data historis bias membuat model memperkuat keputusan yang tidak adil. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 6.3. Telaah pendalaman: data understanding dan data readiness. Dimensi Uraian Analitis Fokus konsep sumber data, kualitas, label, bias, representativitas, privasi, dan akses Contoh penerapan data CRM, transaksi, dan tiket layanan digabung untuk memprediksi pelanggan berisiko churn Artefak data inventory, data quality report, data lineage, dan privacy
Catatan Kuliah RPL Bisnis | Halaman 111 utama assessment Risiko penting data historis bias membuat model memperkuat keputusan yang tidak adil Metrik evaluasi missing value rate, label quality, data freshness, dan bias indicator Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti missing value rate, label quality, data freshness, dan bias indicator untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 112 Unit 6.3. Pemilihan Model AI/ML Unit ini membahas pemilihan model ai/ml sebagai bagian penting dari topik ai/ml dan generative ai untuk solusi bisnis. Sudut pandang utamanya adalah klasifikasi, regresi, clustering, rekomendasi, forecasting, NLP, dan GenAI. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah fraud detection memakai klasifikasi, prediksi penjualan memakai regresi, dan chatbot memakai LLM dengan RAG. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi model selection rationale, experiment log, dan evaluation report. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah model kompleks dipilih tanpa kebutuhan sehingga sulit dijelaskan dan dipelihara. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 6.4. Telaah pendalaman: pemilihan model ai/ml. Dimensi Uraian Analitis Fokus konsep klasifikasi, regresi, clustering, rekomendasi, forecasting, NLP, dan GenAI Contoh penerapan fraud detection memakai klasifikasi, prediksi penjualan memakai regresi, dan chatbot memakai LLM dengan RAG Artefak model selection rationale, experiment log, dan evaluation
Catatan Kuliah RPL Bisnis | Halaman 113 utama report Risiko penting model kompleks dipilih tanpa kebutuhan sehingga sulit dijelaskan dan dipelihara Metrik evaluasi accuracy, precision, recall, F1, RMSE, MAPE, dan relevance score Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti accuracy, precision, recall, F1, RMSE, MAPE, dan relevance score untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 114 Unit 6.4. Generative AI Dan Arsitektur RAG Unit ini membahas generative ai dan arsitektur rag sebagai bagian penting dari topik ai/ml dan generative ai untuk solusi bisnis. Sudut pandang utamanya adalah user interface, prompt layer, retrieval, knowledge base, LLM, guardrail, dan logging. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah chatbot kebijakan akademik mengambil jawaban dari dokumen resmi, menampilkan sumber, dan menolak jika bukti tidak cukup. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi prompt template, knowledge base index, retrieval evaluation, dan safety policy. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah model berhalusinasi atau mengambil sumber tidak sahih ketika konteks tidak dikendalikan. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 6.5. Telaah pendalaman: generative ai dan arsitektur rag. Dimensi Uraian Analitis Fokus konsep user interface, prompt layer, retrieval, knowledge base, LLM, guardrail, dan logging Contoh penerapan chatbot kebijakan akademik mengambil jawaban dari dokumen resmi, menampilkan sumber, dan menolak jika bukti tidak cukup
Catatan Kuliah RPL Bisnis | Halaman 115 Artefak utama prompt template, knowledge base index, retrieval evaluation, dan safety policy Risiko penting model berhalusinasi atau mengambil sumber tidak sahih ketika konteks tidak dikendalikan Metrik evaluasi groundedness, answer relevance, citation coverage, dan refusal accuracy Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti groundedness, answer relevance, citation coverage, dan refusal accuracy untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 116 Unit 6.5. Prompt Engineering Untuk Produktivitas Bisnis Unit ini membahas prompt engineering untuk produktivitas bisnis sebagai bagian penting dari topik ai/ml dan generative ai untuk solusi bisnis. Sudut pandang utamanya adalah role, context, task, output format, example, constraint, dan verification instruction. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah analis bisnis meminta AI menyusun user story, acceptance criteria, dan test scenario dari transkrip wawancara. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi prompt library, output rubric, dan review checklist. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah prompt terlalu umum menghasilkan output dangkal, tidak konsisten, dan sulit diverifikasi. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 6.6. Telaah pendalaman: prompt engineering untuk produktivitas bisnis. Dimensi Uraian Analitis Fokus konsep role, context, task, output format, example, constraint, dan verification instruction Contoh penerapan analis bisnis meminta AI menyusun user story, acceptance criteria, dan test scenario dari transkrip wawancara Artefak utama prompt library, output rubric, dan review checklist
Catatan Kuliah RPL Bisnis | Halaman 117 Risiko penting prompt terlalu umum menghasilkan output dangkal, tidak konsisten, dan sulit diverifikasi Metrik evaluasi output acceptance rate, revision count, consistency score, dan reviewer effort Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti output acceptance rate, revision count, consistency score, dan reviewer effort untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 118 Unit 6.6. Human-in-the-loop Dan Pengalaman Pengguna Unit ini membahas human-in-the-loop dan pengalaman pengguna sebagai bagian penting dari topik ai/ml dan generative ai untuk solusi bisnis. Sudut pandang utamanya adalah confidence, explanation, feedback, override, fallback, audit trail, dan kontrol keputusan. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah AI memberi rekomendasi kredit, tetapi analis manusia mengambil keputusan akhir berdasarkan kebijakan risiko. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi UX flow, review queue, feedback schema, dan audit log. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah pengguna terlalu percaya pada output AI tanpa memahami ketidakpastian model. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 6.7. Telaah pendalaman: human-in-the-loop dan pengalaman pengguna. Dimensi Uraian Analitis Fokus konsep confidence, explanation, feedback, override, fallback, audit trail, dan kontrol keputusan Contoh penerapan AI memberi rekomendasi kredit, tetapi analis manusia mengambil keputusan akhir berdasarkan kebijakan risiko Artefak utama UX flow, review queue, feedback schema, dan audit log
Catatan Kuliah RPL Bisnis | Halaman 119 Risiko penting pengguna terlalu percaya pada output AI tanpa memahami ketidakpastian model Metrik evaluasi override rate, feedback rate, decision accuracy, dan trust score Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti override rate, feedback rate, decision accuracy, dan trust score untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 120 Unit 6.7. MLOps Dan LLMOps Unit ini membahas mlops dan llmops sebagai bagian penting dari topik ai/ml dan generative ai untuk solusi bisnis. Sudut pandang utamanya adalah versioning data, model, prompt, pipeline, registry, monitoring, drift, biaya, dan retraining. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah model rekomendasi dipantau setelah deployment untuk melihat penurunan akurasi dan perubahan perilaku pelanggan. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi model registry, pipeline log, monitoring dashboard, dan retraining policy. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah model dibiarkan berjalan tanpa monitoring sehingga performanya menurun diam-diam. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 6.8. Telaah pendalaman: mlops dan llmops. Dimensi Uraian Analitis Fokus konsep versioning data, model, prompt, pipeline, registry, monitoring, drift, biaya, dan retraining Contoh penerapan model rekomendasi dipantau setelah deployment untuk melihat penurunan akurasi dan perubahan perilaku pelanggan Artefak model registry, pipeline log, monitoring dashboard, dan
Catatan Kuliah RPL Bisnis | Halaman 121 utama retraining policy Risiko penting model dibiarkan berjalan tanpa monitoring sehingga performanya menurun diam-diam Metrik evaluasi drift score, latency, token cost, error rate, dan retraining frequency Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti drift score, latency, token cost, error rate, dan retraining frequency untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 122 Visualisasi Konsep Gambar 6. Visualisasi ringkas ai/ml dan generative ai untuk solusi bisnis. Pemetaan Materi Tabel 6.1. Pemetaan materi ai/ml dan generative ai untuk solusi bisnis. Tipe Model Contoh Use Case Metrik Evaluasi Klasifikasi Churn pelanggan, fraud detection, approval kredit Accuracy, precision, recall, F1. Regresi Prediksi penjualan, forecasting, estimasi biaya RMSE, MAE, MAPE. Clustering Segmentasi pelanggan atau produk Silhouette score, interpretabilitas segmen. Rekomendasi Produk, konten, layanan Click-through rate, conversion, relevance. Generative AI Chatbot, ringkasan, draft dokumen, test case Groundedness, relevance, safety, consistency. Implikasi Untuk Bisnis • Keputusan teknis perlu diterjemahkan menjadi dampak pada biaya, risiko, mutu layanan, kepuasan pengguna, dan nilai strategis organisasi.
Catatan Kuliah RPL Bisnis | Halaman 123 • Dokumentasi requirement, desain, testing, risiko, dan perubahan harus diperlakukan sebagai artefak manajerial, bukan administrasi tambahan. • Keberhasilan software bisnis bergantung pada keselarasan antara proses, data, pengguna, teknologi, dan tata kelola. Studi Kasus Dan Refleksi Studi kasus Untuk layanan akademik, chatbot GenAI dapat menjawab pertanyaan mahasiswa dengan RAG dari dokumen resmi. Sistem harus menampilkan sumber, memiliki fallback saat tidak yakin, mencatat feedback, dan mencegah model memberi jawaban yang tidak berdasar. • Apa keputusan desain yang paling menentukan keberhasilan kasus tersebut? • Risiko apa yang harus dimasukkan ke risk register sejak awal? • Metrik apa yang dapat dipakai untuk membuktikan manfaat bisnisnya?
Catatan Kuliah RPL Bisnis | Halaman 124 Bab 7. Transformasi Digital Dan IT Governance Pertemuan 15 Fokus pembelajaran Menjelaskan transformasi digital sebagai perubahan strategis berbasis software dan data. | Membedakan peran COBIT dan ITIL dalam organisasi. | Memetakan proses bisnis, layanan TI, risiko, kontrol, dan KPI governance. Elaborasi Konsep Transformasi digital bukan sekadar membeli aplikasi baru. Ia adalah perubahan strategis pada proses, data, layanan, struktur kerja, dan cara organisasi menghasilkan nilai. Software bisnis menjadi tulang punggung transformasi karena menghubungkan proses, data, aplikasi, dan teknologi. IT governance penting karena investasi TI harus selaras dengan strategi bisnis, risiko harus dikendalikan, sumber daya harus dioptimalkan, dan nilai harus terukur. Tanpa governance, proyek digital dapat berjalan ramai secara aktivitas tetapi lemah secara outcome. COBIT menjawab apakah TI sudah dikendalikan dan selaras dengan tujuan organisasi. ITIL menjawab bagaimana layanan TI disampaikan dengan baik kepada pengguna. Dalam RPL Bisnis, keduanya melengkapi praktik rekayasa agar aplikasi enterprise aman, andal, terukur, dan berkelanjutan. Uraian Materi Rinci Transformasi Digital Sebagai Perubahan Organisasi Transformasi digital tidak identik dengan digitalisasi dokumen atau pembelian aplikasi. Transformasi digital mengubah cara organisasi menciptakan nilai melalui integrasi proses, data, aplikasi, teknologi, manusia, dan model bisnis. Software menjadi penggerak utama karena hampir semua proses digital diwujudkan dalam sistem informasi. Dalam RPL Bisnis, transformasi digital harus diterjemahkan menjadi arsitektur enterprise, roadmap aplikasi, kontrol risiko, standar layanan, metrik outcome, dan mekanisme continual improvement. Tanpa itu, transformasi digital mudah menjadi kumpulan proyek terpisah yang tidak saling menguatkan.
Catatan Kuliah RPL Bisnis | Halaman 125 COBIT Dan ITIL Sebagai Pasangan Governance-service COBIT menekankan tata kelola dan manajemen enterprise IT. Domain EDM, APO, BAI, DSS, dan MEA membantu organisasi menghubungkan strategi, perencanaan, pembangunan, layanan, dukungan, monitoring, evaluasi, dan audit. COBIT cocok untuk memastikan TI selaras dengan tujuan bisnis dan risiko terkendali. ITIL menekankan manajemen layanan TI. Fokusnya adalah value, service value system, incident management, problem management, change enablement, service request, dan continual improvement. ITIL membantu memastikan aplikasi yang sudah dibangun dapat menjadi layanan yang stabil, responsif, dan bernilai bagi pengguna. Roadmap, Risiko, Dan KPI Roadmap transformasi digital dapat dimulai dari assess, align, design, implement, dan govern. Tahap assess menilai kematangan proses, aplikasi, data, dan risiko. Tahap align menyelaraskan tujuan bisnis dan TI. Tahap design merancang arsitektur, layanan, kontrol, dan metrik. Tahap implement menjalankan proyek bertahap. Tahap govern memonitor manfaat, risiko, compliance, dan kinerja. KPI governance dapat mencakup persentase proyek digital yang selaras strategi, availability layanan, response time, jumlah incident, waktu penyelesaian incident, tingkat kepatuhan security, realisasi manfaat bisnis, kepuasan pengguna, dan capability proses. KPI harus dipakai untuk pembelajaran, bukan sekadar pelaporan. Pendalaman Materi Per Unit Bagian ini memperluas materi menjadi unit-unit belajar yang dapat digunakan untuk diskusi kelas, kajian mandiri, atau pengembangan tugas proyek. Setiap unit menghubungkan konsep teknis dengan artefak rekayasa, risiko, metrik, dan keputusan bisnis.
Catatan Kuliah RPL Bisnis | Halaman 126 Unit 7.1. Transformasi Digital Dan Value Bisnis Unit ini membahas transformasi digital dan value bisnis sebagai bagian penting dari topik transformasi digital dan it governance. Sudut pandang utamanya adalah strategi, proses, data, aplikasi, teknologi, manusia, dan outcome organisasi. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah universitas mengintegrasikan layanan akademik digital agar proses pendaftaran, pembayaran, KRS, dan layanan mahasiswa lebih cepat. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi digital transformation roadmap, value map, dan operating model. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah digitalisasi hanya memindahkan formulir manual ke aplikasi tanpa memperbaiki proses. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 7.2. Telaah pendalaman: transformasi digital dan value bisnis. Dimensi Uraian Analitis Fokus konsep strategi, proses, data, aplikasi, teknologi, manusia, dan outcome organisasi Contoh penerapan universitas mengintegrasikan layanan akademik digital agar proses pendaftaran, pembayaran, KRS, dan layanan mahasiswa lebih cepat
Catatan Kuliah RPL Bisnis | Halaman 127 Artefak utama digital transformation roadmap, value map, dan operating model Risiko penting digitalisasi hanya memindahkan formulir manual ke aplikasi tanpa memperbaiki proses Metrik evaluasi process cycle time, adoption, service satisfaction, dan value realization Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti process cycle time, adoption, service satisfaction, dan value realization untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 128 Unit 7.2. Arsitektur Enterprise Dalam RPL Bisnis Unit ini membahas arsitektur enterprise dalam rpl bisnis sebagai bagian penting dari topik transformasi digital dan it governance. Sudut pandang utamanya adalah proses bisnis, data, aplikasi, teknologi, keamanan, integrasi, dan governance. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah arsitektur memetakan ERP, CRM, data warehouse, aplikasi mobile, dan API gateway dalam satu peta enterprise. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi enterprise architecture map, application portfolio, dan integration landscape. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah aplikasi tumbuh terpisah sehingga biaya integrasi dan pemeliharaan meningkat. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 7.3. Telaah pendalaman: arsitektur enterprise dalam rpl bisnis. Dimensi Uraian Analitis Fokus konsep proses bisnis, data, aplikasi, teknologi, keamanan, integrasi, dan governance Contoh penerapan arsitektur memetakan ERP, CRM, data warehouse, aplikasi mobile, dan API gateway dalam satu peta enterprise Artefak enterprise architecture map, application portfolio, dan
Catatan Kuliah RPL Bisnis | Halaman 129 utama integration landscape Risiko penting aplikasi tumbuh terpisah sehingga biaya integrasi dan pemeliharaan meningkat Metrik evaluasi application redundancy, integration reuse, data consistency, dan architecture compliance Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti application redundancy, integration reuse, data consistency, dan architecture compliance untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 130 Unit 7.3. COBIT 2019 Untuk Governance Unit ini membahas cobit 2019 untuk governance sebagai bagian penting dari topik transformasi digital dan it governance. Sudut pandang utamanya adalah EDM, APO, BAI, DSS, MEA, governance objectives, management objectives, capability, dan performance. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah COBIT dipakai untuk menilai apakah proyek digital selaras dengan tujuan bisnis dan risiko terkendali. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi COBIT goals cascade, capability assessment, dan governance action plan. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah framework dipakai sebagai checklist administratif tanpa keputusan governance nyata. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 7.4. Telaah pendalaman: cobit 2019 untuk governance. Dimensi Uraian Analitis Fokus konsep EDM, APO, BAI, DSS, MEA, governance objectives, management objectives, capability, dan performance Contoh penerapan COBIT dipakai untuk menilai apakah proyek digital selaras dengan tujuan bisnis dan risiko terkendali Artefak COBIT goals cascade, capability assessment, dan governance
Catatan Kuliah RPL Bisnis | Halaman 131 utama action plan Risiko penting framework dipakai sebagai checklist administratif tanpa keputusan governance nyata Metrik evaluasi capability level, control effectiveness, strategic alignment, dan risk exposure Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti capability level, control effectiveness, strategic alignment, dan risk exposure untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 132 Unit 7.4. ITIL 4 Untuk Service Management Unit ini membahas itil 4 untuk service management sebagai bagian penting dari topik transformasi digital dan it governance. Sudut pandang utamanya adalah service value system, guiding principles, service value chain, incident, problem, change, request, dan improvement. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah layanan CRM ditangani dengan proses incident, service request, change enablement, dan continual improvement. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi service catalog, SLA, incident procedure, dan improvement register. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah aplikasi berhasil dibangun tetapi layanan operasionalnya tidak stabil. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 7.5. Telaah pendalaman: itil 4 untuk service management. Dimensi Uraian Analitis Fokus konsep service value system, guiding principles, service value chain, incident, problem, change, request, dan improvement Contoh penerapan layanan CRM ditangani dengan proses incident, service request, change enablement, dan continual improvement Artefak service catalog, SLA, incident procedure, dan improvement
Catatan Kuliah RPL Bisnis | Halaman 133 utama register Risiko penting aplikasi berhasil dibangun tetapi layanan operasionalnya tidak stabil Metrik evaluasi availability, incident resolution time, request fulfillment time, dan SLA compliance Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti availability, incident resolution time, request fulfillment time, dan SLA compliance untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 134 Unit 7.5. Integrasi COBIT, ITIL, Dan RPL Unit ini membahas integrasi cobit, itil, dan rpl sebagai bagian penting dari topik transformasi digital dan it governance. Sudut pandang utamanya adalah governance menentukan arah dan kontrol, ITIL mengelola layanan, RPL membangun solusi software. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah implementasi ERP/CRM memakai COBIT untuk tujuan dan kontrol, ITIL untuk layanan, dan RPL untuk desain serta testing. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi governance-service-engineering matrix dan operating cadence. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah tim governance, layanan, dan pengembangan bekerja dalam silo. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 7.6. Telaah pendalaman: integrasi cobit, itil, dan rpl. Dimensi Uraian Analitis Fokus konsep governance menentukan arah dan kontrol, ITIL mengelola layanan, RPL membangun solusi software Contoh penerapan implementasi ERP/CRM memakai COBIT untuk tujuan dan kontrol, ITIL untuk layanan, dan RPL untuk desain serta testing
Catatan Kuliah RPL Bisnis | Halaman 135 Artefak utama governance-service-engineering matrix dan operating cadence Risiko penting tim governance, layanan, dan pengembangan bekerja dalam silo Metrik evaluasi decision cycle time, cross-team issue resolution, compliance rate, dan release success Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti decision cycle time, cross-team issue resolution, compliance rate, dan release success untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 136 Unit 7.6. Risiko Transformasi Digital Unit ini membahas risiko transformasi digital sebagai bagian penting dari topik transformasi digital dan it governance. Sudut pandang utamanya adalah cybersecurity, compliance, vendor lock-in, shadow IT, kegagalan layanan, resistensi pengguna, dan perubahan proses. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah penggunaan aplikasi SaaS tanpa kontrol pusat menimbulkan shadow IT dan risiko kebocoran data. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi digital risk register, vendor assessment, dan compliance checklist. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah risiko non-teknis seperti budaya dan adopsi diabaikan. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 7.7. Telaah pendalaman: risiko transformasi digital. Dimensi Uraian Analitis Fokus konsep cybersecurity, compliance, vendor lock-in, shadow IT, kegagalan layanan, resistensi pengguna, dan perubahan proses Contoh penerapan penggunaan aplikasi SaaS tanpa kontrol pusat menimbulkan shadow IT dan risiko kebocoran data Artefak digital risk register, vendor assessment, dan compliance
Catatan Kuliah RPL Bisnis | Halaman 137 utama checklist Risiko penting risiko non-teknis seperti budaya dan adopsi diabaikan Metrik evaluasi risk trend, vendor risk score, shadow IT count, dan adoption gap Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti risk trend, vendor risk score, shadow IT count, dan adoption gap untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 138 Unit 7.7. KPI Governance Dan Continuous Improvement Unit ini membahas kpi governance dan continuous improvement sebagai bagian penting dari topik transformasi digital dan it governance. Sudut pandang utamanya adalah availability, response time, kepatuhan, manfaat, capability, maturity, kepuasan, dan pembelajaran organisasi. Dalam pembelajaran RPL untuk bisnis, materi ini penting karena keputusan rekayasa perangkat lunak selalu berdampak pada proses, data, pengguna, risiko, dan nilai organisasi. Pada tingkat konseptual, mahasiswa perlu memahami hubungan antara kebutuhan bisnis, pilihan desain, dan artefak yang dihasilkan. Contoh penerapannya adalah manajemen memantau KPI layanan digital, realisasi manfaat ERP, dan perbaikan proses layanan bulanan. Contoh tersebut menunjukkan bahwa solusi perangkat lunak tidak berdiri sebagai produk teknis semata, tetapi sebagai intervensi terhadap cara kerja organisasi. Artefak yang perlu disiapkan meliputi KPI dictionary, governance dashboard, benefit report, dan improvement backlog. Artefak tersebut berfungsi sebagai bukti berpikir, alat komunikasi antar pemangku kepentingan, dan dasar evaluasi. Tanpa artefak yang baik, keputusan proyek mudah bergantung pada asumsi informal yang sulit diaudit. Risiko utama yang perlu diwaspadai adalah KPI terlalu banyak dan tidak terkait keputusan manajemen. Risiko ini harus diterjemahkan menjadi kontrol, tanggung jawab, rencana mitigasi, dan indikator pemantauan. Dengan demikian, pembahasan materi tidak berhenti pada definisi, tetapi berlanjut pada kemampuan mengelola konsekuensi praktisnya. Tabel 7.8. Telaah pendalaman: kpi governance dan continuous improvement. Dimensi Uraian Analitis Fokus konsep availability, response time, kepatuhan, manfaat, capability, maturity, kepuasan, dan pembelajaran organisasi Contoh penerapan manajemen memantau KPI layanan digital, realisasi manfaat ERP, dan perbaikan proses layanan bulanan Artefak KPI dictionary, governance dashboard, benefit report, dan
Catatan Kuliah RPL Bisnis | Halaman 139 utama improvement backlog Risiko penting KPI terlalu banyak dan tidak terkait keputusan manajemen Metrik evaluasi KPI actionability, benefit realization, improvement closure, dan stakeholder satisfaction Checklist Analisis • Identifikasi aktor bisnis dan teknis yang terdampak oleh keputusan pada unit ini. • Tentukan data, proses, atau layanan yang harus berubah agar solusi bekerja secara nyata. • Tetapkan artefak minimum yang harus tersedia sebelum implementasi atau evaluasi dilakukan. • Ubah risiko utama menjadi kontrol, owner, jadwal monitoring, dan bukti verifikasi. • Gunakan metrik seperti KPI actionability, benefit realization, improvement closure, dan stakeholder satisfaction untuk menilai keberhasilan secara objektif. Pertanyaan reflektif Jika unit ini diterapkan pada organisasi nyata, keputusan apa yang perlu diambil oleh manajemen, bukti apa yang harus disiapkan oleh tim teknis, dan risiko apa yang paling mungkin menghambat manfaat bisnis?
Catatan Kuliah RPL Bisnis | Halaman 140 Visualisasi Konsep Gambar 7. Visualisasi ringkas transformasi digital dan it governance. Pemetaan Materi Tabel 7.1. Pemetaan materi transformasi digital dan it governance. Aspek COBIT ITIL Pertanyaan utama Apakah TI memberi value, mengelola risk, dan memakai resource dengan baik? Bagaimana layanan TI dirancang, disampaikan, dipulihkan, dan ditingkatkan? Fokus Governance objectives, kontrol, capability, compliance Service value, incident, problem, change, service request, improvement Pemakai utama Manajemen, auditor, pengelola risiko, pemilik proses Tim layanan TI, service owner, support, operasi Kontribusi ke RPL Bisnis Menjaga proyek software tetap selaras strategi dan kontrol Menjaga layanan software stabil, responsif, dan bernilai bagi pengguna Implikasi Untuk Bisnis • Keputusan teknis perlu diterjemahkan menjadi dampak pada biaya, risiko, mutu layanan, kepuasan pengguna, dan nilai strategis organisasi.
Catatan Kuliah RPL Bisnis | Halaman 141 • Dokumentasi requirement, desain, testing, risiko, dan perubahan harus diperlakukan sebagai artefak manajerial, bukan administrasi tambahan. • Keberhasilan software bisnis bergantung pada keselarasan antara proses, data, pengguna, teknologi, dan tata kelola. Studi Kasus Dan Refleksi Studi kasus Pada implementasi ERP/CRM digital, COBIT dapat digunakan untuk menetapkan tujuan, risiko, kontrol, dan capability proses; ITIL digunakan untuk mengelola incident, request, change, dan continual improvement. Outcome yang diharapkan adalah proses lebih terintegrasi, layanan stabil, data konsisten, dan keputusan lebih cepat. • Apa keputusan desain yang paling menentukan keberhasilan kasus tersebut? • Risiko apa yang harus dimasukkan ke risk register sejak awal? • Metrik apa yang dapat dipakai untuk membuktikan manfaat bisnisnya?
Catatan Kuliah RPL Bisnis | Halaman 142 Penutup Rangkaian pertemuan 9-15 menunjukkan bahwa Rekayasa Perangkat Lunak untuk Bisnis tidak berhenti pada aktivitas coding. RPL Bisnis mencakup integrasi enterprise, perencanaan proyek, kualitas dan testing, keamanan dan compliance, kontrol perubahan, pemanfaatan AI, serta tata kelola transformasi digital. Benang merah dari seluruh materi adalah kebutuhan untuk menjaga keseimbangan antara nilai bisnis, mutu teknis, risiko, kepatuhan, dan keberlanjutan layanan. Sistem yang baik bukan hanya selesai dibangun, tetapi dapat dioperasikan, dikendalikan, diaudit, ditingkatkan, dan terus memberi manfaat bagi organisasi. Referensi Inti Dari Materi • Sommerville, I. Software Engineering, 10th ed. Pearson, 2016. • Pressman, R. S. & Maxim, B. R. Software Engineering: A Practitioner's Approach, 9th ed. McGraw-Hill, 2019. • Laudon, K. C. & Laudon, J. P. Management Information Systems. • Schwalbe, K. Information Technology Project Management. • Project Management Institute. PMBOK Guide, 7th Edition, 2021. • ISO/IEC 25010: Systems and software quality models. • ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection - ISMS requirements. • OWASP Foundation. OWASP Top Ten Web Application Security Risks. • Kim, G., Humble, J., Debois, P., & Willis, J. The DevOps Handbook. • Russell, S. & Norvig, P. Artificial Intelligence: A Modern Approach.