Bagaimana Proses Loop Terbuka Mengganggu Arus Informasi dalam Bisnis

Saya telah melakukan cukup banyak rekayasa ulang proses bisnis selama karir saya, dan satu-satunya masalah terbesar yang saya temukan selalu sama: proses bisnis loop terbuka. Proses loop terbuka sebagian besar terjadi karena tanggung jawab dibagi di banyak orang dan sering kali di beberapa departemen. Aliran informasi yang dimulai di R&D dengan permintaan untuk peralatan baru dapat berjalan melalui Keuangan dan Pembelian sebelum keluar dari batas organisasi ke Vendor (di mana ia akan melewati beberapa departemen secara bergantian), dan akhirnya kembali ke Penerimaan dan , dengan keberuntungan, grup R&D yang memprakarsai aliran tersebut.

Pada setiap langkah, ada kemungkinan komunikasi terganggu, dan manajer proyek perlu mengurangi risiko ini. Jika arus informasi yang dibangun ke dalam proses bisnis tidak terstruktur secara eksplisit untuk menangkap dan kemudian menangani pengecualian apa pun, kegagalan tidak akan terdeteksi sampai lama kemudian atau mungkin tidak sama sekali. Sementara beberapa kegagalan arus informasi hanya mengakibatkan item yang relatif tidak penting tidak dipesan atau dikirimkan dengan benar, kegagalan lainnya dapat menghabiskan banyak uang organisasi atau menyebabkan penundaan pada kegiatan misi-kritis.

Loop Terbuka Dapat Menghabiskan Jutaan Dolar

Untuk mengilustrasikan poinnya, pertama-tama saya akan berbicara tentang organisasi farmasi besar yang membayar pajak atas ratusan juta dolar peralatan yang tidak dapat dilacak lagi dan ingin menghapus pengeluaran yang tidak perlu ini. Proyek kami menemukan banyak kelemahan proses mendasar, yang semuanya menambahkan hingga puluhan juta dolar pajak yang tidak perlu per tahun dan lebih banyak lagi yang dihabiskan untuk memesan barang yang sama berkali-kali karena kesalahan.

Komunikasi Satu Arah Antar Area Tanggung Jawab

Seperti semua organisasi besar, tanggung jawab berada dalam silo. Seseorang di Manufaktur membutuhkan peralatan X, jadi mereka memberi tahu Keuangan, dan pesanan pembelian (PO) dibuat. Pemesanan mengirimkan PO ke vendor. Hingga satu tahun ke depan, X dikirimkan dan diterima oleh Receiving. Menerima pemberitahuan Manufaktur dan Keuangan. Keuangan mengeluarkan tag aset, yang Menerima tamparan ke X. X ditempatkan ke jalur produksi dan semuanya baik-baik saja.

Kecuali, semuanya tidak baik-baik saja. Sebagai permulaan, karyawan datang dan pergi, dan mudah untuk memesan X tanpa menyadari bahwa orang lain dalam peran yang sama memesan X sembilan bulan yang lalu. Keuangan tidak tahu pesanan ini adalah duplikat: Mereka menganggap Anda hanya membutuhkan X lain, dan PO lain dibuat dan pesanan lain ditempatkan. Selain itu, bahkan jika Anda tidak memesan secara tidak sengaja, Anda dengan cepat kehilangan jejak apa yang Anda miliki.

Mari kita asumsikan X adalah peralatan yang kompleks, mungkin garis pengisi-selesai. Ini terdiri dari 20 komponen utama, yang semuanya akan diganti beberapa kali selama masa pakainya. Tag aset yang ditampar sembarangan ke salah satu bagian X akan hilang karena keausan. Lebih buruk lagi, tag aset bahkan mungkin tidak diterapkan karena tidak mencapai Penerimaan tepat waktu. Setelah itu, tidak ada yang tahu cara melacak X, dan karena itu tidak tahu cara menonaktifkannya di akhir masa pakainya. Dari perspektif pajak, X masih merupakan item kena pajak yang berfungsi.

Selama 20+ tahun, ini akan mulai melukai garis bawah dengan cara yang tidak signifikan. Selain itu, Keuangan menggunakan satu bagian dari sistem ERP mereka dengan satu set penunjuk aset, sementara Manufaktur menggunakan modul ERP yang benar-benar terpisah dengan set penunjuk aset yang berbeda. Pada akhir tahun, tidak ada yang bisa mendamaikan dua set angka, dan auditor mempertanyakan mengapa Anda memiliki perbedaan puluhan atau ratusan juta dolar mengenai peralatan modal Anda.

Ini adalah masalah klasik yang timbul dari serangkaian proses bisnis loop terbuka. Loop terbuka adalah saat Anda tidak membangun titik konfirmasi eksplisit di sepanjang garis alur proses. Dalam contoh di atas, ada begitu banyak proses loop terbuka sehingga kegagalan dijamin.

Menciptakan Arus Informasi Dua Arah

Inilah cara kami mengatasi masalah tersebut. Kami memodelkan setiap aliran proses yang signifikan dari awal hingga akhir. Kami mengidentifikasi semua loop terbuka. Kemudian kami merancang cara sederhana untuk menutup loop tersebut, satu per satu, mulai dari awal.

