Diterjemahkan dari bahasa Inggris ke bahasa Indonesia - www.onlinedoctranslator.

com

71

Bab 5
Kelincahan Bisnis dan
Kelincahan Proses:
Bagaimana Mereka Berhubungan Satu Sama Lain?

Giorgio Bruno
Politecnico di Torino, Italia

ABSTRAK

Kelincahan adalah fitur penting bagi UKM dan bab ini bermaksud untuk memeriksa apakah dan bagaimana
proses bisnis, seperti yang dipahami saat ini, dapat mempromosikannya. Selama beberapa tahun terakhir
sejumlah sudut pandang telah muncul yang memberikan pengaruh besar pada desain notasi dan bahasa untuk
proses bisnis: mayoritas dari mereka dapat disebut sebagai sudut pandang terpusat, sudut pandang peran,
sudut pandang percakapan, sudut pandang kasus dan yang kooperatif. Sudut pandang ini memberikan tingkat
kelincahan yang berbeda dan kemudian hasil yang bermanfaat dapat diharapkan dari integrasinya, yang
merupakan tujuan dari notasi proof-of-concept, AgileBPN, yang disajikan dalam bab ini. Di AgileBPN, proses
bisnis diatur di sekitar percakapan dan proses peran (mencakup tugas yang berkaitan dengan peran tertentu);
artefak bersama direpresentasikan sebagai objek kooperatif. Notasi diilustrasikan dengan bantuan contoh yang
mengacu pada proses bisnis yang dimaksudkan untuk menangani aplikasi dalam organisasi tertentu.

PENGANTAR konteks bisnis, kelincahan dikaitkan dengan praktik

bisnis pada tingkat yang berbeda (perusahaan,
Kelincahan adalah fitur penting untuk UKM, individu dan kelompok).
karena "ini tidak menerapkan proses standar Di tingkat perusahaan, kelincahan berarti
untuk tingkat seperti perusahaan besar" (Riss, adaptasi dari praktik bisnis saat ini atau
Rickayzen, Maus & van der Aalst, 2005). pengenalan yang baru, dalam menanggapi
Secara umum, kelincahan adalah kemampuan untuk bereaksi kebutuhan pasar baru, inisiatif pesaing atau
terhadap rangsangan dari luar, dengan cepat dan efektif. Di sebuah perubahan peraturan.
Karena praktik bisnis dilakukan melalui
DOI: 10.4018/978-1-60960-463-9.ch005 proses bisnis (Davenport, 1993),

Hak Cipta © 2011, IGI Global. Dilarang menyalin atau mendistribusikan dalam bentuk cetak atau elektronik tanpa izin tertulis dari IGI Global.

pendorong kelincahan perusahaan adalah notasi
ekspresif yang mampu menangkap fitur penting
dari masalah bisnis yang sedang
dipertimbangkan. Karena notasi terdiri dari blok
penyusun yang menangani kelas sub-masalah
tertentu, masalahnya adalah mengidentifikasi
blok penyusun serta mekanisme komposisi yang
paling tepat. Kelincahan dicapai karena blok
pembangun memberikan solusi parsial yang
sudah tersedia, yang dapat diatur dalam urutan
yang dibutuhkan, melalui mekanisme komposisi.
Selama beberapa tahun terakhir, sejumlah sudut
pandang telah muncul yang memberikan pengaruh
besar pada desain notasi dan bahasa untuk proses
bisnis.
Sudut pandang ini mengusulkan cara yang berbeda
untuk mengatur konstituen dasar lingkungan koperasi,
yang merupakan kegiatan operasional, kegiatan
koordinasi dan bidang kerja umum (Schmidt & Simone,
1996). Kegiatan operasional adalah unit kerja yang
dimaksudkan untuk menghasilkan beberapa perubahan
dalam bidang pekerjaan umum yang mendasarinya,
yang merupakan tempat penyimpanan artefak (data dan
dokumen bisnis). Kegiatan koordinasi bertanggung
jawab untuk mengatur kegiatan operasional dalam
urutan yang tepat.
Ketika suatu kegiatan harus dilakukan oleh
seseorang, itu disebut sebagai kegiatan manual atau
tugas; istilah "tugas" akan digunakan dalam bab ini
untuk menunjukkan aktivitas manual. Sebaliknya,
aktivitas otomatis dilakukan oleh layanan eksternal.
Orang-orang yang mengambil bagian dalam suatu
proses disebut sebagai partisipan dalam proses.
Pada awal CSCW (Computer Supported
Cooperative Work), koordinasi diserahkan kepada
pengguna yang mencoba mencapainya melalui
berbagai cara, termasuk database bersama dan
email (Holt, 1985). Kemudian, teknik koordinasi
eksplisit diperkenalkan untuk menghasilkan
proses yang berulang.
Namun, ada perbedaan mencolok antara
sudut pandang yang disebutkan di atas
sejauh mana para peserta dalam proses
bisnis terlibat dalam kegiatan koordinasi.
72
Kelincahan Bisnis dan Kelincahan Proses
Dalam sudut pandang terpusat, di mana efisiensi
adalah tujuan utama, koordinasi dilakukan oleh
proses bisnis melalui elemen aliran kontrol, yang
bertanggung jawab untuk mengatur kegiatan
operasional dalam jalur berurutan, alternatif,
berulang dan bersamaan, sesuai kebutuhan.
Sebuah proses bisnis kemudian seperti master yang
mendistribusikan pekerjaan di antara para peserta.
Ini adalah pendekatan yang kaku di mana, ketika
suatu aktivitas telah selesai, pemilihan aktivitas
berikutnya yang akan dilakukan secara otomatis
dilakukan melalui elemen aliran kontrol.
Notasi dan bahasa terkenal, seperti BPMN
(OMG, 2008) dan BPEL (OASIS, 2007),
mendukung sudut pandang terpusat.
Meskipun secara umum diterima bahwa proses kaku
memberikan kontribusi yang signifikan terhadap pekerjaan
yang berulang dan terstandarisasi (yaitu rutinitas), mereka
tampaknya tidak memadai untuk situasi yang
membutuhkan kerja intensif pengetahuan (Riss, Rickayzen,
Maus & van der Aalst, 2005).
Pekerjaan intensif pengetahuan biasanya dikaitkan
dengan kelincahan individu, yaitu kemampuan peserta
untuk mengambil bagian dalam koordinasi pekerjaan yang
akan dilakukan; mereka melakukannya, dengan secara
mandiri memilih tugas-tugas untuk dilaksanakan, bila
diperlukan, berdasarkan penilaian dan pengalaman mereka.
Sudut pandang percakapan dan sudut pandang
kasus masing-masing mempromosikan kelincahan
individu melalui percakapan dan melalui
penanganan artefak individu.
Sudut pandang percakapan menekankan
percakapan, yang merupakan pola interaksi antara
pasangan peserta. Pola yang terkenal adalah
percakapan untuk tindakan (Winograd, 1987-1988), di
mana dua pihak, yaitu pemohon dan penyedia,
mencapai kesepakatan bersama melalui sejumlah
negosiasi. Sebuah proses bisnis kemudian dapat
digambarkan dalam hal peran dan percakapan antara
peran, peran dan percakapan menjadi blok bangunan
(Dietz, 2006). Secara khusus, blok pembangun peran
adalah entitas majemuk yang mencakup "ruang
tindakan" para peserta yang memainkan peran itu
dalam proses bisnis yang sedang dipertimbangkan.
Kelincahan Bisnis dan Kelincahan Proses
Ruang tindakan ini menunjukkan percakapan yang
mungkin melibatkan para peserta serta tugas-tugas
yang diperlukan untuk mendukung mereka. Kelincahan
dicapai bukan hanya karena percakapan berlangsung
melalui negosiasi tetapi juga karena ruang tindakan
dapat mencakup tugas-tugas opsional selain tugas-
tugas wajib; misalnya, tugas opsional dapat
memungkinkan peserta untuk memulai percakapan
tertentu jika diperlukan.
Sementara percakapan berfokus pada
interaksi dan tindakan terkait, tidak jarang proses
bisnis dimaksudkan untuk menangani siklus
hidup kelas artefak tertentu, seperti pesanan
pembelian atau klaim asuransi.
Sudut pandang kasus (di mana kasus
menunjukkan artefak yang akan ditangani oleh
proses bisnis) mempertimbangkan keadaan
kasus, daripada penyelesaian aktivitas proses,
sebagai pendorong utama evolusi proses (van der
Aalst, Weske & Grünbauer, 2005). Alur kontrol
ternyata jauh lebih sederhana dan kelincahan
dicapai karena peserta memilih tugas untuk
dilakukan berdasarkan keadaan kasus.
Secara tradisional, pengembangan kooperatif dari
artefak bersama, seperti dokumen dan perangkat lunak,
dianggap sebagai bagian dari domain groupware,
karena tidak ada aliran kontrol eksplisit yang harus
ditangani. Pekerjaan terbaru mencakup pengembangan
kolaboratif deskripsi proses berdasarkan sistem wiki
(Neumann & Erol, 2009).
Namun, mengintegrasikan sudut pandang kooperatif
dalam proses bisnis mempromosikan kelincahan di tingkat
kelompok di mana sejumlah peserta dapat dengan cepat
terlibat dalam tindakan kolektif tanpa perlu secara eksplisit
mendefinisikan percakapan atau tugas.
Contohnya adalah persiapan penawaran harga yang
rumit sebagai tanggapan atas permintaan penawaran:
manajer akun yang menerima permintaan penawaran
dapat mengatur dokumen wiki untuk mengumpulkan
saran dari sejumlah penasihat sebelum melanjutkan
dengan finalisasi penawaran.
Notasi tangkas harus dapat mendukung semua sudut
pandang yang disebutkan di atas. Ini bukan tujuan yang
mudah karena beberapa alasan: percakapan dan
penanganan kasus tampaknya merupakan gagasan ortogonal
dan mewakili artefak bersama dalam proses bisnis masih
merupakan masalah terbuka.
Bab ini menyajikan notasi proof-of-concept,
yang disebut AgileBPN (Agile Business Process
Notation), di mana semua sudut pandang yang
disebutkan di atas dibahas; ia melakukannya
dengan bantuan contoh yang beberapa versi
dibahas. Di AgileBPN, proses bisnis diatur di
sekitar percakapan dan proses peran
(mencakup tugas yang berkaitan dengan peran
tertentu); artefak bersama direpresentasikan
sebagai objek kooperatif.
Bab ini disusun sebagai berikut. Bagian 2
menggambarkan sudut pandang pada proses bisnis
secara lebih rinci. Bagian 3 memperkenalkan pola
percakapan, sedangkan bagian 4 menyajikan arsitektur
proses bisnis serta proses peran standar yang tersirat
dalam percakapan. Bagian 5 menjelaskan bagaimana
proses peran dapat menggabungkan dua atau lebih
percakapan. Bagian 6 menunjukkan kasus kelincahan
individu dalam proses peran, sedangkan bagian 7
menggambarkan bagaimana artefak bersama dapat
dimasukkan dalam proses bisnis. Bagian 8 menyajikan
kesimpulan dan pekerjaan masa depan.
POIN PANDANGAN BISNIS
PROSES
Bagian ini membahas lima sudut pandang utama pada
proses bisnis, yaitu sudut pandang terpusat, sudut
pandang peran, sudut pandang percakapan, sudut
pandang kasus dan sudut pandang kooperatif.
Mungkin, sudut pandang yang paling populer
adalah yang terpusat, yang menganggap proses
bisnis pada dasarnya sebagai pengatur kegiatan
operasional. Efisiensi adalah tujuan utama, yang
dicapai melalui aliran kontrol yang kaku: dalam
konteks ini, proses bisnis seperti master yang
mendistribusikan pekerjaan di antara para peserta.
Contohnya adalah proses bisnis yang menangani
permintaan pembelian (PR) sebagai berikut. Pertama, PR
dimasukkan oleh pemohon, misalnya melalui yang cocok
73

