RPS minggu 11 · 2x50 menit

Desain Proses dan Otomasi Operasi

Pertemuan 10 — Manajemen Operasi dan Teknologi

Dari peta proses ke keputusan otomasi: kapan meredesain, kapan RPA/AI layak diinvestasikan, dan bagaimana mengelola risiko transformasi — dengan lensa pengambil keputusan, bukan sekadar diagram alur.

Bagian 1 — Desain Proses Tingkat Lanjut

Dari Pemetaan ke Keputusan Struktur Proses

Pertanyaan diskusi: Jika Anda memimpin unit operasi hari ini, proses mana yang paling butuh didesain ulang total — bukan sekadar diperbaiki sedikit demi sedikit?

Matriks Volume-Variasi: Memilih Tipe Proses

Hayes & Wheelwright (1979) memetakan tipe proses sepanjang sumbu volume dan variasi produk/layanan — pilihan ini menentukan struktur biaya, fleksibilitas, dan kelayakan otomasi.

Semakin ke kanan-bawah (volume tinggi, variasi rendah) — semakin layak proses distandardisasi dan menjadi kandidat otomasi penuh.

Service Blueprint Tingkat Lanjut: Garis Interaksi & Visibilitas

Apa yang Berubah dari Peta Proses Dasar

Garis interaksi memisahkan aksi pelanggan dari aksi penyedia — titik kegagalan (fail point) paling sering muncul di sini.
Garis visibilitas memisahkan front-stage (dilihat pelanggan) dari back-stage (proses tak terlihat, kandidat otomasi tersembunyi).
Evidence fisik & digital dipetakan per tahap — menentukan di mana pengalaman pelanggan rawan terganggu saat proses diotomasi.

Implikasi Keputusan Manajerial

Otomasi di back-stage (verifikasi dokumen, scoring) relatif aman — pelanggan tidak merasakan langsung.
Otomasi di front-stage (chatbot, self-service kiosk) mengubah persepsi kualitas layanan — perlu uji penerimaan pelanggan.
Blueprint jadi dasar objektif memilih tahap mana yang diotomasi lebih dulu, bukan tebakan intuitif tim IT.

Mini-Kasus: Redesain Proses Onboarding Nasabah Digital

Sebuah bank digital nasional (skala Bank Jago/BCA Digital) memutuskan meredesain proses pembukaan rekening dari 3 hari kerja manual menjadi target di bawah 10 menit sepenuhnya digital.

Keputusan Struktural

Hapus verifikasi cabang fisik, ganti dengan e-KYC biometrik

Trade-off Diterima

Risiko fraud identitas naik → butuh lapisan deteksi tambahan

Kepatuhan Regulasi

e-KYC OJK 12/2021 & UU PDP — konsen data eksplisit

Hitung dari Nol: Kapasitas Proses & Titik Bottleneck

Proses e-KYC nasabah digital terdiri atas 4 tahap berurutan dengan sumber daya dan waktu proses berbeda (ilustrasi angka untuk latihan kelas, kerangka Cachon & Terwiesch).

Langkah	Perhitungan	Nilai
Tahap 1 — Verifikasi dokumen	1 sistem ÷ 2 menit/nasabah × 60 menit	30 nasabah/jam
Tahap 2 — Verifikasi wajah (liveness)	2 server ÷ 3 menit/nasabah × 60 menit	40 nasabah/jam
Tahap 3 — Credit scoring otomatis	1 mesin ÷ 5 menit/nasabah × 60 menit	12 nasabah/jam
Tahap 4 — Approval manual petugas	2 petugas ÷ 8 menit/nasabah × 60 menit	15 nasabah/jam
Flow time total (serial)	2 + 3 + 5 + 8 menit	18 menit/nasabah

Kapasitas Proses = Bottleneck

12/jam

Tahap 3 (credit scoring) adalah bottleneck — kapasitas terendah di antara 4 tahap. Menambah petugas di Tahap 4 TIDAK menaikkan output selama Tahap 3 tidak ditambah kapasitas.

Bagian 2 — Otomasi Operasi