Langkah pertama

Manufaktur membutuhkan X sehingga mereka meminta Keuangan untuk membuka PO. Keuangan sekarang memeriksa dengan Manufaktur untuk mengonfirmasi, memberikan rincian pesanan sebelumnya untuk X kembali 24 bulan. Duplikasi pesanan yang tidak disengaja dapat dihindari.

Langkah Kedua

Manufaktur menyediakan Keuangan dengan rincian komponen X yang akan diganti selama masa tugas. Keuangan membuat tag aset untuk setiap komponen dan mengonfirmasi dengan Manufaktur. Kedua modul ERP diisi dengan tag aset yang cocok per komponen, memungkinkan pelacakan di seluruh siklus hidup aset.

Langkah ketiga

Menerima memberitahu Keuangan, yang memberitahu Manufaktur. Penempatan tag aset dilakukan oleh pihak yang bertanggung jawab dari Manufaktur untuk memastikan setiap tag ditempatkan pada komponen yang benar. Semua tag/komponen kemudian dikonfirmasi ulang untuk dua modul ERP.

Langkah Empat

Setiap kali komponen ditukar, Manufaktur menginformasikan Keuangan, dan tag aset baru untuk komponen tersebut dibuat dan ditempatkan pada komponen baru oleh Manufaktur, dan kemudian dikonfirmasi di kedua modul ERP. Keuangan kemudian memulai proses penghapusan komponen lama dari pembukuan sementara Manufaktur menjalani proses penonaktifan Panduan Praktik yang Baik (GMP). Pada akhir dekomisioning, Manufaktur menginformasikan Keuangan sehingga aset dapat diambil dari pembukuan.

Detailnya sedikit lebih kompleks daripada contoh yang disederhanakan ini, tetapi intinya jelas: Pada setiap tahap di sepanjang jalan, ada pemeriksaan dan konfirmasi eksplisit.

Memastikan Tindakan Kontinjensi

Dalam proyek lain, saya diminta untuk membantu perusahaan jasa meningkatkan tingkat kepuasan pelanggannya. Bisnis mereka adalah tentang pemrosesan klaim, dan mereka khawatir bahwa mereka gagal memenangkan penawaran. Selain itu, dalam tawaran mereka yang menang, ketidakpuasan berikutnya dari klien berarti rasio akun mereka yang hilang terlalu tinggi.

Hanya butuh beberapa hari untuk mengidentifikasi inti masalahnya, yang sekali lagi merupakan proses loop terbuka. Ketika seorang prospek meminta penawaran, manajer akun akan menggunakan sistem internal mereka untuk mengirimkan garis besar persyaratan klien kepada orang yang bertanggung jawab untuk menyusun penawaran. Pembuat tawaran kemudian akan membuat tawaran dan meneruskannya ke klien. Mudah-mudahan, klien pada akhirnya akan merespons, biasanya dengan modifikasi yang diinginkan, yang akan dibuat oleh pembuat tawaran ke versi berikutnya. Pada titik tertentu, klien akan menerima tawaran, dan akun klien baru akan dibuat oleh Akuntansi, faktur diajukan, dan tim orientasi diberi pengarahan.

Masalah pertama adalah tidak ada konfirmasi eksplisit dari pembuat tawaran kepada pengelola akun, sehingga terkadang tawaran tidak dibuat dan dikirim tepat waktu, dan tidak ada yang mengetahuinya. Ini dimungkinkan karena sistem internal tidak memiliki bidang untuk menunjukkan tanggal jatuh tempo untuk tawaran, dan karena pembuat tawaran terus-menerus bekerja terlalu keras, ini menyebabkan tawaran yang diajukan terlambat. Karena arus informasi yang buruk dalam bisnis, situasi ini tidak pernah muncul.

Setelah itu, modifikasi pada tawaran tidak dikirimkan ke pengelola akun. Ini penting karena manajer akunlah yang memberi pengarahan kepada tim orientasi ketika klien akhirnya menandatangani di garis putus-putus. Sering kali ringkasan tersebut didasarkan pada pemahaman awal manajer akun daripada pada tawaran yang sebenarnya telah diterima klien.

Setelah pertunangan dimulai, dokumen klien akan tiba dan diteruskan ke anggota tim mana pun di kumpulan pemrosesan yang telah ditugaskan minggu itu untuk menanganinya. Karena tidak ada konfirmasi penerimaan yang jelas, ada kemungkinan dokumen hilang tanpa diketahui siapa pun, sampai klien mulai bertanya mengapa mereka tidak menerima hasil pekerjaan pemrosesan.

Ketika dokumen yang diproses dikirim kembali ke klien, tidak ada konfirmasi setelah diterima, sehingga dokumen yang hilang tidak dapat dilihat sampai seseorang di suatu tempat mulai mengeluh tentang ketidakhadiran mereka.

Konfirmasi Acara Utama

