449 lines
33 KiB
Markdown
449 lines
33 KiB
Markdown
# BAB 10 — Pemodelan Proses Bisnis
|
||
|
||
|
||
```
|
||
Bagian : V — Perancangan Solusi SI
|
||
Reader Outcome : Pembaca mampu membuat model proses bisnis menggunakan swimlane
|
||
diagram dan notasi BPMN dasar, menganalisis proses AS-IS untuk
|
||
mengidentifikasi bottleneck, dan merancang model TO-BE yang
|
||
menjadi dasar perancangan SI.
|
||
Level : Lanjutan
|
||
Estimasi Halaman: 15–18
|
||
```
|
||
|
||
---
|
||
|
||
## 10.1 Pembuka
|
||
|
||
Bab 9 membekali Anda dengan kemampuan memetakan kebutuhan informasi per level manajemen. Template A.9 (*Information Requirement Table*) menghasilkan daftar informasi yang dibutuhkan, oleh siapa, dalam format apa, dan seberapa sering. Tetapi informasi tidak muncul dari ruang hampa — ia dihasilkan oleh proses bisnis yang mengolah data mentah menjadi *output* yang relevan bagi pengambil keputusan. Pertanyaannya: proses bisnis mana yang memproduksi informasi tersebut, dan apakah proses itu berjalan efisien?
|
||
|
||
Sebuah Bank Perkreditan Rakyat (BPR) di Jawa Timur mengeluhkan bahwa "proses kredit terlalu lama — 14 hari." Kompetitor *fintech* menawarkan 3 hari. Manajemen merespons: "beli *loan origination system*." Tetapi ketika diminta menggambar proses kreditnya secara lengkap — dari pengajuan hingga pencairan — tidak satu orang pun di BPR itu bisa menjelaskan secara konsisten berapa langkah yang ada, siapa melakukan apa, dan di titik mana data berpindah tangan. Lima staf menggambar lima diagram berbeda. Proses yang tidak bisa divisualisasikan tidak bisa dianalisis — apalagi diperbaiki.
|
||
|
||
Mengapa proses bisnis harus divisualisasikan sebelum SI dirancang — dan bagaimana manajer menggunakan model AS-IS dan TO-BE untuk mengidentifikasi *bottleneck* informasi dan merancang perbaikan?
|
||
|
||
---
|
||
|
||
## 10.2 Model Utama
|
||
|
||
### Gambar 10.1 — Siklus Pemodelan Proses Bisnis
|
||
|
||
```mermaid
|
||
graph LR
|
||
ASIS["Identifikasi<br>Proses AS-IS"] --> DOC["Dokumentasi<br>Swimlane/BPMN"]
|
||
DOC --> ANALYZE["Analisis Bottleneck<br>& Redundansi"]
|
||
ANALYZE --> GAP["Analisis<br>Gap"]
|
||
GAP --> TOBE["Desain<br>TO-BE"]
|
||
TOBE --> IMPL["Implementasi<br>TO-BE + SI"]
|
||
IMPL --> MONITOR["Monitor<br>& Evaluasi"]
|
||
MONITOR -.->|continuous improvement| ASIS
|
||
style ASIS fill:#1a4a5c,stroke:#333,color:#fff
|
||
style DOC fill:#1a4a5c,stroke:#333,color:#fff
|
||
style ANALYZE fill:#1a4a5c,stroke:#333,color:#fff
|
||
style GAP fill:#1a4a5c,stroke:#333,color:#fff
|
||
style TOBE fill:#1a4a5c,stroke:#333,color:#fff
|
||
style IMPL fill:#1a4a5c,stroke:#333,color:#fff
|
||
style MONITOR fill:#1a4a5c,stroke:#333,color:#fff
|
||
```
|
||
|
||
**Identifikasi Proses AS-IS** — memetakan proses yang berjalan saat ini apa adanya, tanpa idealisasi. Sumber informasi: wawancara pelaku proses, observasi langsung di lapangan, dan analisis dokumen yang benar-benar digunakan (bukan SOP yang tersimpan di lemari).
|
||
|
||
**Dokumentasi Swimlane/BPMN** — memvisualisasikan proses dalam notasi standar yang menjawab empat pertanyaan: siapa (aktor di setiap *lane*), melakukan apa (aktivitas), dalam urutan apa (sekuens), dan informasi apa yang berpindah antar-aktor (*data flow*).
|
||
|
||
**Analisis *Bottleneck* & Redundansi** — mengidentifikasi titik-titik di mana proses macet (*bottleneck*), data di-*copy* manual ke beberapa form (*redundansi*), atau informasi hilang saat berpindah aktor (*information loss*). Di sinilah akar inefisiensi terungkap.
|
||
|
||
**Analisis *Gap*** — membandingkan proses AS-IS dengan *best practice* atau dengan kebutuhan informasi yang sudah dipetakan di Bab 9. Selisih antara "proses saat ini" dan "proses yang dibutuhkan" menjadi spesifikasi perbaikan.
|
||
|
||
**Desain TO-BE** — merancang proses masa depan yang menghilangkan *bottleneck*, mengurangi redundansi, dan mendukung kebutuhan informasi yang sudah teridentifikasi. SI dirancang untuk mendukung proses TO-BE — bukan mengotomasi proses AS-IS.
|
||
|
||
**Implementasi & Monitor** — menerapkan proses baru beserta SI pendukungnya, lalu mengevaluasi secara berkelanjutan. Proses bisnis hidup: ia berevolusi seiring perubahan organisasi, pasar, dan regulasi. Siklus kembali ke identifikasi AS-IS untuk iterasi berikutnya.
|
||
|
||
---
|
||
|
||
## 10.3 Definisi Kunci
|
||
|
||
***Business Process* (Proses Bisnis)**
|
||
Serangkaian aktivitas terstruktur yang saling terkait, dilakukan oleh satu atau lebih aktor, yang menerima *input* dan menghasilkan *output* bernilai bagi pelanggan atau *stakeholder*. SI dirancang untuk mendukung proses bisnis — bukan sebaliknya. Manajer yang tidak memahami proses bisnisnya sendiri tidak bisa menspesifikasikan SI yang tepat. Dumas et al. (2021) menegaskan bahwa proses bisnis adalah unit dasar analisis dalam perancangan SI.
|
||
|
||
***Swimlane Diagram***
|
||
Diagram alur yang membagi proses berdasarkan aktor, unit, atau departemen menggunakan "jalur renang" horizontal atau vertikal, menunjukkan siapa bertanggung jawab atas aktivitas mana. *Swimlane* membuat *accountability* terlihat secara visual — manajer bisa langsung melihat di mana *handoff* terjadi, di mana informasi berpindah aktor, dan di mana *bottleneck* mungkin muncul.
|
||
|
||
**BPMN (*Business Process Model and Notation*)**
|
||
Standar notasi internasional dari OMG (*Object Management Group*) untuk memodelkan proses bisnis menggunakan simbol-simbol formal: *event* (lingkaran), *activity* (kotak), *gateway* (diamond), dan *sequence flow* (panah). BPMN berfungsi sebagai "bahasa" universal antara manajer dan tim teknis. White (2004) mendesain standar ini agar *readable* oleh semua pihak — dari eksekutif bisnis hingga *developer*.
|
||
|
||
**AS-IS vs TO-BE**
|
||
AS-IS: model proses yang berjalan saat ini, dipetakan apa adanya. TO-BE: model proses yang diinginkan di masa depan, dirancang untuk mengeliminasi inefisiensi. *Gap* antara keduanya menjadi landasan perancangan SI. Organisasi yang langsung merancang SI tanpa model AS-IS sering mengotomasi proses yang sudah rusak — Hammer dan Champy (1993) menyebutnya "*paving the cow path*."
|
||
|
||
---
|
||
|
||
## 10.4 Konsep Inti
|
||
|
||
### 10.4.1 Mengapa Proses Bisnis Harus Dimodelkan Sebelum SI Dirancang
|
||
|
||
Merancang SI tanpa memahami proses bisnis seperti membangun jalan tol tanpa memetakan pola lalu lintas — hasilnya mungkin cepat tetapi menuju arah yang salah. *Model* proses memastikan SI mendukung alur kerja nyata, bukan asumsi *developer* tentang bagaimana seharusnya pekerjaan dilakukan.
|
||
|
||
Hammer dan Champy (1993) mendokumentasikan bahwa *Business Process Reengineering* (BPR) yang didahului pemodelan proses menghasilkan peningkatan efisiensi 60–90%. Bandingkan dengan organisasi yang langsung memasang SI tanpa analisis proses — peningkatan efisiensi rata-rata hanya 10–20%, dan sering kali efisiensi baru itu datang dari kecepatan mengerjakan hal yang salah.
|
||
|
||
Contoh konkret: sebuah SIMRS dirancang berdasarkan "*best practice*" vendor, tanpa memodelkan proses rawat jalan AS-IS rumah sakit tersebut. Hasilnya: sistem memaksa perawat melakukan 3× *input* data manual karena alur yang diasumsikan vendor tidak cocok dengan SOP rumah sakit. SI yang seharusnya mempercepat malah memperlambat — karena dirancang tanpa memahami proses yang didukungnya.
|
||
|
||
### 10.4.2 *Swimlane Diagram*: Membuat *Accountability* Terlihat
|
||
|
||
*Swimlane* adalah alat pemodelan paling intuitif bagi manajer karena menjawab tiga pertanyaan sekaligus: siapa melakukan, apa yang dilakukan, dan kapan dilakukan — dalam satu visualisasi.
|
||
|
||
Elemen kunci *swimlane diagram*:
|
||
|
||
- ***Lane*** — jalur horizontal atau vertikal yang merepresentasikan satu aktor (orang, unit, atau sistem). Setiap aktivitas ditempatkan di *lane* aktor yang bertanggung jawab.
|
||
- ***Activity*** — kotak yang merepresentasikan satu langkah kerja. "Verifikasi data nasabah" adalah satu *activity*.
|
||
- ***Decision*** — diamond yang merepresentasikan percabangan logika. "Apakah dokumen lengkap?" menghasilkan dua jalur: Ya dan Tidak.
|
||
- ***Flow*** — panah yang menghubungkan aktivitas secara sekuensial.
|
||
- ***Handoff*** — panah yang melintasi *lane* berbeda, menunjukkan perpindahan tanggung jawab dari satu aktor ke aktor lain.
|
||
|
||
Setiap *handoff* lintas-*lane* adalah titik rawan: di sanalah informasi bisa hilang, terdistorsi, atau tertunda. Proses pengajuan cuti sederhana — Karyawan → Manajer → HR → Sistem → Karyawan — sudah mengandung 4 *handoff*. Jika salah satu *handoff* dilakukan via WhatsApp tanpa *audit trail*, informasi bisa tercecer tanpa ada yang menyadari.
|
||
|
||
### 10.4.3 BPMN Dasar untuk Manajer: Empat Simbol yang Cukup
|
||
|
||
BPMN memiliki puluhan simbol dalam spesifikasi lengkapnya. Tetapi manajer bukan *process engineer* — mereka butuh literasi, bukan keahlian teknis. Dumas et al. (2021) menekankan bahwa 80% kebutuhan pemodelan manajerial bisa ditangani dengan *subset* 4–5 simbol dasar:
|
||
|
||
| Simbol | Nama | Bentuk | Fungsi |
|
||
|--------|------|--------|--------|
|
||
| ○ | *Start Event* | Lingkaran tipis | Menandai awal proses |
|
||
| ◉ | *End Event* | Lingkaran tebal | Menandai akhir proses |
|
||
| ▭ | *Task/Activity* | Kotak *rounded* | Satu langkah kerja |
|
||
| ◇ | *Gateway* | Diamond | Percabangan keputusan atau paralelisme |
|
||
| → | *Sequence Flow* | Panah | Urutan aktivitas |
|
||
|
||
Dengan empat simbol ini, manajer bisa membaca model BPMN yang dibuat analis, memvalidasi apakah model itu merepresentasikan realitas, dan memberikan masukan untuk perbaikan. Tidak perlu menguasai *message flow*, *signal event*, atau *subprocess* — itu urusan *modeler* teknis.
|
||
|
||
Penekanan bab ini: bukan tutorial BPMN teknis, melainkan literasi pemodelan agar manajer bisa berkomunikasi dengan analis dan *developer* menggunakan "bahasa" yang sama. Manajer yang bisa membaca BPMN tidak perlu bergantung sepenuhnya pada penjelasan verbal analis yang mungkin menyederhanakan atau salah interpretasi.
|
||
|
||
### 10.4.4 Analisis AS-IS: Memetakan Realitas Tanpa Idealisasi
|
||
|
||
AS-IS harus memetakan proses yang *benar-benar* berjalan — bukan proses yang tertulis di SOP manual yang mungkin sudah ketinggalan zaman bertahun-tahun. Di banyak organisasi Indonesia, SOP resmi dan proses aktual adalah dua hal yang berbeda. Sering kali ada "*shadow process*" — langkah-langkah yang dilakukan karyawan sebagai *workaround* karena SOP resmi tidak praktis.
|
||
|
||
Teknik pengumpulan AS-IS yang efektif:
|
||
|
||
- **Wawancara terstruktur** — tanya pelaku: "Ceritakan langkah demi langkah apa yang Anda lakukan dari awal sampai akhir." Hindari pertanyaan "bagaimana seharusnya" — fokus pada "bagaimana sebenarnya."
|
||
- **Observasi langsung** — duduk di samping pelaku proses, amati apa yang benar-benar terjadi. Sering ditemukan langkah yang tidak disebutkan dalam wawancara karena sudah menjadi kebiasaan otomatis.
|
||
- ***Document tracing*** — telusuri formulir fisik atau *digital form* dari awal sampai akhir: siapa yang mengisi, siapa yang menandatangani, di mana formulir itu menunggu, dan berapa lama.
|
||
|
||
Contoh diskrepansi SOP vs realitas: SOP resmi menyatakan "verifikasi data oleh supervisor sebelum diproses." Realitas AS-IS: supervisor tidak pernah memverifikasi karena volume terlalu tinggi — staf langsung memproses sendiri dan supervisor hanya menandatangani *batch* di akhir hari. SI yang dirancang berdasarkan SOP (bukan AS-IS) akan membangun fitur "*supervisor approval*" yang dalam praktik selalu di-*skip* — membuang waktu *development* dan menambah langkah tanpa nilai.
|
||
|
||
### 10.4.5 Identifikasi *Bottleneck* dan Redundansi Informasi
|
||
|
||
Setelah AS-IS dipetakan, langkah berikutnya adalah diagnosis: di mana titik-titik masalah? Empat pola masalah yang paling sering terungkap melalui pemodelan proses:
|
||
|
||
### Tabel 10.2 — Pola Masalah dalam Proses Bisnis dan Intervensi SI
|
||
|
||
| Pola Masalah | Indikator | Dampak | Intervensi SI |
|
||
|-------------|-----------|--------|--------------|
|
||
| *Bottleneck* | Antrian panjang di satu titik | *Lead time* meningkat | Otomasi titik *bottleneck* |
|
||
| Redundansi data | *Entry* data yang sama di ≥2 form | *Error rate* tinggi, inkonsistensi | *Single entry* + *database* terpusat |
|
||
| *Information loss* | Data hilang antar *handoff* aktor | Keputusan tanpa data lengkap | *Workflow system* + *audit trail* |
|
||
| *Unnecessary loop* | ≥3 *approval* untuk hal rutin | Birokrasi berlebihan | *Exception-based approval* |
|
||
|
||
Dumas et al. (2021) melaporkan bahwa rata-rata proses bisnis mengandung 30–40% aktivitas yang tidak menambah nilai (*non-value-adding*). Aktivitas ini berupa: menunggu, memindahkan dokumen, meng-*entry* ulang data yang sudah ada, dan meminta persetujuan untuk hal-hal yang tidak memerlukan pertimbangan manajerial.
|
||
|
||
Cara mengidentifikasi *non-value-adding activity*: untuk setiap langkah dalam model AS-IS, tanyakan — "Apakah pelanggan atau *stakeholder* bersedia membayar untuk langkah ini?" Jika jawabannya tidak, langkah itu kandidat eliminasi atau otomasi.
|
||
|
||
### 10.4.6 Dari AS-IS ke TO-BE: Merancang Proses Masa Depan
|
||
|
||
TO-BE bukan sekadar "AS-IS minus *bottleneck*." Desain proses masa depan harus mempertimbangkan tiga input secara simultan:
|
||
|
||
- **Kebutuhan informasi** yang sudah dipetakan di Bab 9 — proses TO-BE harus memproduksi informasi yang dibutuhkan setiap level manajemen
|
||
- **Kemampuan teknologi** yang akan dibahas di Bab 12 — apa yang dimungkinkan oleh teknologi saat ini
|
||
- **Strategi organisasi** yang dibahas di Bab 2 — proses harus selaras dengan arah strategis, bukan sekadar efisien secara operasional
|
||
|
||
Empat prinsip desain TO-BE:
|
||
|
||
1. ***Eliminate*** — hapus aktivitas yang tidak menambah nilai. Jika tidak ada yang dirugikan ketika langkah itu dihilangkan, hilangkan.
|
||
2. ***Automate*** — otomasi tugas repetitif yang terstruktur. *Data entry* ganda, *routing* dokumen, dan validasi format adalah kandidat utama.
|
||
3. ***Integrate*** — hubungkan informasi lintas-fungsi. Jika data yang sama dibutuhkan oleh 3 departemen, sediakan dari satu sumber — bukan 3 *entry* terpisah.
|
||
4. ***Enable visibility*** — pastikan setiap aktor bisa melihat status proses secara *real-time*. Transparansi menghilangkan pertanyaan "sudah sampai mana?"
|
||
|
||
Contoh penerapan: proses kredit BPR AS-IS memakan 14 hari dengan 23 langkah dan 7 *handoff* manual. Setelah menerapkan empat prinsip di atas, TO-BE menghasilkan 5 hari dengan 12 langkah dan 2 *handoff* manual — sisanya diotomasi oleh SI.
|
||
|
||
---
|
||
|
||
## 10.5 Komparasi
|
||
|
||
### Tabel 10.1 — Flowchart vs BPMN vs *Use Case Diagram*: Kapan Menggunakan Mana?
|
||
|
||
| Dimensi | *Flowchart* | BPMN | *Use Case Diagram* |
|
||
|---------|-----------|------|-----------------|
|
||
| Tujuan | Visualisasi alur logika | Model proses bisnis standar | Identifikasi interaksi *user–system* |
|
||
| Audiens | Umum, semua level | Manajer + analis + *developer* | Analis + *developer* |
|
||
| Kompleksitas | Rendah | Menengah–tinggi | Menengah |
|
||
| Standar | Tidak formal | ISO/OMG formal | UML (semi-formal) |
|
||
| Multi-aktor | Terbatas | Excellent (*swimlane built-in*) | Ya (aktor terpisah) |
|
||
| *Tools* | Kertas, Visio, Lucidchart | Bizagi, Camunda, Signavio | StarUML, Visual Paradigm |
|
||
| Kapan dipakai | Proses sederhana, linear | Proses lintas-fungsi, pra-desain SI | Saat spesifikasi kebutuhan fungsional |
|
||
| Keterbatasan | Tidak *scalable* untuk kompleks | *Learning curve* notasi lengkap | Tidak menunjukkan alur waktu |
|
||
|
||
**Insight:** Banyak manajer UMKM Indonesia cukup dilayani oleh *flowchart* sederhana untuk proses internal yang linear. BPMN menjadi penting ketika proses melibatkan tiga departemen atau lebih dan akan diimplementasikan dalam *workflow system*. *Use Case Diagram* paling relevan di fase *development* — bukan fase analisis manajerial. Memilih notasi yang tepat untuk konteks yang tepat menghemat waktu dan mengurangi kebingungan.
|
||
|
||
---
|
||
|
||
## 10.6 Realitas Lapangan
|
||
|
||
### Fenomena 1: BPR di Jawa Timur — Proses Kredit 14 Hari yang Ternyata Hanya Butuh 3 Hari Kerja Efektif
|
||
|
||
Sebuah BPR di Jawa Timur melayani 200+ nasabah kredit per bulan dengan rata-rata proses 14 hari kalender. Manajemen mengasumsikan prosesnya padat — sehingga solusinya: tambah staf dan beli sistem *loan origination*.
|
||
|
||
Ketika tim konsultan memodelkan proses AS-IS dalam *swimlane diagram* (4 *lane*: Nasabah, *Customer Service*, Analis Kredit, Pimpinan Cabang), hasilnya mengejutkan: dari 14 hari kalender, hanya 3 hari kerja efektif yang benar-benar *value-adding*. Sebelas hari sisanya: menunggu dokumen dari nasabah yang harus datang langsung (5 hari), menunggu *approval* pimpinan yang sering bertugas luar kantor (3 hari), dan *re-entry* data manual ke 3 sistem berbeda yang tidak terintegrasi (3 hari).
|
||
|
||
SI baru yang dirancang berdasarkan TO-BE — *upload* digital dokumen nasabah via aplikasi, *mobile approval* untuk pimpinan, dan *single-entry* dengan API *integration* — memangkas proses menjadi 5 hari. Investasi SI-nya jauh lebih murah daripada menambah staf.
|
||
|
||
**Insight:** Pemodelan proses sering mengungkap "*hidden waste*" yang tidak terlihat oleh siapa pun karena tidak ada yang pernah menvisualisasikan alur lengkap secara *end-to-end*. Angka 79% *non-value-adding time* bukan anomali — banyak proses bisnis di Indonesia memiliki pola serupa.
|
||
|
||
### Fenomena 2: "*Paving the Cow Path*" — Mengotomasi Proses yang Rusak
|
||
|
||
Istilah klasik dalam literatur BPR: "*paving the cow path*" — membangun jalan beraspal di jalur yang dilalui sapi, tanpa bertanya apakah jalur itu optimal. Sapinya berjalan berkelok-kelok menghindari batu dan pohon yang sudah tidak ada. Jalan beraspal yang mengikuti jalur itu tetap berkelok-kelok — padahal jalan lurus sekarang dimungkinkan.
|
||
|
||
Banyak organisasi di Indonesia melakukan hal serupa: mengotomasi proses AS-IS tanpa menganalisis apakah proses itu sendiri perlu diubah. Contoh: sebuah instansi pemerintah mengembangkan SI e-*procurement* dengan *workflow* 17 langkah yang mereplikasi proses manual sebelumnya. Setelah evaluasi, 7 dari 17 langkah itu adalah tanda tangan persetujuan bertingkat yang awalnya diperlukan karena "*kalau-kalau ada masalah*" — bukan karena menambah nilai. SI yang canggih tetapi menjalankan proses 17 langkah itu hanya membuat birokrasi berlebihan *terasa* lebih modern — tanpa benar-benar menjadi lebih efisien.
|
||
|
||
**Insight:** SI harus dirancang untuk mendukung proses TO-BE, bukan mengotomasi proses AS-IS yang mungkin sudah *broken by design*. Otomasi tanpa analisis proses sering kali mempercepat hal-hal yang seharusnya dihilangkan.
|
||
|
||
### Fenomena 3: Toyota *Production System* — Visualisasi Proses sebagai Budaya
|
||
|
||
Toyota menjadikan visualisasi proses (*Value Stream Mapping*) bukan sekadar alat analisis proyek, melainkan budaya organisasi. Setiap jalur produksi memiliki "*process board*" yang memvisualisasikan alur material dan informasi secara *real-time*. Setiap karyawan — dari operator lini hingga manajer pabrik — bisa melihat di mana *bottleneck* terjadi, di mana *waste* menumpuk, dan di mana peluang perbaikan ada.
|
||
|
||
*Andon board* — papan visual yang menampilkan status setiap stasiun kerja — adalah SI dalam bentuk paling murni: menyajikan informasi yang tepat, kepada orang yang tepat, pada waktu yang tepat. Ketika lampu merah menyala di satu stasiun, seluruh lini tahu ada masalah — tanpa perlu rapat, email, atau menunggu laporan mingguan. Ohno (1988) mendokumentasikan bahwa pendekatan ini mengurangi *defect rate* Toyota hingga 0,03%.
|
||
|
||
**Insight:** Pemodelan proses bisnis paling efektif bukan sebagai proyek *one-time* sebelum implementasi SI, tetapi sebagai praktik berkelanjutan yang menjadi bagian dari DNA organisasi. Toyota membuktikan bahwa visualisasi proses bukan latihan akademik — ia adalah manajemen itu sendiri.
|
||
|
||
---
|
||
|
||
## 10.7 Salah Kaprah
|
||
|
||
***"Diagram proses bisnis itu urusan analis sistem, bukan manajer"***
|
||
|
||
> Manajer adalah pemilik proses bisnis. Jika manajer menyerahkan pemodelan sepenuhnya ke analis, hasilnya adalah model yang *technically correct* tetapi *business-irrelevant* — karena analis tidak memahami nuansa, pengecualian, dan *workaround* yang terjadi di lapangan. Model proses yang dibuat tanpa validasi manajer sering merepresentasikan "proses ideal" yang tidak pernah ada di dunia nyata.
|
||
>
|
||
> **Koreksi:** Manajer harus terlibat minimal di tiga titik: (1) validasi AS-IS — "apakah model ini merepresentasikan apa yang benar-benar terjadi?", (2) masukan untuk TO-BE — "apa yang harus berubah dan mengapa?", (3) *review* akhir model — "apakah saya bisa menjalankan proses baru ini?"
|
||
|
||
***"Prosesnya sudah jelas, tidak perlu digambar"***
|
||
|
||
> Setiap orang dalam organisasi memiliki pemahaman berbeda tentang proses — bahkan untuk proses yang "semua orang tahu." Dumas et al. (2021) melaporkan bahwa ketika 5 orang diminta menggambar proses yang sama, hasilnya 5 diagram berbeda: urutan langkah beda, aktor beda, bahkan jumlah langkah beda. Tanpa visualisasi, organisasi bekerja dengan asumsi individual — bukan pemahaman bersama.
|
||
>
|
||
> **Koreksi:** Lakukan satu eksperimen sederhana: minta 3 orang dari departemen berbeda menggambar proses yang sama secara independen. Bandingkan hasilnya. Perbedaannya akan membuktikan bahwa "sudah jelas" hanya ilusi — dan bahwa visualisasi bukan kemewahan, melainkan kebutuhan.
|
||
|
||
***"BPMN itu terlalu teknis untuk manajemen"***
|
||
|
||
> BPMN dalam spesifikasi lengkapnya memang teknis — ada puluhan simbol untuk *message flow*, *signal event*, *subprocess collapsed*, dan seterusnya. Tetapi *subset* yang dibutuhkan manajer hanya 4–5 simbol (Sek 10.4.3), yang tidak lebih sulit dari *flowchart* biasa. Persepsi "terlalu teknis" sering berasal dari presentasi BPMN yang langsung menunjukkan diagram kompleks, bukan dari tingkat kesulitan yang sebenarnya.
|
||
>
|
||
> **Koreksi:** Manajer tidak perlu menjadi *BPMN expert* — cukup "*literate*" agar bisa membaca dan memvalidasi model yang dibuat analis. Belajar 4 simbol: *event*, *task*, *gateway*, *flow*. Dumas et al. (2021) mengkonfirmasi bahwa *subset* ini mencakup 80% kebutuhan pemodelan manajerial.
|
||
|
||
---
|
||
|
||
## 10.8 Studi Kasus
|
||
|
||
### Studi Kasus Dasar — BPR: Pemodelan Proses Kredit untuk Menghilangkan *Bottleneck*
|
||
|
||
**Kondisi Awal:**
|
||
BPR melayani 200+ nasabah kredit per bulan dengan proses yang memakan 14 hari kalender. Nasabah mulai pindah ke kompetitor *fintech* yang menawarkan 3 hari. Manajemen mengusulkan: "beli *software loan origination system* dari vendor." Anggaran yang dialokasikan: Rp 800 juta.
|
||
|
||
**Setelah Pemodelan AS-IS:**
|
||
Tim konsultan memodelkan 23 langkah proses kredit dalam *swimlane diagram* (4 *lane*: Nasabah, *Customer Service*, Analis Kredit, Pimpinan Cabang). Analisis mengungkap 3 *bottleneck* utama dan 2 titik redundansi data.
|
||
|
||
### Tabel 10.3 — Analisis *Bottleneck* Proses Kredit BPR
|
||
|
||
| *Bottleneck* | Penyebab | Waktu Terbuang | Solusi TO-BE |
|
||
|-------------|----------|----------------|-------------|
|
||
| *Input* dokumen nasabah | Pengumpulan fisik, fotokopi, nasabah harus datang 2× | 5 hari | *Upload* digital via aplikasi mobile |
|
||
| *Approval* pimpinan | Pimpinan sering bertugas luar kantor, dokumen fisik di meja | 3 hari | *Mobile approval* + *delegation rule* |
|
||
| *Entry* data ulang | 3 sistem berbeda tanpa integrasi | 3 hari | *Single entry* + API *integration* |
|
||
|
||
**Hasil TO-BE:** proses 5 hari, 12 langkah, 2 *handoff* manual — total investasi SI Rp 350 juta (lebih murah dari rencana awal). Kapasitas pelayanan meningkat 40% tanpa menambah staf.
|
||
|
||
**Pelajaran:** *Software* mahal tidak menyelesaikan masalah jika proses yang mendasarinya belum dianalisis. Pemodelan AS-IS mengungkap bahwa 79% waktu proses kredit itu bukan *value-adding* — dan solusi yang tepat bukan "SI yang lebih canggih" tetapi "proses yang lebih *lean*." Rp 800 juta yang nyaris dibelanjakan untuk *software* yang mengotomasi proses 23 langkah bisa digantikan Rp 350 juta untuk *software* yang mendukung proses 12 langkah.
|
||
|
||
### Studi Kasus Lanjutan — Toyota: *Value Stream Mapping* sebagai DNA Organisasi
|
||
|
||
**Kondisi Awal (era sebelum TPS):**
|
||
Manufaktur otomotif tradisional beroperasi dengan *batch production*: inventori menumpuk di antar-stasiun kerja, informasi mengalir lambat dari lantai produksi ke manajemen melalui laporan mingguan, dan *defect* baru ditemukan di akhir lini produksi — saat biaya perbaikan sudah berlipat ganda.
|
||
|
||
**Setelah *Value Stream Mapping*:**
|
||
Toyota memvisualisasikan seluruh alur material DAN informasi dari *supplier* hingga pelanggan. Setiap stasiun kerja dilengkapi *andon board* yang menampilkan status *real-time*. *Kanban card* berfungsi sebagai SI fisik yang mengontrol *flow* produksi — mengomunikasikan "apa yang dibutuhkan, berapa banyak, dan kapan" tanpa instruksi manual dari manajer.
|
||
|
||
### Tabel 10.4 — Dampak *Value Stream Mapping* di Toyota
|
||
|
||
| Dimensi | Sebelum VSM | Setelah VSM |
|
||
|---------|------------|-------------|
|
||
| *Lead time* | 30 hari | 3 hari |
|
||
| Inventori (*days of supply*) | 60 hari | 5 hari |
|
||
| *Defect rate* | 5% | 0,03% |
|
||
| Alur informasi | Laporan *batch* mingguan | *Real-time visual board* |
|
||
| Deteksi masalah | Di akhir lini produksi | Di titik terjadinya (*andon*) |
|
||
|
||
Kunci sukses Toyota bukan teknologi canggih — melainkan komitmen untuk memvisualisasikan setiap proses sehingga masalah tidak bisa "bersembunyi." Rother dan Shook (2003) mendokumentasikan bahwa *Value Stream Mapping* di Toyota bukan proyek tahunan, melainkan aktivitas mingguan di setiap lini produksi.
|
||
|
||
**Pelajaran:** Toyota membuktikan bahwa visualisasi proses bukan hanya alat analisis — ia adalah manajemen. Ketika setiap orang bisa "melihat" proses, masalah terdeteksi lebih cepat, *improvement* lebih sering, dan SI menjadi perpanjangan natural dari *visual management* yang sudah ada. Prinsip ini berlaku di industri apa pun — bukan hanya manufaktur.
|
||
|
||
---
|
||
|
||
## 10.9 Template Praktis
|
||
|
||
**Template A.10 — *Worksheet* Diagram AS-IS**
|
||
|
||
```
|
||
TEMPLATE A.10 — WORKSHEET DIAGRAM AS-IS
|
||
|
||
Tanggal : ________________________________________
|
||
Proses : ________________________________________
|
||
Analis : ________________________________________
|
||
|
||
═══════════════════════════════════════════════════════════════
|
||
|
||
A. IDENTIFIKASI PROSES
|
||
Nama proses : ________________________________________
|
||
Pemicu (trigger) : ________________________________________
|
||
Output akhir : ________________________________________
|
||
Aktor terlibat : ________________________________________
|
||
|
||
B. DAFTAR AKTIVITAS (urut dari awal sampai akhir)
|
||
|
||
| No | Aktivitas | Aktor | Input | Output | Waktu | Value-Adding? |
|
||
|----|-----------------|---------|---------|---------|---------|------------------|
|
||
| 1 | _______________ | _______ | _______ | _______ | _______ | [ ] Ya [ ] Tidak |
|
||
| 2 | _______________ | _______ | _______ | _______ | _______ | [ ] Ya [ ] Tidak |
|
||
| 3 | _______________ | _______ | _______ | _______ | _______ | [ ] Ya [ ] Tidak |
|
||
| 4 | _______________ | _______ | _______ | _______ | _______ | [ ] Ya [ ] Tidak |
|
||
| 5 | _______________ | _______ | _______ | _______ | _______ | [ ] Ya [ ] Tidak |
|
||
| 6 | _______________ | _______ | _______ | _______ | _______ | [ ] Ya [ ] Tidak |
|
||
| 7 | _______________ | _______ | _______ | _______ | _______ | [ ] Ya [ ] Tidak |
|
||
| 8 | _______________ | _______ | _______ | _______ | _______ | [ ] Ya [ ] Tidak |
|
||
|
||
C. IDENTIFIKASI MASALAH
|
||
Bottleneck (titik macet) : ________________________________________
|
||
Redundansi data : ________________________________________
|
||
Information loss : ________________________________________
|
||
Unnecessary loops : ________________________________________
|
||
|
||
D. RINGKASAN ANALISIS
|
||
Total waktu proses : ________________________________________
|
||
Waktu value-adding : ________________________________________
|
||
Persentase non-value-adding : ________________________________________
|
||
Prioritas perbaikan : ________________________________________
|
||
|
||
E. SKETSA SWIMLANE (gambar di kertas/whiteboard, lampirkan)
|
||
Lanes: _________ | _________ | _________ | _________
|
||
```
|
||
|
||
---
|
||
|
||
## 10.10 Peta Konsep
|
||
|
||
### Gambar 10.2 — Peta Konsep Pemodelan Proses Bisnis
|
||
|
||
```mermaid
|
||
mindmap
|
||
root((Pemodelan Proses Bisnis))
|
||
Notasi & Tools
|
||
Flowchart sederhana
|
||
Swimlane Diagram
|
||
BPMN dasar 4 simbol
|
||
Value Stream Mapping
|
||
Analisis AS-IS
|
||
Dokumentasi proses nyata
|
||
Wawancara + observasi
|
||
Identifikasi bottleneck
|
||
Redundansi informasi
|
||
Non-value-adding 30-40%
|
||
Desain TO-BE
|
||
Eliminate waste
|
||
Automate repetitif
|
||
Integrate lintas-fungsi
|
||
Enable visibility
|
||
Anti-pattern
|
||
Paving the cow path
|
||
Model di atas kertas saja
|
||
Skip AS-IS langsung TO-BE
|
||
Kaitan
|
||
Input: Kebutuhan Info Bab 9
|
||
Output: Spesifikasi SI Bab 11
|
||
Continuous improvement
|
||
```
|
||
|
||
---
|
||
|
||
## 10.11 Rangkuman
|
||
|
||
**Poin-poin Penting:**
|
||
|
||
1. Proses bisnis yang tidak divisualisasikan tidak bisa diperbaiki — ketika 5 orang diminta menggambar proses yang sama, hasilnya 5 diagram berbeda. Visualisasi mengubah asumsi individual menjadi pemahaman bersama.
|
||
|
||
2. *Swimlane diagram* adalah alat paling intuitif bagi manajer: menunjukkan siapa, apa, dan kapan secara simultan. Setiap *handoff* lintas-*lane* adalah titik rawan kehilangan informasi.
|
||
|
||
3. BPMN lengkap memang teknis, tetapi manajer cukup menguasai 4 simbol dasar (*event*, *task*, *gateway*, *flow*) untuk berkomunikasi efektif dengan tim teknis dan memvalidasi model proses.
|
||
|
||
4. AS-IS harus memetakan realitas — bukan SOP resmi yang mungkin sudah ketinggalan zaman. "*Shadow process*" yang dilakukan karyawan sebagai *workaround* sering kali lebih informatif daripada dokumen formal.
|
||
|
||
5. Rata-rata proses bisnis mengandung 30–40% aktivitas *non-value-adding* (Dumas et al., 2021). Pemodelan proses mengungkap *hidden waste* ini — seperti kasus BPR di mana 79% waktu proses kredit tidak menambah nilai.
|
||
|
||
6. SI harus dirancang untuk mendukung proses TO-BE, bukan mengotomasi proses AS-IS yang sudah rusak. "*Paving the cow path*" — mengotomasi proses yang buruk — hanya membuat kesalahan berjalan lebih cepat.
|
||
|
||
---
|
||
|
||
**Menuju Bab 11:**
|
||
|
||
Proses bisnis TO-BE sudah dirancang — *bottleneck* diidentifikasi, aktivitas *non-value-adding* dieliminasi, dan alur informasi dipetakan. Tetapi model proses belum menjawab pertanyaan teknis: *input* apa yang dibutuhkan SI, bagaimana SI memproses data, dan *output* apa yang dihasilkan? Bab 11 membahas perancangan konseptual SI — menerjemahkan model proses dan kebutuhan informasi menjadi arsitektur SI yang bisa dipahami baik oleh manajer maupun tim teknis.
|
||
|
||
---
|
||
|
||
*"Proses bisnis yang tidak divisualisasikan adalah proses yang tidak bisa diperbaiki — karena masalah yang tidak terlihat tidak akan pernah diperbaiki."*
|
||
|
||
---
|
||
|
||
## 10.12 Latihan & Refleksi
|
||
|
||
### Pertanyaan Diagnostik
|
||
|
||
Tim proyek langsung menyusun model proses baru tanpa terlebih dahulu memetakan keputusan, aktor, *handoff*, *bottleneck*, dan pemborosan pada proses lama. Analisis risiko pendekatan tersebut, artefak yang seharusnya dihasilkan dari analisis proses yang baik, dan cara model proses digunakan untuk membedakan masalah yang memerlukan redesain proses, integrasi data, atau otomasi.
|
||
|
||
### Pertanyaan Reflektif
|
||
|
||
1. Pilih satu proses di organisasi yang Anda kenal yang melibatkan minimal 3 departemen. Apakah ada dokumentasi resminya? Jika ya — apakah dokumentasi itu masih akurat mencerminkan realitas?
|
||
|
||
2. Berikan contoh "*paving the cow path*" — sebuah proses yang diotomasi padahal seharusnya diubah terlebih dahulu. Apa dampaknya? Apa yang seharusnya dilakukan berbeda?
|
||
|
||
3. Mengapa Toyota menjadikan visualisasi proses sebagai budaya (aktivitas mingguan), bukan proyek (*one-time exercise*)? Apa pelajarannya bagi organisasi di Indonesia yang cenderung memperlakukan pemodelan proses sebagai "dokumen proyek SI"?
|
||
|
||
### Latihan Artefak
|
||
|
||
**Latihan 10.1 — *Worksheet* Diagram AS-IS (Template A.10)**
|
||
|
||
Gunakan Template A.10 untuk memodelkan satu proses bisnis sederhana (5–8 aktivitas) yang Anda kenal di organisasi nyata — kampus, tempat kerja, atau organisasi kemahasiswaan.
|
||
|
||
Langkah:
|
||
1. Pilih satu proses yang melibatkan minimal 2 aktor (misalnya: proses pengajuan surat keterangan, proses peminjaman buku perpustakaan, proses pengajuan cuti)
|
||
2. Isi bagian A–D secara lengkap: identifikasi proses, daftar aktivitas per langkah, identifikasi masalah, dan ringkasan analisis
|
||
3. Tandai setiap aktivitas sebagai *value-adding* atau *non-value-adding*
|
||
4. Identifikasi minimal 2 *bottleneck* dan 1 redundansi data
|
||
5. Sketsa *swimlane diagram* di kertas atau *whiteboard*, kemudian lampirkan
|
||
|
||
**Kriteria output yang baik:**
|
||
- Proses nyata dari organisasi yang bisa diobservasi — bukan hipotetis
|
||
- Aktivitas spesifik dan dapat diobservasi (bukan abstrak seperti "koordinasi")
|
||
- Penilaian *value-adding* / *non-value-adding* realistis dan bisa dijustifikasi
|
||
- *Bottleneck* didukung oleh estimasi waktu yang masuk akal
|
||
|
||
*Output Artefak 10.1 menjadi input untuk perancangan konseptual SI di Bab 11.*
|
||
|
||
---
|
||
|
||
## Referensi
|
||
|
||
Bortoluzzi, G., Kadic-Maglajlic, S., & Balboni, B. (2022). Facing the challenges of digital transformation in manufacturing. *Journal of Business Research*, *140*, 209–219.
|
||
|
||
Dumas, M., La Rosa, M., Mendling, J., & Reijers, H. A. (2021). *Fundamentals of Business Process Management* (3rd ed.). Springer.
|
||
|
||
Hammer, M., & Champy, J. (1993). *Reengineering the corporation*. HarperBusiness.
|
||
|
||
Laudon, K. C., & Laudon, J. P. (2022). *Management information systems* (17th ed.). Pearson.
|
||
|
||
Ohno, T. (1988). *Toyota Production System: Beyond large-scale production*. Productivity Press.
|
||
|
||
Rother, M., & Shook, J. (2003). *Learning to see: Value stream mapping*. Lean Enterprise Institute.
|
||
|
||
Satzinger, J. W., Jackson, R. B., & Burd, S. D. (2022). *Systems analysis and design in a changing world* (8th ed.). Cengage Learning.
|
||
|
||
White, S. A. (2004). *Introduction to BPMN*. IBM Corporation.
|