membentuk; kemudian proses menyerahkannya kepada
pemberi persetujuan yang sesuai (misalnya supervisor
pemohon) untuk dievaluasi. Jika evaluasinya positif, proses
menyerahkan PR kepada anggota departemen pembelian
(yaitu pembeli) untuk mengubahnya menjadi pesanan
pembelian; jika tidak, ia akan memberitahukan penolakan
kepada pemohon.
Dalam perspektif terpusat, peserta dimaksudkan
untuk berinteraksi dengan proses dan bukan dengan
satu sama lain. Mereka disajikan dengan daftar tugas
yang menunjukkan tugas yang telah diberikan kepada
mereka oleh proses; dengan mengklik item dari daftar
tugas mereka, mereka dapat melakukan tugas yang
sesuai.
Ketika suatu aktivitas telah selesai, keputusan tentang
aktivitas berikutnya yang akan dilakukan diambil oleh
proses melalui blok pembangun aliran kontrol.
Proses bisnis melibatkan sejumlah peserta yang
ditunjukkan oleh peran mereka; dalam contoh di atas,
disebutkan tiga peran, yaitu pemohon (peran peserta
yang berhak memasukkan daftar permintaan
pembelian), pemberi persetujuan dan pembeli.
Swimlanes biasanya dikaitkan dengan peran untuk
mengelompokkan tugas yang sesuai.
Aktivitas dan elemen aliran kontrol adalah blok
bangunan utama, sedangkan swimlanes adalah
mekanisme penataan utama. Notasi dan bahasa
yang terkenal, seperti BPMN (OMG, 2008) dan
BPEL (OASIS, 2007), mendukung sudut pandang
terpusat.
Tidak mudah bagi peserta untuk memahami
keterlibatan mereka yang sebenarnya ketika melihat
model proses bisnis berdasarkan perspektif terpusat.
Mereka dapat menemukan tugas mereka di
swimlane yang terkait dengan peran mereka, tetapi
alur tugas untuk peserta tertentu sulit untuk
diidentifikasi karena alur tugas semua peserta
dicampur, dalam model proses.
Partisipasi pengguna dalam proses menjadi lebih
jelas, jika proses didekomposisi menjadi beberapa
komponen "peran": inilah esensi dari sudut pandang
peran. Dalam pendekatan RAD (Role Activity
Diagramming) (Ould, 2005), setiap komponen peran
disusun sebagai suatu proses yang meliputi
74
Kelincahan Bisnis dan Kelincahan Proses
tugas yang berkaitan dengan peran; komponen
berinteraksi satu sama lain melalui operasi kirim/
terima.
Sudut pandang percakapan dimulai dari
pertimbangan bahwa biasanya mungkin untuk
mengidentifikasi sejumlah bagian dalam proses
bisnis, setiap bagian mencakup aliran tugas yang
melibatkan pasangan peserta yang sama. Sementara
tugas sebenarnya bergantung pada masalah bisnis
yang ditangani, alirannya, sebaliknya, biasanya jatuh
ke dalam sejumlah pola standar.
Pola yang terkenal adalah percakapan untuk
tindakan (Winograd, 1987-1988), yang dapat
diungkapkan sebagai berikut. R (yaitu peserta yang
memulai percakapan, juga disebut sebagai pemrakarsa
percakapan) mengajukan permintaan kepada F (yaitu
pihak lain, juga disebut sebagai pengikut percakapan): F
dapat menerima, menolak, atau bahkan membuat
penawaran balik . Dalam kasus terakhir, R dapat
menerima tawaran balik, dapat membatalkan
permintaan atau dapat membuat permintaan lain.
Dalam hal penerimaan, F akan menyatakan tugas telah
selesai, dan R dapat menerima atau dapat menolak
hasilnya. Pola demikian disebut percakapan, karena
ditujukan untuk menghasilkan efek pada dunia nyata
melalui interaksi dua pihak, dan interaksi tersebut
sangat mirip dengan tindak tutur (Austin, 1976).
Sebenarnya, tujuan dari suatu interaksi adalah
untuk mengkomunikasikan maksud dari pencetus
(interaksi) kepada penerima. Contoh niat adalah
membuat permintaan, menerima permintaan,
dan memberikan jawaban.
Pola serupa adalah percakapan untuk
persetujuan yang tujuannya adalah agar permintaan
pemrakarsa dievaluasi oleh pengikut.
Misalnya, proses permintaan pembelian yang disebutkan di
atas dapat diperpanjang sehingga memungkinkan pemberi
persetujuan untuk meminta beberapa modifikasi pada
permintaan pembelian. Kemudian pemohon dapat
memperbarui permintaan pembelian atau dapat menariknya
kembali. Dalam kasus pertama, pemberi persetujuan
selanjutnya akan mengevaluasi permintaan pembelian yang
diperbarui dan hasilnya mungkin berupa persetujuan atau
penolakan atau bahkan permintaan baru untuk perubahan.
Kelincahan Bisnis dan Kelincahan Proses
Jika logika bisnis bergantung pada sejumlah
percakapan, proses bisnis secara keseluruhan
mungkin sangat rumit pada tingkat tugas; namun,
jika blok bangunan yang berpusat pada percakapan
disediakan, proses bisnis yang dihasilkan ternyata
jauh lebih sederhana.
Kelincahan dalam desain dicapai melalui blok bangunan
tersebut, karena arsitektur proses bisnis dapat dengan
cepat diperoleh dengan mengidentifikasi peran yang
terlibat dan kemudian memperkenalkan percakapan yang
diperlukan, yang dapat diperoleh dengan menyesuaikan
pola standar, seperti yang ditunjukkan pada bagian
berikutnya .
Temuan empiris (Thom, Reichert & Iochpe,
2009) menunjukkan bahwa proses bisnis umum
terutama terdiri dari pola percakapan standar.
Beberapa pendekatan pemodelan berdasarkan
percakapan telah diusulkan; mereka mencirikan
perspektif bahasa/tindakan, atau PAP (Weigand,
2006).
Dalam pendekatan Alur Kerja Tindakan
(Medina-Mora,Winograd, Flores&Flores, 1992),
percakapan khas terjadi antara pemohon dan
pelaku dan terdiri dari empat fase utama
(permintaan, komitmen, kinerja dan evaluasi)
membentuk apa yang disebut lingkaran alur kerja.
Dalam pendekatan DEMO (Dietz, 2006), loop
alur kerja dibagi dalam tiga fase (urutan, eksekusi,
dan hasil) dan dikemas dalam transaksi. Proses
bisnis adalah komposisi peran dan transaksi, di
mana transaksi menghubungkan dua peran dan
peran termasuk tugas dan logika aliran kontrol.
Dalam struktur hierarkis yang disediakan oleh
DEMO, tugas dibandingkan dengan atom,
transaksi dengan molekul, dan proses bisnis
dengan serat (Dietz, 2003).
Sudut pandang yang diperiksa sejauh ini
menekankan aktivitas dan masalah aliran kontrol,
sementara mengesampingkan entitas bisnis yang
seharusnya ditangani oleh aktivitas tersebut.
Namun, ada situasi yang membutuhkan sudut
pandang yang berbeda, di mana penanganan
siklus hidup entitas bisnis tertentu adalah tujuan
utama dari proses bisnis. entitas bisnis
ditangani disebut sebagai kasus (van der Aalst,
Weske & Grünbauer, 2005) dari proses, yang
dilambangkan sebagai proses penanganan kasus;
sudut pandang ini dapat disebut sudut pandang
kasus, akibatnya.
Proses penanganan kasus memerlukan
integrasi yang lebih kuat antara masalah aliran
kontrol dan aliran data, karena evolusi proses
didorong oleh keadaan kasus daripada
penyelesaian aktivitasnya (Künzle & Reichert,
2009). Faktanya, tugas dapat diaktifkan segera
setelah atribut yang diperlukan dari kasus telah
ditetapkan oleh tugas lain (bahkan jika tugas ini
belum selesai).
Kelincahan dicapai karena peserta dapat melihat
kasus secara keseluruhan: ketika melakukan tugas,
mereka tidak dibatasi hanya untuk memberikan item
informasi wajib, tetapi sampai batas tertentu,
mereka juga dapat memasukkan item informasi
tambahan. Jika terjadi item informasi yang
diperkenalkan dengan tugas tertentu, misalnya T1,
termasuk item informasi wajib untuk tugas
berikutnya, katakanlah, T2, maka T2 menjadi tidak
perlu dan dapat dilewati.
Winograd menyatakan bahwa percakapan
"membentuk jalinan utama kerja
kooperatif" (Winograd, 1987-1988). Istilah
percakapan harus diambil dalam arti luas
termasuk tidak hanya percakapan untuk tindakan,
tetapi juga jenis percakapan lain, seperti untuk
klarifikasi, untuk kemungkinan atau untuk
orientasi. Dari sudut pandang ini, kerjasama
dicapai melalui interaksi antar individu.
Namun, meskipun penting untuk memahami unsur-
unsur kerja kooperatif, yaitu interaksi dan percakapan
sebagai pengelompokan interaksi yang berorientasi
pada tujuan, juga harus diakui bahwa dalam banyak
kasus tujuan kerja kooperatif adalah produksi artefak
bersama, seperti dokumen. dan perangkat lunak. Dalam
sudut pandang ini disebut sebagai sudut pandang
kooperatif, para peserta berbagi ruang tindakan
"sehingga tindakan satu anggota kelompok dapat
mempengaruhi ruang tindakan yang lain" (Kaplan &
Carroll, 1992). Ini umum
75