Kapan Otomasi Layak Diinvestasikan?

Pertanyaan diskusi: Proses apa di organisasi Anda yang paling "matang" untuk diotomasi — dan apa yang selama ini menahan keputusan investasinya?

Spektrum Otomasi: dari RPA sampai Cobot

Otomasi bergerak sepanjang spektrum kompleksitas keputusan — semakin tinggi tingkat penilaian (judgment) yang dibutuhkan, semakin mahal dan berisiko otomasi penuhnya.

Tingkat	Teknologi	Contoh Penerapan
1. Rule-based	RPA (Robotic Process Automation) — glosarium: bot software meniru klik/input manusia di aplikasi digital	Rekonsiliasi laporan keuangan bulanan
2. Cognitive	AI/ML (machine learning) untuk klasifikasi & prediksi	Credit scoring, deteksi fraud transaksi
3. Fisik kolaboratif	Cobot — glosarium: robot kolaboratif yang bekerja berdampingan dengan manusia tanpa pagar pengaman	Perakitan komponen di lini otomotif
4. Otonom penuh	Robot mobile otonom (AMR) & digital twin	Gudang fulfillment e-commerce skala besar

Kerangka Keputusan: Automate, Outsource, atau Pertahankan Manual?

Sebelum berinvestasi otomasi, manajer operasi perlu menguji proses lewat rubrik analisis berjenjang — bukan mengikuti tren teknologi semata.

Langkah Analisis	Pertanyaan Kunci	Implikasi
1. Kompleksitas keputusan	Apakah proses rule-based atau butuh judgment manusia?	Rule-based → kandidat kuat RPA/AI
2. Volume & frekuensi	Apakah transaksi berulang dalam volume tinggi?	Volume rendah → ROI otomasi sulit tercapai
3. Stabilitas proses	Seberapa sering aturan/prosedur berubah?	Proses sering berubah → tunda otomasi penuh
4. Kelayakan finansial	Apakah ROI & payback lebih baik dibanding outsourcing BPO?	Bandingkan dengan biaya vendor eksternal
5. Risiko kepatuhan	Apakah data sensitif terlibat (OJK, UU PDP)?	Risiko tinggi → butuh mitigasi tata kelola data

Kesimpulan Rubrik

Otomasi penuh layak HANYA jika proses stabil, bervolume tinggi, ROI positif melampaui opsi outsourcing, dan risiko kepatuhan dapat dikelola — bila salah satu syarat gagal, pertimbangkan otomasi parsial atau outsourcing.

Mini-Kasus: Otomasi Gudang Fulfillment E-Commerce

Sebuah marketplace nasional (skala Tokopedia/JD.ID) mengotomasi proses picking & packing gudang dengan robot mobile otonom (AMR) untuk menghadapi lonjakan pesanan harbolnas.

Keputusan yang Diambil Manajemen

AMR dipilih di atas conveyor tetap karena fleksibilitas layout gudang yang sering berubah.
Petugas manusia dipertahankan untuk item fragile & verifikasi kualitas akhir — otomasi parsial, bukan penuh.
Dynamic Capabilities (Teece, 1997) relevan: kapabilitas beradaptasi cepat saat lonjakan permintaan musiman.

Tantangan Implementasi

Integrasi AMR dengan sistem manajemen gudang (WMS) lama butuh waktu 6 bulan lebih dari rencana.
Pelatihan ulang staf gudang menjadi operator/supervisor robot, bukan sekadar picker manual.
Downtime robot saat listrik/jaringan gudang tidak stabil — perlu mitigasi cadangan manual.

Hitung dari Nol: ROI & Payback Period Otomasi RPA

Sebuah perusahaan mengotomasi proses rekonsiliasi keuangan bulanan dengan RPA (ilustrasi angka untuk latihan kelas).

