Analisa Proses Bisnis – Pertemuan 10 – Materi Perkuliahan

Gede Surya Mahendra - Home

Analisa Proses Bisnis – Pertemuan 10 – Materi Perkuliahan

Stiki Logo - Short

Mata Kuliah : Analisa Proses Bisnis

Kode Mata Kuliah : MKK-209

Program Studi : Teknik Informatika

STIMIK STIKOM Indonesia

PERTEMUAN 10

Untuk tampilan lebih baik, dapat mendownload file PDF pada link yang tersedia

Kemampuan Akhir yang Diharapkan:

Mahasiswa memahami Analisa Proses Bisnis Saat Ini (As-Is)

Bahan Kajian:

  • Analisa proses bisnis saat ini (as- is)
  • Pemodelan dengan document flow diagram

Metode Pembelajaran:

  • Metode inkuiri dengan topik pemodelan proses bisnis dengan document flow diagram

Pengalaman Pembelajaran:

  • Menjabarkan sebuah proses bisnis saat ini dengan menggunakan pemodelan document flow diagram

Kriteria Penilaian dan Indikator:

  • Kemampuan memahami pemodelan proses bisnis saat ini (as-is) dengan document flow diagram.

 

Download File Materi PDF

Download File Slide Perkuliahan PDF 

 

TINJAUAN

  1. Tipe Proses Bisnis
  2. Jenis Analisis Proses Bisnis
  3. Komponen Proses Bisnis
  4. Karakteristik Proses Bisnis
  5. Segmen yang Dilakukan Analisis Proses Bisnis
  6. Ruang Lingkup Analisis Proses Bisnis
  7. Siklus Deming

MATERI

As-Is Proses Model

Setelah organisasi menghargai kegunaan pemodelan proses, kegiatan modeling ‘as-is’ dapat mulai. Titik kritis mengenai modeling as-is adalah lingkup pemodelannya. Seberapa komprehensif model yang harus dibuat? Level of detail apa yang harus mereka gambarkan dalam menggambarkan kegiatan perusahaan? Informasi apa yang harus dimasukkan dalam model proses – organisasi unit, orang, tujuan, kelemahan, data, sumber daya, pengetahuan, atau pelanggan, dll? Semua pertanyaan ini hanya dapat dijawab jika tujuan pemodelan didefinisikan dengan jelas.

Tujuan pemodelan proses bisa berbeda-beda. Pemodelan proses meningkatkan transparansi tentang organisasi proses, dengan cara yang sama dengan cara bagan organisasi menggambarkan struktur organisasi. Dalam hal pemodelan proses berlangsung sebagai bagian dari reorganisasi proses, itu lebih penting untuk menyoroti kelemahan dan mengidentifikasi kemungkinan perbaikan. Jika model proses yang digunakan untuk memilih solusi perangkat lunak baru, itu akan berguna untuk melihat bagaimana alternatif solusi perangkat lunak mendukung proses tertentu. Proses model juga dapat memberikan masukan bagi software developer yang mengembangkan perangkat lunak baru berdasarkan spesifikasi dan persyaratan proses bisnis yang berlaku. Selain itu, model proses dapat menyoroti interface untuk pelanggan dan memberikan manfaat untuk proyek Customer Relationship Management.

Pertanyaan dan Jawaban dibawah dapat mendorong Anda untuk berhati-hati dalam mempertimbangkan konsekuensi merancang ‘as-is’ model.:

Perbandingan As-Is Proses Model

Keuntungan Kekurangan
  • Pemahaman yang sama atas permasalahan yang ada
  • Lingkup proyek didefinisikan
  • Terminologi yang sama
  • Mendukung penerimaan untuk proyek (unfreezing)
  • Dasar untuk strategi migrasi terhadap proses didesain ulang
  • Kelengkapan untuk melakan evaluasi terhadap to-be proses
  • Hasil dari analisis proses as-is dapat digunakan sebagai to-be, jika tidak ada atau hanya sedikit perubahan
  • Itu menunjukkan kelemahan dan restriction
  • Proses as-is akan menjadi obsolete setelah proses to-be sudah dirancang atau diimplementasikan
  • Berbahaya karena narrow focused process design (thinking in constraints)
  • Memakan waktu dan biaya