ruang disebut sebagai ruang sosial dan terdiri dari
sejumlah entitas, disebut sebagai entitas sosial, yang
terlihat oleh semua peserta: dengan bertindak atas
entitas sosial, mereka dapat saling mempengaruhi.
Ada minat yang berkembang dalam sistem wiki, karena
potensinya dalam hal ketersediaan, kemampuan penyesuaian,
dan kelincahan dalam penggunaan (Leuf & Cunningham, 2001).
Dokumen wiki adalah entitas sosial yang
memungkinkan sejumlah pengguna dengan peran
berbeda untuk menjalankan dokumen bersama
dengan memanfaatkan mekanisme internal yang
disediakan oleh sistem wiki (misalnya kontrol akses
dan manajemen versi). Penyesuaian dokumen wiki
dapat menyiratkan pengenalan hierarki halaman dan
akibatnya definisi peserta yang berhak
mengerjakannya (Bruno, 2009).
Proses bisnis bisa mendapatkan keuntungan dari
pengenalan entitas sosial, seperti dokumen wiki.
Contohnya adalah persiapan penawaran harga yang
rumit sebagai tanggapan atas permintaan penawaran:
manajer akun yang menerima permintaan penawaran
dapat mengatur dokumen wiki untuk mengumpulkan
saran dari sejumlah penasihat sebelum melanjutkan
dengan finalisasi penawaran.
Integrasi antara proses bisnis dan entitas
sosial adalah bidang penelitian baru; pada
bagian 7, proposal berdasarkan gagasan
objek koperasi disajikan.
PERCAKAPAN
Bagian ini mengilustrasikan bagaimana percakapan
direpresentasikan di AgileBPN.
Pada dasarnya percakapan adalah pola interaksi
antara dua pihak yang disebut sebagai inisiator
(yang memulai percakapan) dan pengikut. Tujuan
interaksi adalah untuk mengkomunikasikan maksud
dari pencetusnya kepada penerimanya. Contoh niat
adalah membuat permintaan, menerima
permintaan, dan memberikan jawaban.
76
Kelincahan Bisnis dan Kelincahan Proses
Percakapan diwakili dalam hal arus interaksi
dan berbagai jenis model telah diusulkan.
Model keadaan paling banyak digunakan untuk
percakapan sekuensial, yaitu ketika interaksi
paralel tidak dapat terjadi; contoh yang
terkenal adalah model percakapan untuk
tindakan (Winograd, 1987-1988).
Dalam domain koreografi (yang membahas
percakapan yang terjadi antara dua atau lebih
peserta), ada beberapa solusi: BPSS (Hofreiter,
Huemer & Winiwarter, 2005) didasarkan pada
diagram aktivitas UML (OMG, 2007), interaksi Petri
nets ( Decker & Weske, 2007) menarik jaring Petri,
dan Let'sDance (Zaha, Dumas, ter Hofstede,
Barros & Decker, 2008) memperkenalkan
konstruksi prioritas dan penghambatan khusus.
Penelitian tentang PAIS (Process-Aware Information
Systems) (Dumas, van der Aalst & ter Hofstede, 2005)
dan penanganan kasus (van der Aalst, Weske &
Grünbauer, 2005) menganjurkan hubungan yang lebih
kuat antara aktivitas dan entitas bisnis yang akan
dibangun. ditindaklanjuti; Untuk alasan ini, di AgileBPN,
niat yang dikomunikasikan oleh interaksi didukung oleh
badan usaha yang menyediakan semua detail yang
diperlukan. Misalnya, interaksi bernama “kirim
permintaan pembelian” menunjuk ke entitas bisnis,
yang merupakan permintaan pembelian yang diajukan
oleh pembuatnya.
Mengingat interaksi, entitas bisnis terkait
disebut sebagai entitas pendukungnya.
Dari sudut pandang pelengkap, percakapan adalah
mekanisme koordinasi yang memungkinkan para peserta
untuk bertindak atas entitas bisnis yang sama pada waktu
yang berbeda dan dengan tujuan yang berbeda.
Dalam analogi dengan proses penanganan kasus
(van der Aalst, Weske & Grünbauer, 2005), ada
percakapan yang ditujukan untuk menangani siklus
hidup entitas bisnis tertentu, yang dapat disebut
sebagai kasus percakapan.
Dalam percakapan untuk persetujuan, yang akan
ditampilkan nanti di bagian ini, ada satu entitas
bisnis (yaitu item yang akan dievaluasi) mengalir di
sepanjang berbagai interaksi: item ini adalah kasus
percakapan.
Kelincahan Bisnis dan Kelincahan Proses
Secara umum, entitas pendukung dari
interaksi pertama percakapan akan dianggap
sebagai kasus percakapan.
Semua percakapan dengan tujuan yang sama
memiliki struktur yang sama dan berbeda dalam jenis
entitas pendukung interaksinya. Struktur seperti itu,
yang disebut pola percakapan, dapat didefinisikan
secara independen dari jenis entitas bisnis yang
dipertukarkan oleh para pihak; jenis generik digunakan
sebagai pengganti yang sebenarnya. Dalam model
proses, pola percakapan disesuaikan dengan mengganti
tipe generik dengan tipe aktual.
Model yang ditunjukkan pada Gambar 1 mewakili
percakapan sederhana untuk tindakan (SimpleCfA);
ditampilkan dua representasi, yaitu state model dan
sequence diagram UML (OMG, 2007).
Sebagai aturan umum, inisiator dimaksudkan
untuk ditempatkan di sisi kiri model dan pengikut
di sisi kanan. Kendala berbasis data tidak
dipertimbangkan untuk menjaga contoh cukup
sederhana: agar dapat ditangani, model informasi
termasuk atribut yang relevan dari tipe generik
harus ditambahkan.
Percakapan dimulai dengan interaksi r, dimaksudkan
untuk menyampaikan permintaan; Rmenunjukkan jenis
entitas pendukungnya. Jenis entitas dukungan interaksi
disebut sebagai jenis dukungan interaksi.
Pengikut dapat membalas dengan salah satu dari
dua interaksi alternatif, r- dan s, sehingga mengakhiri
percakapan. Interaksi r- berarti permintaan telah
ditolak, sedangkan interaksi s menyampaikan
Gambar 1. Model SimpleCfA: state model (a), sequence diagram (b)
respon (yaitu hasil dari tindakan yang dilakukan oleh
pengikut). Interaksi r- mengembalikan permintaan,
dan, untuk alasan ini, ia memiliki tipe dukungan yang
sama dengan interaksi r. Jenis dukungan interaksi s
berbeda karena mewakili hasil dari tindakan yang
dilakukan.
Pola ini menjadi lebih rumit, jika
penawaran balik disertakan (Winograd
1987-1988).
Diagram urutan mengatur aliran interaksi
dalam fragmen: fragmen "alt" mencakup
sejumlah bagian alternatif.
Selain menjadi pola interaksi, percakapan
juga merupakan pola kerja karena interaksi
dihasilkan oleh tugas pencetus dan ditangani
oleh tugas penerima.
Meskipun tugas yang sebenarnya akan ditentukan
dalam model proses, akan berguna untuk menganalisis
percakapan dalam isolasi untuk mengetahui tugas mana
yang diperlukan: tugas tersebut disebut sebagai tugas
implisit dari percakapan.
Representasi tugas lebih mudah dengan
model keadaan daripada dengan diagram urutan;
inilah alasan mengapa model negara dipilih di
AgileBPN. Pada dasarnya, tugas dikaitkan dengan
transisi, sementara interaksi ditampilkan di status.
Interaksi pertama, r, dalam pola SimpleCfA
dihasilkan oleh tugas proaktif, diwakili oleh
transisi memasuki keadaan r. Tugas proaktif tidak
memiliki status input; sebenarnya, itu terserah
77