Langkah	Perhitungan	Nilai
1. Biaya manual (sebelum)	3 staf × Rp 12 juta/bulan × 12 bulan	Rp 432 juta/tahun
2. Biaya setelah otomasi	(1 staf × Rp12jt × 12bln) + (maintenance RPA Rp8jt × 12bln)	Rp 144jt + Rp 96jt = Rp 240 juta/tahun
3. Penghematan tahunan	Rp 432 juta − Rp 240 juta	Rp 192 juta/tahun
4. Payback period	Investasi Rp 450 juta ÷ Rp 192 juta/tahun	2,34 tahun

ROI 3 Tahun

28%

(Rp192 juta × 3 tahun − Rp450 juta investasi) ÷ Rp450 juta × 100% = Rp126 juta ÷ Rp450 juta = 28%. Payback di bawah 3 tahun dan ROI positif → investasi RPA layak dilanjutkan.

Coba Sendiri: Hitung ROI Otomasi Proses Anda Sendiri

Ubah biaya staf, biaya maintenance sistem, dan investasi awal, lalu amati bagaimana payback period dan ROI otomasi berubah.

Bagian 3 — Reengineering & Risiko Transformasi

Redesain Radikal vs Perbaikan Bertahap

Pertanyaan diskusi: Kapan sebuah organisasi seharusnya memilih reengineering radikal, dan kapan justru perbaikan bertahap (Kaizen) lebih aman?

Business Process Reengineering (BPR): Prinsip Tingkat Lanjut

Prinsip Hammer & Champy (1993)

Redesain dimulai dari output yang diinginkan pelanggan, bukan struktur organisasi yang ada.
Gabungkan beberapa jabatan/tahap menjadi satu proses terintegrasi — hilangkan serah-terima yang tak perlu.
Biarkan pengambil keputusan bekerja di titik proses terjadi, bukan dieskalasi berlapis-lapis.

BPR vs Kaizen: Kapan Memilih yang Mana

BPR radikal: cocok saat organisasi menghadapi krisis kompetitif (mis. disrupsi fintech terhadap bank konvensional).
Kaizen bertahap: cocok saat proses sudah cukup kompetitif, hanya perlu efisiensi inkremental (lihat P8 Lean & Six Sigma).
Risiko BPR jauh lebih tinggi — kegagalan implementasi BPR dilaporkan luas mencapai lebih dari separuh proyek.

Risiko Implementasi Otomasi yang Wajib Dikelola

Perpindahan Tenaga Kerja

Reskilling & redeployment, bukan hanya PHK — mitigasi reputasi & hubungan industrial

Resistensi Perubahan

Kotter's 8-Step Change Model relevan untuk change management otomasi skala besar

Keamanan Siber

Bot RPA & API otomatis memperluas permukaan serangan — audit akses wajib

Studi McKinsey & MIT menemukan mayoritas kegagalan proyek otomasi bersumber dari manajemen perubahan yang lemah, bukan kegagalan teknologi itu sendiri.

Tata Kelola Otomasi: Siapa Bertanggung Jawab?

Proyek otomasi yang berhasil selalu punya pembagian peran yang jelas — bukan hanya "urusan IT".

Peran	Tanggung Jawab Utama	Contoh Keputusan
Process Owner (unit bisnis)	Menentukan aturan bisnis & menyetujui SOP baru	Batas nilai transaksi yang boleh diotomasi penuh
Tim IT/RPA Center of Excellence	Membangun & memelihara bot/AI, memastikan skalabilitas	Standar arsitektur bot lintas divisi
Fungsi Kepatuhan & Risiko	Audit jejak keputusan otomatis, kepatuhan OJK/UU PDP	Menolak otomasi proses berisiko tinggi tanpa mitigasi
SDM & Change Management	Reskilling, komunikasi perubahan peran kerja	Program redeployment staf terdampak

Tanpa process owner yang jelas, proyek otomasi mudah terjebak jadi eksperimen IT yang tidak pernah diadopsi penuh oleh unit bisnis.

