Coding My Ideas

Kemarin2.0 ada diskusi hangat dengan seorang konsultan bisnis. Dengan panjang lebar dia menceritakan betapa pentingnya mendesain proses bisnis sebelum membuat aplikasi perangkat lunak. Dia mengecam banyak perusahaan yang gagal gara2.0 tergesa-gesa membeli solusi IT padahal proses bisnis-nya belum dirancang dengan baik. Salah satu yang dikecam, ya, kantor saya. Mungkin gara2.0 kita ga jadi pake jasa konsultan itu kali ya…hehe…

Well, kantor saya memang memutuskan terjun langsung ke solusi IT, melawan keyakinan sang konsultan. “Sudahlah, kita ikutin best practice yang ada aplikasi aja. Waktu kita ga banyak” kata bos saya. Saya manut aja..guk angguk angguk guk…(mengutip lagu Project Pop).

Apakah konsultan itu salah? sama sekali tidak. Saya termasuk yang percaya proses bisnis yang ngawur akan menghasilkan aplikasi yang ngawur. Berarti bos saya salah dong? Hmm..rasanya ga juga. Karena saya pernah lihat beberapa perusahaan yang sukses dengan cara ala bos saya itu.

“Menurut kamu gimana?” tanya si bos sekonyong-konyong. Weleh, sambil gelagapan, saya ngecap:

“Klo menurut saya, jika pun harus segera implementasi solusi IT maka buatlah sistem dengan arsitektur yang fleksibel. Maksudnya fleksibel, kapan2.0 proses bisnis perusahaan harus diubah, maka sistem itu harus bisa diubah dengan mudah. Saya pikir proses bisnis itu suatu perjalanan, trial-and-error, harus terus diadaptasi sesuai dengan kondisi persaingan yang dihadapi perusahaan. Ga cukup dengan sekali rancang langsung optimal di awal saja seperti keyakinan sang konsultan.
Best practice? hmm, bisa aja ga cocok untuk saat ini karena beda kultur lah, market landscape lah etc. Klo pun cocok, sampei berapa lama best practice itu berlaku? suatu proses bisnis yang tergolong best practice saat ini, jika dikemudian hari diamalkan banyak kompetitor..ya ga guna, alias kudu rancang proses bisnis inovatif lain. Contoh: ATM, di awal2.0 BCA bisa pake itu untuk memimpin pasar, karena inovatif . Tapi ketika semua bank pake ATM, ya, sekarang ATM jadi expense biasa aja. Just to stay in the race…Balik soal sistem, idealnya sistem itu cukup fleksibel sampei bukan orang IT pun bisa mengubah proses bisnis yang ada di sistem”.

“Hah…mana bisa?” tanya bos saya. Saya langsung merespon : “Mmm…bisa pak, kata teman saya ada engine workflow dan business rules yang open source. Namanya jBPM dan Drools. Keduanya dari JBoss. Drools jadi otaknya, jBPM jadi eksekutor untuk otomatisasinya“.

“Hmm..OK. You take the lead to check their feasibility“ujar si bos. Waduhh…ada yang ngerti pernah make jBPM dan Drools?

update from googling:

[1] Why Java Developers hate (j)BPM?

… BPM suites make programming boring. They force you to use point-and-click and drag-and-drop tools to design your process diagrams, data models and forms. What’s worse, they actually encourage Business People to model processes and design forms on their own…

[2] Introduction to BPM

…The first step in managing a process is to know what the process actually is. This includes the steps that are done by people and the steps that are done by machines. I once found it necessary to gather a dozen people in a room to find out what everyone thought the process was, and then later discovered the process wasn’t at all what they thought it was. Big companies like to spend lots of money to diagram their processes… which they then file away for five years until they do it again.

The second step in managing a process is to gather metrics… How long (on average) does it take for each step of the process to take? How often are steps repeated (presumably due to errors)?

The third step and fourth steps in managing a process are to analyze and actively manage the process. Use the metrics that you’ve gathered to analyze process performance, develop a better process, try it out and start all over again. That’s Continuous Process Improvement.

All good BPM suites provide infrastructure support for all the steps needed to manage processes…