pemrakarsa untuk memulai percakapan baru kapan
pun mereka mau. Nama standar tugas ini adalah
submitRq (kirim permintaan).
Pengikut bereaksi terhadap permintaan dengan salah
satu dari dua tugas alternatif, menolakRq (menolak
permintaan) atau menyediakanRp (memberikan
tanggapan). Itu adalah tugas opsional karena terserah
pengikut untuk memilih salah satunya. Mereka juga
merupakan tugas reaktif karena disebabkan oleh interaksi
yang masuk dan menghasilkan interaksi yang keluar.
Interaksi r- dan s mengakhiri percakapan;
pemrakarsa dapat memperhatikannya melalui
tugas readR- (perhatikan penolakan) dan readRp
(perhatikan respons), yang tidak memiliki status
keluaran karena interaksi ini bersifat final.
Jenis dukungan, R dan S, ditampilkan di
dekat status terkait.
Dua pola lagi, yang digunakan pada bagian berikut,
ditunjukkan pada Gambar 2.
Pola SimpleCfApproval menangani percakapan yang
disederhanakan untuk persetujuan. Percakapan dimulai
dengan permintaan (r) dan pengikut dapat menerima
(r+) atau menolaknya (r-). Entitas pendukung yang sama
dimaksudkan untuk maju mundur di antara para pihak,
dan karenanya hanya ada satu tipe generik yang
terlibat, R.
PatternNotification terdiri dari satu interaksi
(n), diartikan sebagai pemberitahuan (yaitu komunikasi
sederhana yang tidak memerlukan balasan). Jenis
dukungan interaksi umum adalah N.
Gambar 2. Model SimpleCfApproval (a) dan Notification (b)
78
Kelincahan Bisnis dan Kelincahan Proses
MODEL PROSES
Di AgileBPN, proses bisnis terdiri dari dua jenis
utama blok bangunan, yaitu jenis percakapan dan
proses peran, seperti yang diilustrasikan dalam
contoh sederhana berikut.
Contoh ini berkaitan dengan proses bisnis yang
dimaksudkan untuk menangani aplikasi dalam
organisasi tertentu. Persyaratannya, dijaga agar tetap
minimum, adalah sebagai berikut. Seorang pelamar
diasumsikan melamar salah satu posisi yang tersedia
dengan mengisi formulir aplikasi online; kemudian
lamaran ditangani oleh salah satu perekrut yang terkait
dengan posisi yang tertera di lamaran. Perekrut dapat
menerima atau menolak aplikasi dan hasilnya
dikomunikasikan kepada pelamar.
Dua peran, Pemohon dan Perekrut, terlibat dan
interaksi mereka mengikuti pola SimpleCfApproval;
oleh karena itu jenis percakapan, yang
disebutApplyForJob, berdasarkan template ini,
diperkenalkan. Model proses bisnis ini, yang disebut
ApplicationHandler v.1 ditunjukkan pada Gambar 3.
Versi lanjutan dari proses bisnis ini akan dibahas di
bagian berikutnya.
Beberapa notasi telah diusulkan untuk
mengintegrasikan percakapan dalam proses
bisnis; di antaranya menonjol Alur Kerja Aksi
(Medina-Mora, Winograd, Flores & Flores, 1992)
dan DEMO (Dietz, 2003).
Proses di DEMO dan di AgileBPN memiliki
struktur serupa berdasarkan percakapan (disebut
Kelincahan Bisnis dan Kelincahan Proses
Gambar 3. Proses bisnis ApplicationHandler v.1 (a) dan tabel percakapannya (b)
transaksi di DEMO) dan proses peran. Namun, di
AgileBPN, percakapan tidak terbatas pada percakapan
untuk tindakan (seperti inDEMO) dan juga
mengintegrasikan penanganan kasus; selain itu, proses
peran dapat mengakomodasi objek kooperatif seperti
yang diilustrasikan pada bagian berikutnya.
Di AgileBPN, peran ditampilkan sebagai kotak dan
percakapan sebagai tautan langsung yang berasal dari
kotak yang terkait dengan peran inisiator dan berakhir
di kotak peran pengikut. Secara umum, jenis percakapan
dapat sepenuhnya didefinisikan dalam model terpisah;
sebagai alternatif, mereka dapat diperoleh sebagai
penyesuaian pola percakapan standar. Ini adalah kasus
tipe percakapanApplyForJob, yang diturunkan dari pola
SimpleCfApproval, seperti yang ditunjukkan pada tabel
percakapan. Tabel ini (dalam kolom Pola) menunjukkan
tipe aktual mana yang dimaksudkan untuk
menggantikan tipe generik: di ApplyFor-Job, tipe generik
R harus diganti dengan tipe sebenarnya Application.
Untuk menggambarkan tipe aktual beserta atribut dan
hubungannya, diperlukan model informasi: model ini
dihilangkan demi kesederhanaan.
Model tersebut pada dasarnya menunjukkan
bahwa percakapan tipe ApplyForJob dapat terjadi
antara pelamar dan perekrut; itu adalah deskripsi
arsitektur yang meninggalkan dua aspek penting,
yaitu bagaimana pengikut percakapan ditentukan
dan bagaimana para peserta diharapkan
berperilaku berdasarkan percakapan yang
mereka ikuti.
Untuk masalah pertama, yaitu penentuan
pengikut dari percakapan yang diberikan, ada dua
alternatif utama: pengikut dipilih oleh pemrakarsa
atau pilihan dibuat oleh proses berdasarkan
aturan bisnis. Situasi pertama diilustrasikan di
bagian berikutnya, ketika perekrut berhak
meminta peninjau untuk memberikan evaluasi
aplikasi mereka. Di sisi lain, ketika pelamar
mengajukan aplikasi, mereka tidak dapat memilih
perekrut yang akan mengikuti percakapan, karena
pilihan tersebut didasarkan pada kebijakan
perusahaan. Mekanisme pemilihan dijelaskan di
kolom pengikut tabel percakapan; deskripsi yang
diberikan bersifat informal, tetapi jika model
informasi diberikan, dapat dibuat lebih tepat,
misalnya dengan menggunakan bahasa navigasi
seperti OCL (OMG, 2005).
Perilaku peserta didefinisikan dalam kotak peran,
yang bila diperluas, menunjukkan proses peran. Proses
peran mencakup tugas-tugas yang diharapkan
dilakukan oleh para peserta yang memainkan peran itu.
Karena peran terlibat dalam sejumlah percakapan,
proses peran dapat mengambil keuntungan dari tugas
implisit yang terkait dengan percakapan ini, seperti yang
ditunjukkan pada Gambar 4.
Percakapan di mana peran terlibat ditampilkan
sebagai proses percakapan dalam proses peran yang
sesuai. Proses percakapan diberi label dengan jenis
percakapan yang dirujuk dan direpresentasikan
sebagai persegi panjang dengan sudut membulat
termasuk interaksi percakapan.
79
 Kelincahan Bisnis dan Kelincahan Proses