Setelah kick-off proyek dan sebelum dokumentasi yang lebih komprehensif dari proses as-is, pertimbangan yang cermat dari keuntungan dan kerugian dari as-is model sangat diperlukan.

Keuntungan As-Is Proses Model

Manfaat utama dari pemodelan as-is adalah bahwa semua anggota proyek yang terlibat dapat mengembangkan keterampilan komunikasi yang diperlukan selama proses pemodelan, dan memiliki pemahaman yang sama tentang masalah dan terminologi. Desain kolaboratif model memerlukan kesepakatan dalam istilah yang akan digunakan. Ruang lingkup proyek didokumentasikan dalam model proses. Selama pengembangan perbaikan, model as-is berfungsi sebagai semacam patokan dan cek kelengkapan. Bagian atau model selengkap-yang sering dapat digunakan sebagai ‘to-be’ model, jika tidak ada perubahan proses utama yang diperlukan atau mungkin. Akhirnya, deskripsi proses yang ada menyoroti kelemahan, sehingga memberikan potensi perbaikan, tetapi juga mengidentifikasi kendala yang ada.

Kerugian As-Is Proses Model

Kerugian utama dari modelling as-is proses adalah bahaya bahwa tim proyek akan kehilangan kemampuan dalam berfikir ‘out-of-the-box’. Hal ini terjadi ketika tim analis bisnis yang bertanggung jawab dari pemodelan proses terdiri dari orang-orang yang agak berpengalaman yang mewawancarai rekan yang berpengalaman dari berbagai area bisnis. Responden (tim) akan sering mencoba untuk meyakinkan analis bisnis bahwa cara yang ada untuk melakukan bisnis adalah satu-satunya cara dalam kaitannya dengan kendala yang ada karena sejumlah alasan. Pada akhir wawancara akan menjadi sulit untuk melangkah mundur dan menganalisis proses secara obyektif.

Masalah ini adalah alasan mengapa Michael Hammer merekomendasikan melewatkan analisis as-is. Dia menyarankan cara baru dalam memandang perusahaan, dengan cara yang tidak memiliki pengetahuan tentang kendala dan mulai dari awal. Model as-is tidak akan berlaku lagi ketika model to-be sudah dibuat, dan dapat memakan banyak waktu dan biaya.

Peserta dapat berdebat tentang istilah apa yang harus digunakan atau mengapa kasus tertentu tidak digambarkan dalam model. Namun, diskusi tersebut dapat dihindari dengan berfokus pada aturan 80/20. Dengan mengikuti aturan ini, hanya 80% kasus yang akan menjadi pokok perhatian, yaitu skenario yang khas. Dan tidak perlu untuk menjelaskan masing-masing dan setiap kasus yang ditemukan. Selain itu, model proses hanya mencerminkan istilah yang paling populer. Hal ini tidak dapat mempertimbangkan kebutuhan individu peserta tertentu seperti engineers, perwakilan bisnis dan staf IT, yang masing-masing dapat menggunakan terminologi yang berbeda.

Proses Bisnis Frameworks (Business Process Frameworks)

Pemodelan proses as-is dengan cepat akan menjadi tugas yang sangat kompleks karena jumlah model yang dirancang akan bertambah. Untuk itu diperlukan cara untuk menemukan mekanisme yang memadai untuk mengurangi dan mengelola kompleksitas ini. Salah satu cara yang efisien adalah untuk mengembangkan high level ‘Business Process Frameworks’, yang menggambarkan bisnis dan dukungan inti proses perusahaan tertentu. Sebagai level pertama dari proyek pemodelan proses, kerangka bisnis (business frameworks) berfungsi sebagai titik masuk ke semua model yang ada.

Kerangka proses bisnis/business process frameworks dapat digunakan untuk mengkarakterisasi proses bisnis yang berbeda dari suatu perusahaan pada level tertinggi (high level). Warna yang berbeda, misalnya, bisa menunjukkan prioritas yang berbeda mengenai perlunya proses desain dan dapat mengekspresikan tingkat dukungan yang berbeda dari IT. Kerangka proses bisnis menjadi titik pusat akses ke semua model proses.

Langkah-Langkah As-Is Proses Model

