sim-manajement-book/chapters/outlines/_archive_v1/outline-bab-09.md

OUTLINE DETAIL — BAB 9

Siklus Hidup Pengembangan Sistem dan Manajemen Proyek SI

Bagian: III — Analisis dan Perancangan SI
Level: Menengah
Estimasi Halaman: 18–22
Target Kata: 4.500–5.500

---

SEK 9.1 — PEMBUKA

Opening Bridge dari Bab 8: Analisis proses bisnis (Bab 8) menghasilkan dua output utama: dokumentasi "as-is" dan rancangan "to-be." Rancangan "to-be" seringkali melibatkan pembangunan atau kustomisasi sistem informasi baru. Saat itulah manajer bisnis harus dapat berpartisipasi aktif — bukan hanya sebagai "end user" yang menunggu, tapi sebagai co-creator yang mendefinisikan kebutuhan dan mengevaluasi hasilnya.

Hook: Sebuah perusahaan logistik menginvestasikan Rp 15 miliar untuk sistem tracking baru. Satu tahun kemudian, sistem sudah berjalan — tapi 60% driver tidak menggunakannya karena antarmuka yang tidak intuitif untuk penggunaan di lapangan. Investigasi menemukan: tidak ada satupun driver yang pernah dilibatkan dalam proses requirements gathering. Manajer operasional tidak pernah ikut dalam satu pun demo prototype sebelum go-live. Rp 8 miliar dibutuhkan untuk redesign.

Pertanyaan sentral: "Bagaimana seorang manajer bisnis dapat berpartisipasi secara efektif dalam siklus hidup pengembangan sistem — dari perencanaan hingga evaluasi — untuk memastikan SI yang dibangun benar-benar menjawab kebutuhan bisnis?"

---

SEK 9.2 — MODEL UTAMA (Gambar 9.1)

Nama Model: Kerangka Manajemen Pengembangan SI Berbasis Nilai (MPSI-BN)

Mermaid diagram: graph TD, 2 jalur paralel (teknis dan manajerial) yang berinteraksi

Jalur Teknis (IT):
  Requirements Engineering → System Design → Development → Testing → Deployment → Maintenance

Jalur Manajerial (Business):
  Business Case → Stakeholder Alignment → UAT Participation → Change Management → Benefits Realization → Continuous Review

Titik interaksi (bisnis-IT):
  - Requirements Validation
  - Design Review
  - User Acceptance Testing
  - Go-live Decision
  - Post-implementation Review

---

SEK 9.3 — DEFINISI KUNCI

1. 📌 Siklus Hidup Pengembangan Sistem / SDLC (System Development Life Cycle) — Pendekatan terstruktur untuk merencanakan, menciptakan, menguji, dan menerapkan sistem informasi, yang mendefinisikan fase-fase, aktivitas, dan deliverable yang diharapkan di setiap tahap (Laudon & Laudon, 2022). Relevansi: manajer yang memahami SDLC dapat berpartisipasi dengan efektif di titik-titik keputusan yang kritis.

2. 📌 Metodologi Agile (Agile Development) — Pendekatan pengembangan software yang menekankan iterasi cepat, kolaborasi lintas fungsi, respons terhadap perubahan, dan delivery value secara inkremental — berlawanan dengan pendekatan waterfall yang berurutan dan kaku (Beck et al., 2021). Relevansi: Agile meningkatkan keterlibatan manajer bisnis dalam pengembangan SI — sprint review adalah mekanisme umpan balik yang efektif.

3. 📌 Business Case (Business Case Proyek SI) — Dokumen yang mengartikulasikan justifikasi untuk investasi proyek SI, mencakup problem statement, opsi solusi, analisis biaya-manfaat, risiko, dan rekomendasi; digunakan untuk mendapatkan persetujuan dan alokasi sumber daya (PMI, 2021). Relevansi: manajer bisnis — bukan IT — bertanggung jawab atas business case karena mereka yang memahami nilai bisnis.