Gambar 4. Peran proses dalam proses bisnis

Bagian yang relevan dari keseluruhan aliran
ApplicationHandler v.1
kontrol ditentukan dalam jenis percakapan; namun,
mungkin ada situasi di mana urutan percakapan
harus ditetapkan sebagai konsekuensi dari kebijakan
perusahaan. Dalam kasus seperti itu, aliran kontrol
tingkat proses diperlukan, yang kemudian berada di
luar percakapan.
Pembahasan masalah ini didasarkan pada
versi panjang dari proses bisnis
ApplicationHandler (diperkenalkan di bagian
sebelumnya). Dalam situasi baru, empat peran
terlibat, yaitu pelamar, perekrut, peninjau dan
anggota departemen personalia.
Pelamar mengirimkan aplikasi seperti
sebelumnya. Namun, perekrut tidak dapat
memutuskan aplikasi tanpa mendapatkan tiga
ulasan eksternal sebelumnya. Oleh karena itu
mereka mengirim aplikasi ke tiga reviewer dan ketika
review tersedia, mereka akan mengambil keputusan
jenis tion serta tugas implisit yang dibutuhkan.
akhir (apakah menerima atau menolak aplikasi). Jika
Tugas adalah yang berkaitan dengan fungsi
peninjau menolak untuk mengevaluasi aplikasi,
(inisiator atau pengikut) yang dilakukan oleh
mereka akan menunjuk yang lain. Pemilihan
peran sehubungan dengan jenis percakapan dan
pengulas dilakukan oleh perekrut.
jenis dukungan umum diganti dengan jenis
Dalam hal aplikasi diterima, (anggota)
dukungan yang sebenarnya (berdasarkan kolom
departemen personalia akan menyelesaikan
pola di tabel percakapan).
prosedur perekrutan melalui serangkaian interaksi
Komplikasi muncul ketika peran terlibat dalam
dengan pelamar: demi kesederhanaan, hanya satu
dua atau lebih jenis percakapan: situasi ini, dianalisis
interaksi (dari departemen personalia ke pelamar)
di bagian berikutnya, memerlukan pengenalan tugas
yang harus dilakukan. dipertimbangkan. Interaksi ini
baru (sebagai tambahan atau alternatif dari yang
seharusnya membawa aplikasi kembali ke pelamar
implisit), yang tujuannya adalah untuk
dengan beberapa detail perekrutan.
menggabungkan interaksi milik berbeda jenis
Analisis persyaratan di atas mengungkapkan
percakapan.
bahwa percakapan yang terjadi antara perekrut
dan pengulas adalah percakapan sederhana
untuk tindakan; maka mereka berasal dari pola
PROSES PERAN
SimpleCfA. Tipenya disebut GetReview: tipe
dukungan generik R dan S diganti dengan tipe
Bagian ini membahas dua faktor utama
dukungan sebenarnyaApplication dan Review.
kompleksitas, satu di tingkat peran dan yang
Percakapan antara departemen personalia dan
lainnya di tingkat proses.
pelamar berjumlah pemberitahuan; tipenya
Kompleksitas meningkat pada tingkat peran ketika ada
disebut FinalizeHiring dan tipe dukungan generik
dua atau lebih jenis percakapan yang harus ditangani; aliran
N diganti dengan Application.
kontrol tambahan kemudian diperlukan untuk
mengintegrasikan proses percakapan yang terpisah.