Pada setiap langkah proses penawaran, kami membangun konfirmasi eksplisit. Kami membuat solusi untuk kekurangan sistem sehingga semua informasi penting ditangkap, termasuk tanggal yang diperlukan oleh dan modifikasi tawaran berikutnya. Kami menerapkan pemeriksaan dan konfirmasi eksplisit untuk semua aliran informasi dalam bisnis di dalam perusahaan, dan antara perusahaan dan klien.

Misalnya, ketika klien mengirimkan paket dokumen, mereka sekarang akan mengirim email ke manajer akun klien untuk memberi tahu mereka. Manajer akun klien akan meneruskan ini ke pihak yang bertanggung jawab dalam pemrosesan klaim. Jika dokumen tidak diterima dalam waktu tiga hari, peringatan akan dinaikkan. Ketika dokumen diterima, sebuah email masuk ke klien yang mengonfirmasi penerimaan. Hal sebaliknya juga terjadi ketika perusahaan mengirimkan kembali dokumen yang telah diproses ke klien.

Karena sebagian besar klien menggunakan surat AS untuk mengacak dokumen hardcopy bolak-balik, proses loop tertutup menggunakan pemeriksaan eksplisit pada setiap langkah berarti bahwa setiap dokumen yang hilang dapat dengan cepat diidentifikasi dan langkah-langkah diambil untuk memperbaiki situasi.

Prosedur Penanganan Pengecualian Desain

Untuk melihat bagaimana prosedur penanganan pengecualian dapat dibangun dengan cara yang cukup ringan namun efektif, kita akan melihat contoh dunia nyata lain yang saya temui dalam karir saya ketika saya menjadi CIO dari sebuah organisasi penelitian ilmiah yang berfokus pada penyelidikan penyebab penuaan dan pemicu penyakit terkait usia.

Semua lembaga penelitian yang didanai NIH berisi banyak laboratorium individu, masing-masing dijalankan oleh Penyelidik Utama (PI) dan dikelola oleh berbagai ilmuwan bawahan dan pasca-dokter. Pada titik tertentu, PI memerlukan baki reagen multiruang baru, jadi mereka meminta salah satu post-docs untuk membuat permintaan yang diperlukan. Post-doc membuat permintaan dan mengirimkannya melalui email ke Finance untuk meminta PO diajukan, cc ke PI untuk memastikan PI mengetahui bahwa permintaan telah dikirim. Sementara itu, PI memiliki pemberitahuan kalender otomatis untuk mengingatkan mereka untuk memeriksa status permintaan jika mereka belum menerima konfirmasi pada tanggal tertentu. Ini memastikan mekanisme failsafe jika post-doc lupa membuat atau mengirim permintaan yang diperlukan.

Sekarang post-doc juga memiliki pemberitahuan kalender otomatis untuk check-in dengan Finance jika mereka tidak menerima konfirmasi PO dinaikkan dalam jangka waktu tertentu. Ketika Keuangan menaikkan PO, post-doc menerima email konfirmasi bahwa itu telah dikirim ke vendor, dan post-doc meneruskan konfirmasi ini ke PI.

Pada tahap ini, baik PI atau post-doc menyetel pemberitahuan kalender otomatis lainnya untuk memastikan bahwa jika tidak ada yang terdengar dari vendor dalam jangka waktu tertentu, seseorang memeriksa dengan vendor untuk memastikan penerimaan PO dan pengiriman peralatan yang telah dipesan.

Dengan asumsi vendor mengakui penerimaan PO dan mengirimkan item bersama dengan pemberitahuan pengiriman, ini diteruskan ke PI atau post-doc. Mereka kemudian menetapkan pemberitahuan kalender terakhir selama tiga hari setelah tanggal penerimaan yang dijadwalkan untuk memastikan bahwa jika item tidak muncul, mereka tahu untuk menghubungi vendor untuk melacak apa yang terjadi dan mengirimkan item dengan benar. Jika item tersebut tiba sesuai rencana, post-doc akan memberi tahu Finance, dan jika organisasi menggunakan tag aset, maka rangkaian proses ini dapat dimulai.

Pada setiap langkah, ada konfirmasi eksplisit yang diperlukan dan sub-proses tersedia untuk memastikan tindakan perbaikan terjadi jika aliran proses utama terganggu. Tidak ada yang dibiarkan menggantung, tidak dikonfirmasi, atau tidak didukung. Tidak ada tindakan ad-hoc yang diperlukan karena semua orang tahu apa yang diperlukan dan apa yang harus dilakukan jika terjadi kesalahan.

Belajar Membuat Proses Loop Tertutup dari SQL

Inti dari proses yang baik sangat mirip dengan cara database relasional berbasis SQL dirancang untuk memastikan konsistensi transaksional. Setiap tindakan harus dikonfirmasi agar dapat dianggap selesai. Semua komunikasi dua arah membutuhkan konfirmasi eksplisit yang dibangun sebagai bagian dari proses, dan proses bawahan dikembangkan untuk memastikan bahwa jika konfirmasi tidak diterima, tindakan yang benar diambil. Manajer proyek yang sukses harus menciptakan proses loop tertutup untuk meningkatkan aliran informasi dalam bisnis dan menghemat banyak waktu dan uang organisasi.