4. 📌 UAT (User Acceptance Testing) — Fase pengujian akhir di mana pengguna bisnis memverifikasi bahwa sistem yang dikembangkan memenuhi persyaratan bisnis yang disepakati, sebelum sistem diterima secara resmi dan go-live (Laudon & Laudon, 2022). Relevansi: UAT bukan formalitas — ini adalah hak dan tanggung jawab manajer untuk memastikan sistem benar-benar menjawab kebutuhan.

---

SEK 9.4 — KONSEP INTI

9.4.1 — Metodologi SDLC: Waterfall, Agile, dan Hybrid

Argumen utama: Tidak ada metodologi yang universally "terbaik" — pilihan bergantung pada karakteristik proyek. Waterfall (Sequential):

• Fase berurutan: Requirements → Design → Development → Testing → Deployment
• Cocok untuk: requirements yang stabil dan well-defined, sistem kritikal dengan zero-defect requirement
• Kelemahan: terlambat mendeteksi masalah, perubahan mahal

Agile (Iterative/Incremental):

• Sprint 2–4 minggu, deliver working software setiap sprint
• Cocok untuk: requirements yang evolving, time-to-market penting, user involvement tinggi
• Kelemahan: sulit untuk fixed-price contracts, butuh komitmen user yang konsisten

Hybrid:

• Waterfall untuk arsitektur dan infrastruktur; Agile untuk aplikasi dan UI
• Semakin umum di enterprise

Panduan praktis: Tabel pertanyaan → rekomendasi metodologi

9.4.2 — Business Case dan Analisis Biaya-Manfaat

Argumen utama: Business case yang kuat adalah tanggung jawab manajer bisnis — IT tidak bisa membuatnya karena mereka tidak tahu nilai bisnisnya. Komponen business case proyek SI:

1. Executive summary — 1 halaman, mengapa proyek ini penting sekarang
2. Problem statement — masalah bisnis yang akan diselesaikan (terukur)
3. Solution options — minimal 3 opsi termasuk "do nothing"
4. Cost-benefit analysis — ROI, payback period, NPV
5. Risk assessment — top 5 risiko + mitigasi
6. Recommendation — opsi yang direkomendasikan + justifikasi

Biaya yang sering dilupakan:

• Lisensi ongoing (bukan hanya upfront)
• Integration costs
• Training dan change management
• Downtime selama cutover
• Technical debt jika tidak dikelola

Manfaat yang sering tidak diukur:

• Waktu manajer yang dikembalikan dari manual work
• Kualitas keputusan yang meningkat (revenue opportunity)
• Risk reduction (sulit dimonetisasi tapi nyata)

9.4.3 — Agile dan Scrum dari Sudut Pandang Manajer

Argumen utama: Agile mengubah peran manajer bisnis dalam pengembangan SI — dari definisi requirements sekali di awal ke keterlibatan berkelanjutan. Role dalam Scrum yang relevan untuk manajer bisnis:

• Product Owner — idealnya dari sisi bisnis: mendefinisikan backlog, memrioritaskan fitur, menerima sprint result
• Stakeholder — berpartisipasi dalam Sprint Review setiap 2–4 minggu
• SME (Subject Matter Expert) — subject matter expert dari departemen yang menjawab pertanyaan tim developer

Artifacts Scrum yang harus dipahami manajer:

• Product Backlog: daftar semua kebutuhan yang diprioritaskan
• Sprint Backlog: yang dikerjakan sprint ini
• Increment: software yang bisa diperagakan setiap sprint
• Definition of Done: kriteria penerimaan yang disepakati

9.4.4 — Requirements Engineering dari Perspektif Bisnis

Argumen utama: Requirements yang buruk adalah penyebab kegagalan proyek #1 — dan akarnya hampir selalu di sisi bisnis, bukan IT. Tipe requirements:

1. Business requirements — apa yang bisnis butuhkan untuk dicapai (outcome level)
2. Functional requirements — fungsi apa yang sistem harus lakukan
3. Non-functional requirements — bagaimana sistem harus berperilaku (performance, security, usability)
4. Constraints — batasan teknis/bisnis/regulasi yang tidak dapat diubah

User stories (Agile format): "As a [role], I want to [action] so that [benefit]" Contoh: "As a store manager, I want to receive alert when inventory level falls below minimum threshold, so that I can reorder before stockout occurs."

Acceptance criteria: Konkret, testable conditions untuk setiap user story

9.4.5 — Manajemen Proyek SI: Scope, Time, Cost, Quality

Argumen utama: Project management triple constraint masih valid, tapi scope management adalah yang paling kritis untuk proyek SI. Scope creep: Penyebab terbesar cost overrun dalam proyek SI.

• Tanda-tanda awal: "itu mudah, tambahkan saja", "sekalian juga ini", client requests tanpa formal change control
• Dampak: timeline molor, budget membengkak, kualitas menurun

Change control process: Setiap perubahan dari baseline requirements harus melalui proses: identifikasi impact → estimasi effort → approval → update schedule/budget → dokumentasi.

PMBOK untuk SI (PMI, 2021):

• Initiating: Charter, stakeholder identification
• Planning: Scope, WBS, schedule, cost, risk
• Executing: Team management, procurement, quality assurance
• Monitoring & Controlling: Progress, change control, risk monitoring
• Closing: Lessons learned, benefit realization handoff

9.4.6 — User Acceptance Testing dan Go-Live Decision

Argumen utama: UAT adalah gate terakhir sebelum go-live — dan ini adalah domain manajer bisnis, bukan IT. UAT yang efektif:

• Test cases berbasis business scenarios, bukan technical scenarios
• Partisipasi actual end users, bukan hanya IT champion
• Dokumentasi defect dengan prioritas bisnis (P1: critical, P2: major, P3: minor)
• Go/No-Go criteria yang disepakati sebelum UAT dimulai

Go-live decision matrix:

• P1 defects: 0 (hard stop)
• P2 defects: ≤ X dengan workaround documented
• P3 defects: acceptable, scheduled in next release

Cutover strategy:

• Big bang vs phased rollout vs parallel run
• Rollback plan jika terjadi critical issue

9.4.7 — Post-Implementation Review dan Benefits Realization

Argumen utama: Proyek SI tidak selesai saat go-live — selesai saat nilai bisnis yang dijanjikan dalam business case terwujud. Benefits realization framework:

1. Tetapkan baseline sebelum implementasi (metrik bisnis saat ini)
2. Define target benefit dengan timeline (3 bulan, 6 bulan, 1 tahun)
3. Review berkala: apakah manfaat sedang terwujud?
4. Jika tidak: investigasi hambatan — teknis, proses, atau adoption?
5. Lessons learned: apa yang bisa dilakukan lebih baik di proyek berikutnya?

Paradox post-implementation: Banyak organisasi merangkul implementasi baru tapi mengabaikan optimization setelah go-live — padahal 40–60% value biasanya datang dari 6–12 bulan pertama pasca go-live jika dikelola dengan benar.

---

SEK 9.5 — KOMPARASI (Tabel 9.1)

Judul Tabel: "Manajer Bisnis Pasif vs Manajer Bisnis Aktif dalam Proyek SI: 8 Dimensi"

Dimensi	Manajer Bisnis Pasif	Manajer Bisnis Aktif
Peran dalam requirements	Menunggu IT menganalisis	Memimpin business requirements, validasi user stories
Business case	Dibuat IT/konsultan	Dipimpin manajer bisnis, IT sebagai input
Keterlibatan pengembangan	Hadir di demo akhir	Hadir di sprint review setiap 2–4 minggu
UAT	Delegasikan ke staf junior	Partisipasi langsung pada business-critical scenarios
Change management	IT mengumumkan go-live	Manajer memimpin adoption program
Post-implementation	"Sistem sudah jalan, selesai"	Review manfaat 3, 6, 12 bulan
Kualitas sistem akhir	Baik secara teknis, tidak fit bisnis	Fit bisnis karena kontinuitas feedback
ROI proyek	Sering tidak terukur	Terukur karena baseline dan target terdefinisi