80
Kelincahan Bisnis dan Kelincahan Proses
Model proses bisnis Application-Handler v.2
ditunjukkan pada Gambar 5 beserta tabel
percakapannya.
Dalam proses ApplicationHandler v.2, ketika
aplikasi diterima, pekerjaan lebih lanjut harus
dilakukan oleh departemen personalia; namun,
anggotanya tidak terlibat dalam evaluasi aplikasi
dan karenanya aliran kontrol eksternal diperlukan
untuk membawa mereka aplikasi yang diterima.
Dengan istilah lain, ketika percakapan
ApplyForJob berakhir dengan sukses, percakapan
FinalizeHiring dimaksudkan untuk diikuti.
Hubungan antara dua percakapan ini diperoleh
melalui notifikasi N, yang bertujuan untuk
menyampaikan interaksi ApplyForJob.r+ dari
perekrut (sumber tautan) ke anggota departemen
personalia, yang dipilih oleh proses. Mengenai
notasi, tautan notifikasi diberi label oleh interaksi
yang akan disampaikan yang ditulis di antara
tanda kurung.
Persyaratan tidak membebani perekrut untuk
melakukan percakapan eksplisit dengan departemen
personalia, dan oleh karena itu pemberitahuan otomatis
diperlukan. Perekrut tidak mengetahui pemberitahuan
otomatis seperti itu, karena mereka adalah bagian dari
tingkat penataan yang lebih tinggi.
Gambar 5. Model proses ApplicationHandler v.2
Proses peran perekrut, ditunjukkan pada Gambar
6, ternyata lebih kompleks daripada proses
bisnis versi pertama, karena perekrut terlibat
dalam beberapa percakapan (tipe ApplyForJob
dan GetReview) yang perlu digabungkan
berdasarkan persyaratan di atas.
Jenis percakapan adalah model yang
menggambarkan bagaimana percakapan aktual
berdasarkan jenis itu diharapkan berlangsung dari
waktu ke waktu. Model ini berbasis negara sebagai
percakapan aktual bergerak dari satu negara ke negara
lain tergantung pada keputusan yang diambil oleh
peserta yang terlibat. Ketika beberapa percakapan perlu
diintegrasikan, proses percakapan standar (berasal dari
jenis percakapan yang sesuai) diperluas dengan
penambahan status baru dan dengan pengenalan tugas
baru yang tindakannya mencakup dua atau lebih
percakapan aktual.
Ketika seorang perekrut menerima aplikasi untuk
mengevaluasi, mereka harus mendapatkan tiga ulasan
dari pengulas yang sesuai; oleh karena itu tugas baru
askFor-Reviews diperlukan. Tugas implisit, rejectRq dan
approvalRq, tidak lagi diperlukan. Efek dari tugas
askForReviews adalah menempatkan aplikasi dalam
status baru, yaitu status p (keputusan menunggu
keputusan), dan memulai tiga percakapan GetReview,
masing-masing dengan peninjau berbeda.
81

Gambar 6. Proses peran perekrut dalam proses bisnis ApplicationHandler v.2
Jika tugas, seperti askForReviews, memiliki dua atau
lebih status keluaran, itu tidak direpresentasikan
sebagai tautan tetapi sebagai persegi panjang kecil;
secara umum representasi ini (menyerupai jaring Petri)
diperlukan ketika ada dua atau lebih input dan/atau dua
atau lebih output.
Jika tugas terhubung ke status awal proses
percakapan, maka pelaksanaan tugas ini akan
menghasilkan aktivasi percakapan baru jenis
itu; jika multiplisitas (misalnya 3) ditampilkan di
dekat koneksi, maka beberapa percakapan
baru akan dimulai oleh tugas.
Karena status input ApplyForJob.r dan status
output GetReview.r memiliki jenis dukungan yang
sama, aplikasi yang sama yang diterima dengan
interaksi ApplyForJob.r ditransmisikan ke interaksi
keluar GetReview.r.
Faktanya, task askForReviews mencakup
empat percakapan: percakapanApplyForJob yang
memicu eksekusi tugas dan tiga percakapan
GetReview yang dimulai oleh tugas. Hubungan
orang tua-anak dibuat antara percakapan dengan
tugas-tugas seperti askForReviews: percakapan
ApplyForJob dapat dianggap sebagai induk dari
tiga percakapan GetReview.
82
Kelincahan Bisnis dan Kelincahan Proses
Interpretasi ini didasarkan pada fakta bahwa
tugas askForReviews muncul di dalam proses
percakapan ApplyForJob.
Reviewer dapat membalas dengan penolakan
atau review. Dalam kasus pertama, perekrut harus
melibatkan pengulas lain, seperti yang ditunjukkan
oleh tugas replaceReviewer. Tugas ini, dipicu oleh
kesimpulan negatif dari percakapan GetReview,
dimaksudkan untuk memulai percakapan GetReview
baru dengan pengulas lain. Tugas replaceReviewer
mencakup satu percakapan ApplyForJob dan dua
percakapan GetReview: percakapan GetReview yang
baru dimulai adalah anak dari percakapan
ApplyForJob karena tugas tersebut milik proses
percakapan ApplyForJob.
Ketika tiga ulasan tersedia, perekrut dapat
menerima atau menolak aplikasi yang tertunda.
Tugas terkait disebut acceptApplication dan
rejectApplication: efeknya adalah memindahkan
aplikasi tertunda dari status p ke status r+ atau
status r-, masing-masing.
Tugas tersebut dijaga karena aktivasinya tunduk
pada ketersediaan tiga ulasan yang berkorelasi (di
mana korelasi didasarkan pada hubungan orang tua-
anak di antara percakapan). Penjaga
Kelincahan Bisnis dan Kelincahan Proses
(misalnya g1) adalah kondisi yang harus
dipenuhi agar tugas dapat dilaksanakan; itu
diberikan deskripsi informal tanpa adanya
model informasi.
PROSES PERAN gesit
Percakapan dimaksudkan untuk memperkenalkan
beberapa kelincahan dalam interaksi antara dua pihak,
karena negosiasi dapat terjadi pada setiap tahap
(Winograd, 1987-1988).
Dalam pola percakapanSimpleCfApproval, kelincahan ini
dicapai dengan memberi pengikut kesempatan untuk
memutuskan interaksi mana yang akan dilakukan setelah
menerima permintaan, yaitu apakah akan menerima atau
menolaknya. Karena interaksi dihasilkan oleh tugas,
keputusan tersebut diwujudkan dalam pemilihan tugas
yang tepat untuk dilaksanakan. Kelincahan semacam ini
disebut sebagai kelincahan percakapan.
Jenis lain dari kelincahan, disebut sebagai kelincahan
peran, dapat dicapai pada tingkat peran, jika peserta
dapat memilih tugas untuk dilakukan pada
Gambar 7. Proses perekrut tangkas
dasar penilaian pribadi mereka didasarkan pada
keterampilan dan pengalaman mereka.
Dalam proses perekrut yang ditunjukkan pada
Gambar 6, ada dua situasi "kaku", sesuai dengan
tugas askForReviews dan replaceReviewer. Tugas-
tugas ini wajib, karena mereka tidak memiliki
alternatif. Kekakuan yang berlebihan mencegah
peserta mengambil reaksi cerdas dalam
menanggapi situasi luar biasa.
Misalnya, jika aplikasi memerlukan penanganan
yang hati-hati, perekrut mungkin ingin melibatkan lebih
dari tiga peninjau, untuk memilih ulasan yang paling
tepat, atau mereka mungkin ingin melibatkan pengulas
lain segera setelah mereka menduga bahwa peninjau
tidak akan menyampaikan ulasan mereka; atau, dalam
situasi ekstrem, mereka mungkin ingin memberikan
ulasan sendiri.
Selain itu, jumlah tinjauan yang diperlukan
dapat diubah berdasarkan persyaratan urgensi.
Model proses perekrut yang direvisi ditunjukkan
pada Gambar 7. Ketika aplikasi dalam status r, tugas
askForReviews dan writeReview mungkin
83