Sebelum kita melakukan improvement, langkah awal yang harus kita lakukan adalah mengetahui proses yang sedang berjalan sekarang. Identifikasi proses diawal ini dinamakan Proses As Is. Cara terbaik membuat proses As Is adalah dengan melakukan observasi dan interview langsung user di lapangan (Tips: jangan melihat SOP, karena belum tentu sesuai dengan kenyataan di lapangan). Langkah apa saja yang harus kita lakukan untuk membuat As Is Proses, berikut diantaranya:

1. Lakukan meeting besar awal dengan semua pihak terkait

Meeting ini penting dilakukan untuk mendukung eksistensi kita sewaktu melakukan project. Kita tentunya tidak mau capek sendiri, harus ada Person in Charge, pembagian tugas dan timeline yang jelas terkait project. Pastikan semua pihak datang dalam meeting, jika tidak cari waktu lain yang memungkinkan. Putuskan secara detil peran masing-masing pihak, dan minta diinformasikan kesemua user yang terlibat project ini, supaya kita dilapangan tidak sering ditanya mengenai apa yang kita lakukan, dan menghindari anggapan kita sedang melakukan audit. Jika user nantinya menganggap kita sedang melakukan audit, maka mereka akan defence duluan, sehingga sulit nantinya diajak brainstorming. Hasil yang harus didapatkan pada meeting awal ini adalah penjelasan mengenai project yang akan dijalankan, structure organisasi project & jobdesk, timeline project dan gentlemen agreement antara atasan langsung.

2. Lakukan Observasi lapangan

Observasi lapangan ini, bisa berupa melihat aktivitas user di lapangan, interview user, pengumpulan data(penjualan, pembelian dan apapun itu yang berhubungan dengan user, dan kalau bisa data yang didapatkan berupa excell). Jika perlu bawalah stopwatch, kamera digital, decorder dan alat lain yang dianggap bisa membantu. Lakukan observasi sesuai timeline yang sudah ditetapkan dan observasi ini tidak dalam sekali datang, tapi bisa berkali-kali sampai kita merasa puas dengan pengumpulan data yang dibutuhkan. Observasi penting dilakukan supaya kita bisa mendapatkan proses yang terukur, baik dari sisi biaya, waktu, produktivitas dan lain sebagainya. Karena kita tidak dapat mengimprove sesuatu yang tidak bisa terukur.

3. Analisa data

Data yang kita dapat hasil observasi harus kita analisa, dan kita tampilkan dengan bentuk yang user friendly dan informatif. Pengolahan data softcopy, biasanya menggunakan aplikasi Microsoft Excell, maka diperlukan pemahaman yang cukup terkait rumus excell, tampilan tabel, grafik dan sebagainya. Untuk data dari hasil interview dan foto, susunlah data tersebut dalam bentuk alur proses yang dilakukan user. Lakuka interview dengan user terkait alur proses as is yang dibuat dengan user, sampai user bersepakat dengan alur dan leadtime yang kita buat. Carilah sumber-sumber yang berhubungan dengan proses yang sedang kita olah, sebagai data pembanding.

4. Buat Alur As Is Proses

Setelah analisa selesai, buat alur proses as is(bisa di Excell atau power point). Penulis biasa membuat alur as is di power point, supaya lebih enak dilihat dan gampang untuk ditampilkan. Alur proses dibuat dari pojok kiri atas dan berakhir di kanan tabel.

5. Meeting proses As Is

Setelah pembuatan alur proses As Is selesai dibuat, lakukan meeting dengan seluruh tim project untuk menyamakan persepsi. Pancing tanya jawab di forum, dan pastikan semua bagian yang ada di alur proses hadir. Jika semua sudah sepakat dan persepsi mengenai improvement apa yang akan dilakukan sudah sama, baru kita akan lakukan pembuatan To Be proses. Jangan lupa buat notulen untuk setiap meeting yang dilakukan.

Daftar Pustaka:

  • Kenneth E. Kendall. 2007. Analisis Dan Perancangan Sistem Edisi Kelima Jilid 1. Indeks.
  • Mathias Weske. 2007. Business Process Management (Concept, Language, Architectures). Springer
  • Martin Owen & Jog Raj. 2003. BPMN and Business Process Management. Popkin Software

 40 total views,  2 views today

Tags: ,

Leave a Reply

Your email address will not be published. Required fields are marked *