💡 Insight: Proyek SI gagal lebih sering karena manajer bisnis yang tidak terlibat daripada karena tim IT yang tidak kompeten. Keterlibatan aktif manajer bisnis adalah investasi waktu yang paling tinggi ROI-nya dalam sebuah proyek SI.

---

SEK 9.6 — REALITAS LAPANGAN

Fenomena 1: CHAOS Report — Why IT Projects Fail

Konten: Standish Group CHAOS Report (2023) menunjukkan hanya 31% proyek IT delivered on-time, on-budget, dan with full scope. 52% challenged (terlambat, over budget, atau scope dikurangi), 17% cancelled. Top 3 penyebab kegagalan: (1) poor requirements, (2) lack of stakeholder engagement, (3) poor planning. Ketiganya adalah masalah yang bisa diatasi oleh manajer bisnis yang aktif dan kompeten.

💡 Insight: Statistik kegagalan proyek IT yang telah bertahan selama 30 tahun lebih bukan karena developer tidak kompeten — tapi karena requirements dan keterlibatan stakeholder bisnis yang konsisten buruk.

Fenomena 2: Proyek SIAK (Sistem Informasi Administrasi Kependudukan) — Indonesia

Konten: Kemendagri mengimplementasikan SIAK generasi berikutnya di 500+ kantor Disdukcapil Indonesia. Tantangan: setiap daerah memiliki variasi proses yang berbeda. Solusi yang berhasil: melibatkan "super user" dari Disdukcapil daerah dalam UAT, bukan hanya tim pusat. Requirements juga dikumpulkan dengan participatory approach — manajer layanan kelurahan dilibatkan. Daerah yang prosesnya dilibatkan di awal: adoption rate 94%. Yang tidak: 61%.

💡 Insight: Keterlibatan end user dalam requirements dan UAT — meskipun memakan waktu lebih lama di awal — menghasilkan adoption yang jauh lebih tinggi.

Fenomena 3: Tokopedia — Agile at Enterprise Scale

Konten: Tokopedia mengoperasikan ratusan tim Agile yang bekerja secara parallel pada ribuan fitur produk. Product Owners di Tokopedia adalah manajer bisnis dari divisi masing-masing (Merchant Solutions, Payments, Logistics) — bukan IT. Setiap sprint review melibatkan representasi dari operations, marketing, dan customer experience. GoTo Group menyebut ini "Product-led organization" — produk digital adalah bisnis, bukan alat bisnis. (GoTo Annual Report 2024)

💡 Insight: Ketika perusahaan digital paling maju menempatkan manajer bisnis sebagai Product Owner, ini menegaskan bahwa ownership sistem informasi adalah tanggung jawab bisnis yang fundamental.

---

SEK 9.7 — JEBAKAN KOGNITIF

1. ⚠️ "IT yang tahu paling baik tentang sistemnya — biarkan mereka yang define requirements"

   • Mengapa salah: IT tahu paling baik tentang teknologi. Manajer bisnis tahu paling baik tentang kebutuhan bisnis. Konfusikan keduanya dan Anda akan mendapat sistem yang technically perfect tapi business-irrelevant.
   • Koreksi: Split tanggung jawab dengan jelas: business requirements adalah domain bisnis; technical design adalah domain IT.

2. ⚠️ "Agile berarti tidak ada planning — kita improvise seiring berjalan"

   • Mengapa salah: Agile membutuhkan lebih banyak planning, bukan lebih sedikit — hanya planning-nya bergeser dari "big upfront" ke "continuous lightweight."
   • Koreksi: Agile menekankan respondiveness terhadap perubahan — bukan ketidakdisiplinan. Product backlog yang well-prioritized adalah artefak planning yang paling penting.