dilakukan dalam urutan apa pun; untuk alasan ini, ada
hubungan dua arah antara status r dan tugas-tugas ini.
Tugas askForReviews memungkinkan perekrut untuk
melibatkan satu atau lebih peninjau (dan tidak tepat tiga
seperti pada model sebelumnya, yang ditunjukkan pada
Gambar 6) dan dapat dilakukan beberapa kali. Multiplisitas
“+”, yang ditampilkan di dekat koneksi dari tugas ini ke
status awal proses percakapan GetReview, berarti bahwa
satu atau beberapa percakapan dapat dimulai oleh tugas
tersebut.
Tugas writeReview dapat dilakukan sekali
karena penjaga g2.
Jumlah tinjauan yang diperlukan ditentukan
oleh parameter nr, yang dapat diubah sesekali,
bila diperlukan.
Proses tangkas dapat dibandingkan dengan peta
yang digunakan untuk tujuan orientasi, dan bukan
sebagai urutan tindakan yang ditentukan (Suchman,
1987). Penekanannya ditempatkan pada tugas-tugas
yang harus dilakukan dan pada artefak yang akan
ditindaklanjuti, bukan pada hubungan pemesanan
eksplisit antara tugas-tugas.
Proses peran yang ditunjukkan pada Gambar 7
adalah kasus "fleksibilitas terbatas" (de Man, 2009),
karena keadaan percakapan membentuk wilayah
fleksibilitas di mana para peserta dapat mengambil
keputusan mereka.
OBJEK KOPERASI
Bagian ini membahas bagaimana pengembangan
kooperatif dari artefak bersama direpresentasikan di
AgileBPN melalui objek kooperatif. Secara khusus
penggunaan sistem wiki ditujukan, karena
potensinya dalam hal ketersediaan, kemampuan
penyesuaian, dan kelincahan dalam penggunaan
(Neumann & Erol, 2009).
Di AgileBPN, objek koperasi adalah
lingkungan koperasi yang dikemas, terdiri
dari kegiatan operasional, kegiatan
koordinasi dan bidang kerja bersama.
Bidang kerja umum dari objek kerja sama
wiki adalah kumpulan halaman web tempat
84
Kelincahan Bisnis dan Kelincahan Proses
tindakan operasional (misalnya pengeditan) dapat
dilakukan dengan memanfaatkan mekanisme
internal sistem wiki, yang mencakup kontrol akses
dan manajemen versi (Bruno, 2009).
Tindakan koordinasi terutama berkaitan
dengan penanganan kelompok kerja dan ini
terjadi melalui percakapan.
Sebagai contoh, bagian ini menyajikan versi
baru dari proses bisnis ApplicationHandler di
mana aplikasi dievaluasi secara kooperatif oleh
perekrut dan peninjau. Secara khusus, setelah
menerima aplikasi, perekrut membuat dokumen
wiki (dalam bentuk awalnya) dan mengundang
sejumlah peninjau untuk bekerja sama menulis
evaluasi aplikasi dalam dokumen wiki.
Di AgileBPN, objek kooperatif awiki menyiratkan dua
peran utama, moderator dan kontributor. Moderator
bertanggung jawab untuk menghasilkan dokumen wiki dan
mengundang kontributor, yang pada dasarnya bertindak
sebagai penulis. Moderator juga penulis, dan, sebagai
tambahan, mereka dapat membekukan dokumen wiki
sehingga menghentikan perubahan lebih lanjut.
Moderator mengelola kelompok kerja dengan
percakapan sederhana yang ditunjukkan pada Gambar
8; jenis mereka bernama WikiConversation.
Moderator adalah inisiator percakapan,
sedangkan pengikutnya adalah kontributor.
Interaksi awal (i) memungkinkan moderator untuk
mengundang kontributor untuk mengambil bagian dalam
upaya kooperatif; entitas pendukung adalah dokumen wiki
yang akan ditindaklanjuti. Salah satu pihak bisa berakhir
Gambar 8. Model WikiConversation
Kelincahan Bisnis dan Kelincahan Proses
percakapan: moderator ketika periode pengeditan telah
berlalu, kontributor kapan saja. Penolakan tugas adalah
opsional seperti yang ditunjukkan oleh stereotip yang
terkait dengan transisi.
Tindakan dan interaksi yang dilakukan
melalui objek kerjasama wiki oleh moderator
dan kontributor dapat direpresentasikan
melalui model perilaku yang ditunjukkan pada
Gambar 9, di mana sisi kiri membahas perilaku
moderator dan sisi kanan kontributor. Model
perilaku objek kooperatif menunjukkan tugas
dan percakapan yang berkaitan dengan peran
peserta serta kendala pemesanan. Batasan
pemesanan bergantung baik pada mekanisme
internal (yang, misalnya, mencegah dua
peserta mengedit bagian dokumen yang sama)
dan pada interaksi koordinasi. Model perilaku
dokumen wiki diberi nama WikiDocument dan
mengacu pada jenis percakapan
WikiConversation.
Setelah membuat dokumen wiki, moderator berhak
mengundang kontributor (dengan memulai
WikiConversations dengan mereka), untuk berkontribusi
pada dokumen serta mengoordinasikan kelompok kerja
(dengan moderator tugas). Status g adalah status awal
dokumen wiki, sedangkan status e adalah status akhir.
Ketika waktu yang diberikan untuk menulis
Gambar 9. Model perilaku WikiDocument
dokumen wiki telah berlalu, moderator dapat
membekukannya, sehingga membawanya ke status akhir.
Ketika dokumen wiki dibekukan, semua Percakapan Wiki
yang sedang berlangsung akan berakhir.
Saat WikiConversations dalam status g, kontributor
dapat mengerjakan dokumen wiki terkait; mereka dapat
melakukannya sampai mereka menolak atau
percakapan diakhiri oleh moderator.
Tugas berkontribusi dan moderat dipetakan
ke mekanisme internal sistem wiki.
Ketika peran dimaksudkan untuk beroperasi
pada objek kooperatif, tidak perlu secara eksplisit
memperkenalkan tugas perilaku terkait dalam
proses peran, karena secara otomatis tersirat oleh
objek kooperatif itu sendiri.
Versi baru dari proses Application-Handler (versi
3) ditunjukkan pada Gambar 10. Jenis EvaluationWiki
mengacu pada patternWikiDocument yang
merupakan objek kooperatif.
Dalam proses peran, objek kooperatif muncul sebagai blok
bangunan, ditampilkan sebagai kotak, yang terhubung ke tugas
yang dimaksudkan untuk mengaktifkannya.
Versi baru dari proses perekrut ditunjukkan
pada Gambar 11.
Setelah menerima aplikasi untuk mengevaluasi,
perekrut melakukan tugas genWikiDocument sehingga
menghasilkan sebuah instance dari EvaluationWiki (mis.
85
 Kelincahan Bisnis dan Kelincahan Proses

Gambar 10. Model proses ApplicationHandler v.3

dokumen wiki). Kemudian, mereka dapat mengundang
pengulas sebagai kontributor berdasarkan model perilaku
yang ditunjukkan pada Gambar 9.
Tugas genWikiDocument membawa aplikasi ke
status p; aplikasi tetap dalam keadaan ini sampai
perekrut mengambil keputusan akhir, yang harus
didahului dengan pembekuan dokumen wiki
sebagaimana ditentukan oleh penjaga g1.

Gambar 11. Proses perekrut termasuk objek kooperatif