Jelaskan bahwa banyak proyek otomasi gagal bukan karena teknologinya tidak bekerja, melainkan karena tidak ada kejelasan siapa pemilik proses yang berhak menyetujui perubahan aturan bisnis di baliknya. Tanyakan kepada mahasiswa yang pernah terlibat proyek RPA atau AI di perusahaan mereka: apakah unit bisnis dilibatkan sejak awal atau otomasi hanya "didorong" dari tim IT tanpa keterlibatan pemilik proses. Ingatkan bahwa fungsi kepatuhan harus punya wewenang menolak otomasi pada proses berisiko tinggi, sekalipun secara teknis sudah siap dijalankan, karena konsekuensi regulasi bisa jauh lebih mahal daripada penghematan operasional. Tutup dengan menegaskan bahwa struktur tata kelola seperti ini menjadi prasyarat sebelum kelompok mengerjakan latihan peta keputusan otomasi pada slide berikutnya.

Latihan Kelompok: Rancang Peta Keputusan Otomasi

Instruksi tugas untuk 20 menit sisa sesi (dilanjutkan sebagai tugas terstruktur).

Langkah Kerja Kelompok (3-4 orang)

Pilih satu proses nyata di organisasi salah satu anggota kelompok (jasa atau manufaktur).
Petakan proses tersebut ke matriks volume-variasi & identifikasi bottleneck-nya.
Terapkan rubrik Automate/Outsource/Manual dari slide sebelumnya — beri skor tiap kriteria.
Hitung estimasi payback period sederhana bila proses tersebut diotomasi.
Siapkan 1 slide ringkasan rekomendasi untuk dipresentasikan singkat minggu depan.

Teknologi Enabler Emerging: Digital Twin & AI Generatif

Digital Twin dalam Desain Proses

Glosarium: replika virtual proses fisik yang disinkronkan data real-time — dipakai mensimulasikan redesain sebelum implementasi nyata.
Mengurangi risiko uji-coba redesain proses langsung di lini produksi/layanan aktif.
Sudah dipakai produsen otomotif Indonesia untuk simulasi ulang tata letak lini perakitan sebelum investasi fisik.

AI Generatif untuk Desain Proses

Membantu menghasilkan opsi alternatif alur kerja dari data historis proses — mempercepat fase ideasi BPR.
Berpotensi menulis draf SOP & skrip RPA otomatis dari deskripsi proses bahasa natural.
Tetap butuh validasi manusia — halusinasi model bisa menghasilkan alur yang tidak sesuai regulasi.

Sintesis: Rantai Keterkaitan Lean, Otomasi, dan Rantai Pasok

Eliminasi pemborosan (Lean) menyiapkan proses agar layak diotomasi; proses yang sudah otomatis menjadi fondasi digitalisasi rantai pasok end-to-end minggu depan.

Ringkasan: Peta Keputusan Manajerial Hari Ini

Area Keputusan	Pertanyaan Inti	Alat Bantu
Tipe & struktur proses	Volume & variasi seperti apa yang dihadapi?	Matriks volume-variasi, service blueprint
Kapasitas & bottleneck	Tahap mana yang membatasi output keseluruhan?	Analisis kapasitas per tahap (Cachon-Terwiesch)
Kelayakan otomasi	Apakah proses stabil, bervolume tinggi, ROI positif?	Rubrik Automate/Outsource/Manual
Kedalaman redesain	Radikal (BPR) atau bertahap (Kaizen)?	Prinsip Hammer & Champy vs Lean
Risiko transformasi	Bagaimana mengelola SDM, perubahan, dan keamanan?	Change management, audit keamanan siber

Persiapan Pertemuan 11: Digitalisasi Rantai Pasok (Supply Chain 4.0)

Bacaan & Tugas Sebelum Sesi Berikutnya

Cachon & Terwiesch, Matching Supply with Demand — bab proses & kapasitas (untuk konsolidasi konsep hari ini).
Selesaikan latihan kelompok: peta keputusan otomasi 1 proses nyata, siap dipresentasikan singkat.
Baca sekilas berita tentang inisiatif Supply Chain 4.0 di Indonesia (mis. digitalisasi distribusi Indofood/Unilever) sebagai bahan diskusi pembuka.

Bawa temuan bottleneck dari latihan kelompok hari ini — akan dipakai sebagai titik awal diskusi digitalisasi rantai pasok minggu depan.