3. ⚠️ "Proyek selesai saat sistem go-live"

   • Mengapa salah: Go-live adalah awal dari value realization, bukan akhir proyek. 40% dari manfaat yang direncanakan biasanya hanya terwujud dalam 12 bulan pertama pasca go-live jika dikelola secara aktif.
   • Koreksi: Tetapkan "benefits realization owner" yang bertanggung jawab memastikan manfaat bisnis yang dijanjikan dalam business case benar-benar terwujud.

4. ⚠️ "UAT adalah tanggung jawab IT untuk membuktikan sistemnya bekerja"

   • Mengapa salah: UAT adalah verifikasi bahwa sistem menjawab kebutuhan bisnis — ini bisa divalidasi hanya oleh pengguna bisnis yang memahami konteks pekerjaan sehari-hari mereka.
   • Koreksi: Pastikan UAT melibatkan actual end users, bukan hanya IT champion atau manajer yang tidak menggunakan sistem sehari-hari.

---

SEK 9.8 — STUDI KASUS

Kasus A (Dasar): Implementasi ERP di PT Semen Indonesia

Sumber: Annual Report Semen Indonesia 2024, Sari (2023) Kondisi awal (❌): PT Semen Indonesia (SIG) memiliki 3 pabrik dengan sistem keuangan dan operasional yang berbeda-beda setelah beberapa akuisisi. Konsolidasi laporan keuangan membutuhkan 10 hari. tidak ada visibilitas inventory real-time lintas pabrik. Business case tidak pernah dibuat formal; proyek ERP "dipaksakan" tanpa buy-in semua divisi. Perubahan (✅): Proyek SAP ERP Phase 2 (2021–2024) menggunakan approach berbeda: business case dibuat oleh CFO group (bukan IT), setiap divisi menunjuk business owner yang aktif dalam requirements workshop, UAT dilakukan di 3 lokasi, perubahan dikelola dengan Kotter model. Konsolidasi laporan turun ke 2 hari. Inventory visibility penuh di seluruh pabrik. Tabel: Waktu konsolidasi, inventory accuracy, user adoption rate (sebelum vs sesudah) Pelajaran: Business-led ERP implementation (vs IT-led) menghasilkan adoption yang jauh lebih tinggi dan manfaat yang lebih cepat terwujud.

Kasus B (Lanjutan): Spotify — Agile Squad Model

Sumber: Kane et al. (2022), Spotify Engineering Culture (2023) Model Spotify:

• Squads: tim kecil (5–10 orang), lintas fungsi, autonomus, responsible atas area produk tertentu
• Tribes: kumpulan squads yang terkait (max ~100 orang)
• Chapters: komunitas praktik lintas tribes (engineering excellence)
• Guilds: komunitas minat lintas seluruh organisasi

Apa yang membuat model ini bekerja: Setiap squad memiliki Product Owner dari sisi bisnis, Engineer Lead dari IT, dan clear mission + metrics success. Squads fully accountable atas produk mereka dari requirements hingga deployment hingga monitoring.

Pelajaran untuk manajer Indonesia: Model squad dapat diadaptasi bahkan di perusahaan non-tech — intinya adalah cross-functional team ownership atas proyek SI, bukan silo antara "yang minta" dan "yang membangun."

---

SEK 9.9 — TEMPLATE PRAKTIS

Nama Template: Business Case Proyek SI (Mini Canvas)

======================================
TEMPLATE 9.1 — BUSINESS CASE PROYEK SI (MINI CANVAS)
======================================

JUDUL PROYEK: ____________________________
BUSINESS OWNER: ____________________________
TANGGAL: ____________________________

BAGIAN A: PROBLEM STATEMENT
Masalah bisnis yang akan diselesaikan (konkret, terukur):
____________________________
Dampak finansial atau risiko saat ini (estimasi):
____________________________
Bukti bahwa ini masalah yang nyata (data/observasi):
____________________________