86
Kelincahan Bisnis dan Kelincahan Proses
KESIMPULAN
Kelincahan adalah fitur penting untuk UKM,
karena "ini tidak menerapkan proses standar
untuk tingkat seperti perusahaan besar" (Riss,
Rickayzen, Maus & van der Aalst, 2005).
Notasi dan bahasa untuk proses bisnis berbeda dalam
sudut pandang yang mendasarinya; bab ini telah
mempertimbangkan lima sudut pandang utama (yaitu
sudut pandang terpusat, sudut pandang peran, sudut
pandang percakapan, sudut pandang kasus dan yang
kooperatif) dan telah membahas bagaimana mereka
menangani masalah kelincahan. Secara khusus, tiga bentuk
kelincahan telah ditekankan: kelincahan percakapan,
kelincahan peran dan kelincahan kelompok.
Bentuk pertama berkaitan dengan percakapan antara
dua pihak karena negosiasi dapat terjadi pada tahap
apapun. Kelincahan peran adalah kemampuan peserta
(memainkan peran tertentu) untuk memilih tugas yang akan
dilakukan berdasarkan penilaian pribadi mereka yang
didasarkan pada keterampilan dan pengalaman mereka.
Kelincahan peran dipromosikan oleh sudut
pandang kasus karena peserta dapat melihat kasus
(yaitu objek bisnis yang akan ditindaklanjuti) secara
keseluruhan dan evolusi proses didorong oleh
keadaan kasus daripada penyelesaian aktivitasnya
( Kunzle & Reichert, 2009).
Dalam bab ini, kelincahan kelompok terutama
terkait dengan pengembangan kooperatif artefak
bersama: khususnya penggunaan sistem wiki dibahas,
karena potensinya dalam hal ketersediaan, kemampuan
penyesuaian, dan kelincahan dalam penggunaan
(Neumann & Erol, 2009).
Notasi bukti konsep, AgileBPN, telah disajikan
yang bertujuan untuk mengintegrasikan semua
sudut pandang yang disebutkan di atas. DiAgileBPN,
proses bisnis diatur di sekitar percakapan dan proses
peran (mencakup tugas yang berkaitan dengan
peran tertentu); artefak bersama direpresentasikan
sebagai objek kooperatif. Definisi objek kooperatif
wiki telah disajikan: ini adalah pendekatan baru di
mana tindakan operasional yang terkait dengan
teknologi yang mendasarinya adalah
terintegrasi dengan kegiatan koordinasi berdasarkan
percakapan.
Peningkatan perhatian diharapkan diarahkan
pada pendekatan holistik seperti AgileBPN, karena
sekarang diakui bahwa "proses paling penting untuk
organisasi saat ini melibatkan kerja
pengetahuan" (Davenport, 2005).
Ada dua arah utama pengembangan masa
depan untuk penelitian yang disajikan dalam
bab ini. Salah satunya adalah integrasi model
proses dan model informasi dengan tujuan
membuat anotasi dalam model lebih formal.
Arah lain berkaitan dengan definisi ruang kerja
pribadi yang sesuai di mana peserta dapat
melakukan tindakan mereka dan dapat
mengamati hasil tindakan peserta lain.
REFERENSI
Austin, JL (1976).Bagaimana melakukan sesuatu dengan kata-
kata. Oxford, Inggris: Oxford University Press.
Bruno, G. (2009).Persyaratan elisitasi sebagai kasus
proses sosial: sebuah pendekatan untuk deskripsinya. Di
dalam 7th Int. Konferensi Manajemen Proses Bisnis:
Workshop BPMS2'09. Pegas (dalam pers).
Davenport, TH (1993).Inovasi proses. Boston:
Pers Sekolah Bisnis Harvard.
Davenport, TH (2005).Berpikir untuk mencari nafkah.
Boston: Pers Sekolah Bisnis Harvard.
de Man, H. (2009). Manajemen kasus: Pendekatan
Cordys.BPtrends. Diakses pada 18 September 2009,
dari http://www.bptrends.com.
Decker,G.,&Weske,M. (2007). Keberlakuan Lokal
dalam Interaksi Petri Nets. [NewYork: Springer.].
Catatan KuliahdiIlmu Komputer,4714,305–319.
doi:10.1007/978-3-540-75183-0_22
Dietz, JLG (2003). Atom, molekul, dan serat
organisasi.Rekayasa Data & Pengetahuan,
47(3), 301–325. doi:10.1016/S0169-
023X(03)00062-4
87
 Kelincahan Bisnis dan Kelincahan Proses

Dietz, JLG (2006). Struktur Mendalam OASIS. (2007). Bahasa Eksekusi Proses Bisnis
Proses Bisnis.KomunikasiACM,49(5), 59–64. Layanan Web, V.2.0. Diakses pada 18
doi: 10.1145/1125944.1125976 September 2009, dari http://docs.oasis-
open.org/wsbpel/2.0/wsbpel-v2.0.pdf.
Dumas, M., van der Aalst, WMP, & ter Hofstede,
AHM (2005).Sistem Informasi Sadar Proses: YA AMPUN. (2005).Spesifikasi UML 2.0 OCL.
menjembatani orang dan perangkat lunak Diakses pada 18 September 2009, dari http://
melalui teknologi proses. New York: Wiley. www. omg.org/docs/ptc/ 05-06-06.pdf.
doi:10.1002/0471741442
YA TUHAN. (2007).Bahasa Pemodelan Terpadu:
Hofreiter,B.,Huemer,C.,&Winiwarter,W. (2005). Superstruktur, V.2.1.1. Diakses pada 18
Model kolaborasi bisnis dan koreografi web yang September 2009, dari http://www.omg.org/docs/
bergantung pada konteks bisnis mereka di BPSS. formal/07-02-03.pdf.
Jurnal Internasional Sistem Informasi Web, 1(1),
YA TUHAN. (2008).Notasi Pemodelan Proses
33–42. doi: 10.1108/17440080580000081
Bisnis, V.1.1. Diakses pada 18 September 2009,
Holt, AW (1985). Teknologi koordinasi dan dari http://www.bpmn.org.
jaring Petri. [New York: Pegas.].Catatan Kuliah
Lama, M. (2005).BusinessProcessManagement:
di Ilmu Komputer,222, 278–296. doi:10.1007/
pendekatan yang ketat.Masyarakat Komputer Inggris.
BFb0016217
Riss, UV, Rickayzen, A., Maus, H., & van der
Kaplan, SM, & Carroll, AM (1992). Mendukung
Aalst, WMP (2005). Tantangan untuk proses
Proses Kolaboratif dengan ConversationBuilder.
bisnis dan manajemen tugas.Jurnal Manajemen
Komunikasi Komputer,15(8), 489–501.
Pengetahuan Universal,0(2), 77–100.
doi:10.1016/0140-3664(92)90028-D
Schmidt, K., & Simone, C. (1996). Mekanisme
Künzle, V., & Reichert, M. (2009). Menuju sistem
koordinasi: menuju landasan konseptual
manajemen proses yang sadar objek: masalah,
desain sistem CSCW.Kerja Koperasi yang
tantangan, manfaat. Di dalamCatatan Kuliah dalam
Didukung Komputer,5, 155–200. doi:10.1007/
Pengolahan Informasi Bisnis, 29(hlm. 197–210). New
BF00133655
York: Pegas.
Suchman, LA (1987).Rencana dan tindakan situasi:
Leuf, B., & Cunningham, W. (2001).Cara
masalah komunikasi manusia-mesin. Cambridge,
Wiki: kolaborasi cepat di web. Membaca,
Inggris: Cambridge University Press.
MA: Addison-Wesley.
Thom, LH, Reichert, M., & Iochpe, C. (2009).
Medina-Mora, R., Winograd, T., Flores, R., & Flores, F.
Pola aktivitas dalam Sistem Informasi Sadar
(1992). Pendekatan Alur Kerja Aksi untuk teknologi
Proses: konsep dasar dan bukti empiris.
manajemen alur kerja. Dalam J. Turner & R. Kraut
Jurnal Internasional Integrasi dan
(Eds.),Konferensi ke-4 tentang Kerja Koperasi yang
Manajemen Proses Bisnis,4(2), 93–110.
Didukung Komputer. New York: ACM.
doi:10.1504/ IJBPIM.2009.027778
Neumann, G., & Erol, S. (2009). Dari wiki sosial
van derAalst, WMP, Weske, M., & Grünbauer, D.
ke sistem alur kerja sosial. Di dalamCatatan
(2005). Penanganan kasus: paradigma baru untuk
Kuliah dalam Pengolahan Informasi Bisnis, 17
mendukung proses bisnis.Rekayasa Data &
(hal. 698–708). New York: Pegas.
Pengetahuan,53(2), 129-162. doi:10.1016/j.
datak.2004.07.003

88
Kelincahan Bisnis dan Kelincahan Proses

Weigand, H. (2006). Dua dekade Perspektif
Bahasa-Tindakan: pengantar. Komunikasi
ACM,49(5), 44–46. doi:
10.1145/1125944.1125973
Winograd, T. (1987-1988). Perspektif
Bahasa/Tindakan pada desain kerja
kooperatif.Interaksi Manusia-Komputer,3,
3–30. doi:10.1207/s15327051hci0301_2
Zaha, JM, Dumas, M., ter Hofstede, AHM, Barros,
A., & Decker, G. (2008). Menjembatani model
global dan lokal dari sistem berorientasi layanan.
Transaksi IEEE pada Sistem, Manusia dan
Sibernetika. Bagian C, Aplikasi dan Ulasan,38(3),
302–318. doi:10.1109/TSMCC.2008.919193

89