BAGIAN B: SOLUSI YANG DIUSULKAN
Opsi 1 (Do Nothing)   : Dampak: ____________________________
Opsi 2 (Quick Fix)    : Biaya: ____ Manfaat: __________________
Opsi 3 (Rekomendasi)  : Biaya: ____ Manfaat: __________________
Pilihan yang direkomendasikan: ________ , alasan: ______________

BAGIAN C: ANALISIS BIAYA-MANFAAT (Opsi yang Direkomendasikan)
BIAYA (3 tahun)
  Investasi awal (hardware/software/impl.)  : Rp ____________
  Lisensi ongoing (per tahun × 3)          : Rp ____________
  Training & change management             : Rp ____________
  Biaya tak terduga (15% contingency)      : Rp ____________
  TOTAL BIAYA 3 TAHUN                      : Rp ____________

MANFAAT (3 tahun)
  Penghematan operasional                  : Rp ____________
  Revenue baru / opportunity               : Rp ____________
  Risk reduction value                     : Rp ____________
  TOTAL MANFAAT 3 TAHUN                    : Rp ____________

ROI = (Total Manfaat - Total Biaya) / Total Biaya × 100% = _____%
Payback Period                                              = __ bulan

BAGIAN D: RISIKO UTAMA
#  | Risiko | Probabilitas | Dampak | Mitigasi
---|--------|-------------|--------|----------
1  |        | [T/S/R]     | [T/S/R] |
2  |        | [T/S/R]     | [T/S/R] |
3  |        | [T/S/R]     | [T/S/R] |

BAGIAN E: SUCCESS METRICS
KPI yang akan diukur untuk benefits realization:
  3 bulan pasca go-live: ____________________________
  6 bulan pasca go-live: ____________________________
  12 bulan pasca go-live: ____________________________

Siapa yang bertanggung jawab mengukur: ____________________________
Tanggal review pertama: ____________________________

======================================

---

SEK 9.10 — PETA KONSEP (Gambar 9.2)

Root: SDLC dan Manajemen Proyek SI
├── Metodologi
│   ├── Waterfall (stable requirements)
│   ├── Agile/Scrum (iterative)
│   └── Hybrid (enterprise practical)
├── Peran Manajer Bisnis
│   ├── Business Case owner
│   ├── Product Owner (Agile)
│   └── UAT lead
├── Requirements Engineering
│   ├── Business → Functional → Non-functional
│   └── User stories + Acceptance criteria
├── Manajemen Proyek
│   ├── Scope creep prevention
│   └── Change control process
└── Benefits Realization
    └── Baseline → Target → Review cycle

---

SEK 9.11 — RANGKUMAN

7 poin takeaway:

1. Manajer bisnis — bukan IT — bertanggung jawab atas business case proyek SI karena hanya mereka yang memahami nilai bisnis yang dihadirkan.
2. Metodologi waterfall vs Agile bukan pilihan teknis — ini adalah keputusan bisnis berdasarkan stabilitas requirements, toleransi risiko, dan urgency time-to-value.
3. Requirements yang buruk adalah penyebab kegagalan proyek SI #1 selama 30+ tahun — dan akarnya hampir selalu di sisi keterlibatan bisnis yang insufficient.
4. Agile meningkatkan keterlibatan manajer bisnis — sprint review adalah mekanisme feedback yang sangat efektif jika digunakan dengan serius.
5. UAT adalah momen ketika manajer bisnis memverifikasi bahwa sistem menjawab kebutuhan bisnis — bukan formalitas yang bisa didelegasikan sepenuhnya.
6. Proyek si tidak selesai saat go-live — benefits realization adalah tanggung jawab bisnis yang dimulai di hari 1 pasca go-live.
7. Tingkat keterlibatan manajer bisnis adalah prediktor terkuat keberhasilan proyek SI — lebih kuat dari budget, tim IT, atau teknologi yang digunakan.

Closing Bridge ke Bab 10: Pengembangan sistem yang baik (Bab 9) menghasilkan aplikasi yang berfungsi. Namun di era modern, aplikasi-aplikasi tersebut beroperasi di atas infrastruktur yang terus berevolusi — dari data center on-premise ke cloud, dari jaringan kabel ke konektivitas mobile dan IoT. Bab 10 membahas infrastruktur digital modern yang perlu dipahami manajer — bukan dari perspektif teknis, tapi dari perspektif implikasi manajerial dan keputusan strategis.

🔥 "Sistem informasi yang gagal lebih sering disebabkan oleh manajer yang tidak terlibat daripada oleh programmer yang tidak kompeten — ownership bisnis atas SI adalah tanggung jawab yang tidak bisa didelegasikan."

---

SEK 9.12 — LATIHAN & REFLEKSI

Pertanyaan Reflektif:

1. Anda baru saja dipercaya menjadi Business Owner untuk proyek implementasi CRM baru di perusahaan Anda. Apa 5 hal pertama yang akan Anda lakukan dalam 2 minggu pertama?
2. Mengapa scope creep begitu umum dan sulit dihindari dalam proyek IT? Strategi apa yang paling efektif menurut Anda?
3. Dalam konteks Agile, apa perbedaan antara "Product Owner yang baik" dan "Product Owner yang hanya menghadiri sprint review"? Apa yang membedakan keduanya dalam praktik?
4. Bagaimana Anda mengukur "success" sebuah proyek implementasi ERP — dari perspektif IT vs perspektif bisnis? Mengapa perbedaan perspektif ini penting?

Latihan Artefak 9.1 — Business Case Mini Canvas Pilih satu kebutuhan SI yang Anda identifikasi dari analisis sebelumnya (dari artefak bab 1–8):

1. Formulasikan problem statement dengan data konkret
2. Buat analisis 3 opsi solusi
3. Lakukan cost-benefit analysis sederhana untuk opsi yang direkomendasikan
4. Identifikasi 3 risiko utama dan strategi mitigasinya
5. Tentukan KPI benefits realization untuk 3, 6, dan 12 bulan

Artefak 9.1 = business case yang siap dipresentasikan kepada manajemen untuk meminta persetujuan investasi.

---

REFERENSI BAB 9

• Laudon, K. C., & Laudon, J. P. (2022). Management Information Systems: Managing the Digital Firm (17th ed.). Pearson.
• PMI. (2021). A guide to the project management body of knowledge (PMBOK guide) (7th ed.). Project Management Institute.
• Beck, K., et al. (2021). Manifesto for agile software development (20th anniversary ed.). Agile Alliance.
• Standish Group. (2023). CHAOS report 2023: Decision latency theory. The Standish Group International.
• Kane, G. C., Phillips, A. N., Copulsky, J., & Andrus, G. (2022). The technology fallacy: How people are the real key to digital transformation. MIT Press.
• Dumas, M., La Rosa, M., Mendling, J., & Reijers, H. A. (2021). Fundamentals of business process management (3rd ed.). Springer.
• GoTo Group. (2024). Annual report 2024. PT GoTo Gojek Tokopedia Tbk.
• Sari, N. P. (2023). Transformasi digital perbankan di Indonesia: Studi kasus Bank BRI. Jurnal Manajemen dan Bisnis Digital, 5(2), 89–104.
• McKinsey & Company. (2023). Delivering large-scale IT projects on time, on budget, and on value. McKinsey Digital.
• Turban, E., Pollard, C., & Wood, G. (2021). Information technology for management (11th ed.). Wiley.
• Cobb, C. G. (2022). The project manager's guide to mastering agile: Principles and practices for an adaptive approach (2nd ed.). Wiley.
• Rogers, D. L. (2021). The digital transformation roadmap. Columbia Business School Publishing.