1. Pendoman / Quality Manual atau Environment Manual, biasanya disebut Level 1, yaitu dokumen tertinggi yang mengatur dokumen-dokumen di level berikutnya. Biasanya dalam level 1 ini salah satunya mengatur tentang pengendalian dokumen itu sendiri atau bisa juga pengendalian dokumen dibuatkan dalam prosedur (level 2).
2. Prosedur / Procedure, biasanya disebut Level 2, yaitu dokumen yang berisi prosedur atau proses bisnis. Biasanya didalamnya terdapat alur kerja / flowchart.
3. Dokumen Pendukung / Supporting Document, yaitu dokumen pendukung dari prosedur atau level 2, dapat berupa formulir, log, record, dst.

Prosedur pengendalian dokumen mengatur kesemua level dari dokumen diatas. Tujuan dari prosedur pengenalian dokumen adalah untuk memastikan semua level dokumen dibuat dan distribusikan dengan benar. Berikut ini adalah proses-proses yang biasanya diatur dalam prosedur pengendalian dokumen, yaitu:

1. Pengaturan penerbitan dokumen baru
2. Pengaturan perubahan dokumen yang sudah ada
3. Pengaturan pendistribusian dokumen yang  baru terbit sekaligus penarikan dokumen versi sebelumnya

Alasan kenapa untuk penerbitan sebuah dokumen baru atau revisi perlu diatur dalam sebuah prosedur atau diatur dalam pedoman, yaitu:

1. Legalitas, yaitu mengatur pejabat yang berhak melakukan review dan memberikan persetujuan terhadap penerbitan prosedur. Tanpa persetujuan Pejabat yang memiliki wewenang, prosedur menjadi tidak sah.
2. Aturan revisi, yaitu mengatur tata cara merevisi dokumen yang sudah ada, termasuk didalamnya persetujuan dari permohonan revisi, pembuatan revisi dan persetujuan hasil revisi.
3. Distribusi, yaitu tata cara mendistribusikan dokumen baru atau dokumen revisi yang baru disetujui. Didalamnya menyangkut tandaterima dokumen baru maupun berita acara penarikan dokumen lama.

Dalam pelaksanaannya prosedur pengendalian dokumen ini bisa dilakukan secara manual maupun melalui sistem. Berikut ini adalah kesulitan jika dilakukan secara manual:

1. Proses persetujuan tidak termonitor dengan baik karena dokumen berjalan dari meja ke meja.
2. Pendistribusian menyangkut proses penggandaan dokumen yang jumlahnya bisa ratusan bahkan ribuan lembar, karena sebuah dokumen yang jumlahnya hanya 20 lembar jika di distribusikan ke 20 bagian, maka jumlah penggandaan mencapai 400 lembar. Proses penggandaan ini meliputi fotocopy dan pengesahan, biasanya berupa cap “TERKENDALI” di setiap lembarnya.
3. Pendistribusian yang lambat dan rentan terhadap kesalahan, seperti hilang, rusak, dst. Apalagi jika distribusi menyangkut lokasi bagian-bagian yang ada diluar kota.
4. Kesalahan penarikan dokumen lama, sehingga bisa mengakibatkan pada salahnya proses.
5. Bagian-bagian mengalami kesusahan dalam mencari dokumen, karena pencarian pada kertas-kertas dalam map. Ditambah lagi dokumen tidak bisa dibuka secara pararel oleh beberapa orang sekaligus.

Melihat dari kelemahan diatas adalah sangat baik jika proses dalam pengendalian dokumen dibuat secara elektronik. Pada tulisan berikutnya akan dijelaskan tentang aplikasi pengendalian dokumen dalam Perusahaan menggunakan sistem atau secara elektronik.

Jika ada pertanyaan atau kebutuhan tentang aplikasi pengendalian dokumen silahkan menghubungi alamat email berikut ini: Wibowo Gunawan

Aplikasi Cuti bisa dibuat menjadi aplikasi workflow yang sederhana maupun yang lebih Advance. Berikut fitur yang bisa dibangun jika ingin membuat aplikasi Cuti yang sederhana, yaitu:

1. Pengisian formulir Permohoan Cuti
2. Persetujuan oleh bagian terkait (Atasan dan/atau HRD)

Sedangkan fitur-fitur Advance yang bisa dikembangkan adalah:

1. Perhitungan sisa cuti untuk cuti tahunan beserta dengan aturannya seperti apakah sisa cuti bisa dibawa ke tahun berikutnya, sisa cuti apakah bisa diuangkan, dst.
2. Pengontrolan cuti selain cuti tahunan, seperti pernikahan, naik haji, kelahiran, dst.
3. Pengiriman data cuti untuk digunakan di mesin absensi dan aplikasi penggajian
4. Pengontrolan terhadap aturan cuti, seperti per perhomonan hanya boleh mengajukan cuti maks. xx hari, dalam 1 Departemen hanya boleh ada xx permohonan, dst.

Untuk perhitungan sisa cuti, didalam aplikasi Permohonan Cuti, bisa ada dua alternatif, yaitu dilakukan didalam aplikasi ini atau jika Perusahaan sudah punya aplikasi tentang kepegawaian yang didalamnya sudah ada modul cuti-nya, maka aplikasi Cuti akan mengecek secara online sisa cuti sebagai validasi permohonan.

Apa itu Workflow Engine ?

Lotus Workflow – a Workflow Engine

Berikut obyektif yang akan dibahas dalam tulisan ini:

1. Apa itu Workflow atau Aplikasi Workflow ?
2. Apa perbedaan dari Aplikasi Workflow dengan Workflow Engine ?
3. Contoh aplikasi Workflow

Apa itu Workflow atau Aplikasi Workflow ?

Workflow atau Aplikasi Workflow adalah sebuah software yang digunakan untuk menjalankan suatu proses bisnis secara elektronik, dimana didalamnya terdapat proses/fungsi menjalankan tugas-tugas ke bagian-bagian terkait untuk dikerjakan. Secara garis besar dalam workflow terdapat:

1. Tugas atau tugas-tugas
2. Fungsi menjalankan atau mendistribusikan tugas atau tugas-tugas
3. Ke bagian-bagian terkait untuk dikerjakan/diselesaikan
4. Mengikuti alur kerja atau bisnis proses yang sudah ditentukan sebelumnya

Apa itu tugas atau tugas-tugas ?

Tugas adalah pekerjaan yang akan diserahkan kepada bagian terkait untuk dikerjakan/diselesaikan mengikuti proses bisnis yang sudah ada. Tugas disini bisa berupa pekerjaan didalam aplikasi workflow itu sendiri atau berupa pekerjaan diluar sistem (di sistem lain atau pekerjaan manual). Contoh tugas-tugas yang ada didalam sebuah workflow Pengajuan Cuti:

1. Pengisian formulir permohonan cuti
2. Pengecekan sisa cuti
3. Persetujuan permohonan cuti
4. Pengecekan aturan cuti

Dari contoh diatas, tugas yang dilakukan di dalam aplikasi workflow Permohonan Cuti adalah tugas no 1 dan 3, dilakukan di sistem lain adalah tugas no. 2 dan dikerjakan secara manual adalah tugas no. 4.

Apa itu fungsi menjalankan atau mendistribusikan tugas atau tugas-tugas ?

Workflow adalah rangkaian tugas-tugas yang dilakukan untuk sebuah tujuan (proses bisnis) dan pada umumnya rangkaian pekerjaan ini melibatkan beberapa pihak. Nah karena melibatkan beberapa pihak, maka salah satu fungsi dari workflow adalah routing atau menjalankan atau mendistribusikan. Apa yang dijalankan ? Yaitu tugas-tugas. Kemana dijalankan ? Yaitu ke bagian-bagian terkait. Bagaimana cara menjalankan ? Yaitu melalui aplikasi atau secara elektronik. Yang dimaksud menjalankan disini ada 2 pengertian, yaitu:

1. Menjalankan tugas: memindahkan tugas dari satu bagian ke bagian lain (berupa status dokumen yang berubah dan pemberian hak untuk mengerjakan tugas/memberi tanda kepada bagian yang mendapatkan tugas).
2. Pemberitahuan tugas: bisa berupa email atau sms kepada penerima tugas

Apa itu Bagian-bagian terkait ?

Tugas dalam sebuah proses bisnis sudah diarahkan untuk dikerjakan oleh pihak tertentu sesuai dengan fungsi dan wewenang. Nah bagian disini adalah keterkaitan antara tugas dan fungsi routing yaitu siapa penerima tugas atau tanggungjawab ? Kenapa bagian terkait ini mendapat perhatian khusus dalam pembahasan workflow ? karena workflow yang baik sudah menyediakan alat bantu untuk mengatur mengarahkan kepada bagian-bagian ini secara fleksible. Yang dimaksud disini mudah dan flexible adalah workflow bisa membantu untuk mencari bagian berdasarkan beberapa hal secara otomatis, seperti struktur organisasi (untuk mendapatkan urutan atasan yang akan menyetujui), kepala dari unit kerja, role untuk melakukan sebuah fungsi. Tanpa ada komponen yang mengatur Bagian-bagian ini, maka aplikasi Workflow akan menjadi rumit.

Apa itu alur kerja ?

Alur kerja atau bisnis proses adalah proses keluruhan dari kaitan tugas-tugas untuk sebuah tujuan. Tujuan disini adalah berupa tujuan bisnis (seperti sales order, maintenance support), administrasi (pengajuan cuti, interview), pengontrolan (pembelian, expense claim).

Apa perbedaan dari Aplikasi Workflow dengan Workflow Engine ?

Mungkin beberapa belum pernah mendengar istilah Workflow Engine, tapi tidak apa-apa karena akan dijelaskan dibagian ini. Sebuah aplikasi worfklow, dengan arsitektur yang benar, akan memisahkan antara fungsi tugas dan alur kerja dengan komponen lainnya (routing – komponen ke 2 dan bagian – komponen ke 3). Fungsi tugas dan alur kerja adalah merupakan komponen spesifik terhadap sebuah aplikasi workflow. Komponen ini akan berbeda-beda untuk setiap aplikasi workflow. Berbeda dengan 2 komponen lainnya yaitu routing dan bagian, dimana komponen ini bisa dibuat baku karena fungsinya yang baku. Nah kedua komponen ini yang bisa disebut sebagai Workflow Engine.

Tapi dalam banyak kasus, tidak semua aplikasi workflow dapat dipisahkan secara jelas antara aplikasi workflow dan workflow engine. Untuk aplikasi yang demikian bisa dikategorikan sebagai aplikasi workflow yang jelek. Kenapa hal ini bisa disebutkan demikian silahkan baca artikel Workflow Engine. Dalam artikel tersebut dijelaskan secara mendalam tentang apa itu Workflow Engine, apa saja kegunaan dari Workflow Engine, komponen dalam Workflow Engine dan fitur yang disediakan oleh Workflow Engine.

Contoh aplikasi Workflow

Apa saja contoh aplikasi workflow ? Bisa berupa aplikasi apa saja dengan ruanglingkup sebagai berikut:

1. Ada beberapa tugas, proses yang dikerjakan dalam aplikasi lebih dari 1 tugas, bukan hanya 1 tugas saja. Contoh yang hanya 1 tugas, pengentrian Jurnal Accounting, pengentrial hasil produksi, pengentrial penerimaan Invoice untuk dijadikan A/P. Contoh yang lebih dari 1 tugas, Jurnal Accounting membutuhkan persetujuan oleh unit kerja terkait dan fungsi untuk mengisi pembebanan cost center, Entry hasil produksi dengan persetujuan oleh bagian QC, Pencatatan A/P setelah mendapatkan persetujuan dari penerima barang. Jadi 1 buah bisnis proses bisa jadi sebuah aplikasi workflow atau tidak, tergantung dari proses bisnis-nya.
2. Ada beberapa bagian terkait, 1 proses tapi melibatkan beberapa bagian. Keterlibatan ini bisa berupa alur proses atau hanya sekedar sebuah persetujuan.

Berikut ini modul-modul yang terdapat dalam aplikasi PR/PO Workflow:

1. Budget: modul yang menangani proses persetujuan pembuatan budget, perhitungan penggunaan budget melalui PR, pengontrolan PR budget supaya tidak melebihi nilai budget
2. Purchase Requisition: modul yang menangani pembuatan permohonan PR atau pembuatan PR otomatis yang merupakan hasil MRP dari sistem lain, keterkaitan dengan budget, pengontrolan angka PR dengan budget, persetujuan PR sesuai besar dan tipe PR, pengisian detil spesifikasi produk, pencatatan hasil bidding, penunjukan pemenang bidding
3. Purchase Order: pembuatan PO berdasarkan PR yang sudah ditentukan pemenang bidding nya, pengisian perjanjian yang disetujui bersama pihak Supplier, persetujuan penerbitan PO, pencetakan PO, pencatatan penandatangan PO oleh salah satu Penyetuju, pengiriman PO disetujui ke sistem ERP
4. Good Receipt: pencatatan penerimaan untuk penerimaan yang dilakukan di aplikasi PR/PO Workflow, pencetakan Good Receipt untuk diserahkan ke Supplier, perhitungan penerimaan terhadap PO, pengiriman Jurnal Good Receipt ke ERP

MODUL BUDGET

Modul Budget adalah modul yang menangani tentang masalah budget. Budget dalam PR/PO adalah daftar perencanaan/budget seluruh pembelian yang direncakan untuk direalisasikan di tahun berjalan atau tahun berikutnya. Fitur dalam modul budget adalah:

1. Opening budget setiap awal tahun.  Opening budget ini bisa dilakukan persetujuannya didalam modul Budget atau alternatif nya proses persetujuan dilakukan diluar sistem, hasil dari persetujuan di entry ke dalam sistem untuk dipakai sebagai Opening Budget.
2. Revisi budget berupa penambahan kode budget baru: yaitu pengajuan budget baru untuk kode yang baru. Yang dimaksud kode budget baru adalah untuk tipe budget baru. Budget baru bisa muncul di tahun berjalan dikarenakan perubahan struktur organisasi, penambahan account biaya di accounting, perubahan proses kerja antar departemen
3. Revisi budget berupa penambahan terhadap kode budget yang ada, yaitu penambahan angka rupiah terhadap kode budget yang sudah ada. Kode budget tersebut adalah opening budget awal tahun atau revisi budget penambahan kode baru.

Berdasarkan transaksi diatas maka sistem akan memiliki value budget per masing-masing departemen per masing-masing account biaya/fix asset. Dalam hal account secara garis besar budget dibagi menjadi 3 bagian, yaitu: pembelian Capex, Opex dan pembelian untuk produksi (Raw/Packaging Material). Sedangkan dari sisi departemen adalah tentang Cost Center yang dicatat didalam ERP. Meskipun demikian Cost Center PR/PO bisa bebeda pengertiannya dengan Cost Center dalam ERP/Accounting. Dalam hal ini perbedaannya adalah skope atau skala. Biasanya Cost Center dalam aplikasi PR/PO lebih detil dibandingkan dengan yang ada dalam Accounting, karena keperluan dalam PR/PO lebih detil dibanding dengan Accounting.

Setelah sistem memiliki nilai budget, berupa total kalkulasi dari Opening Budget dan Revisi, selanjutnya nilai budget akan direalisasikan melalui pembuatan PR. Yang menjadi masalah adalah angka realisasi PR adalah angka yang sifatnya tentative atau berubah-ubah. Karena PR sendiri baru berupa permohonan dan belum berupa perjanjian pembelian antara Customer dengan Supplier. Jadi dalam hal ini budget harus bisa melakukan perhitungan menggunakan angka real sesuai perkembangan dari PR. Pada umumnya perubahan angka PR yang mungkin terjadi adalah:

1. Angka perkiraan awal oleh pemohon
2. Angka perkiraan oleh departemen terkait yang mengerti tentang barang yang akan dibeli
3. Angka penawaran awal dari Supplier
4. Angka final dari Supplier pemenang

Fitur kunci dari budget adalah pengontrolan pembukaan PR, dimana PR yang dibuat dengan menunjuk kode budget tertentu harus di kontrol supaya tidak melebihi nilai budget. Bagaimana jika PR yang dibuat melebihi sisa budget ? Solusi nya adalah dengan membuat alternatif PR Non Budget atau mengajukan revisi kode budget. Perbedaannya adalah PR Non Budget persetujuannya ada di dalam PR, sedangkan budget revisi persetujuannya ada di dalam budget revisi itu sendiri.

MODUL PURCHASE REQUISITION

Modul Purchase Requisition (PR) adalah modul yang menangani pembuatan permohonan pembelian berupa pengisian formulir Purchase Requisition (PR) baik secara manual atau otomatis hasil dari sistem lain. Yang dimaksud dengan manual adalah pengisian dilakukan didalam modul PR ini, sedangkan yang dimaksud dengan otomatis adalah pengisian dilakukan di sistem lain (fungsi MRP, Minimum Order, Direct Purchase, Work Order ke Third Party). Setelah pengisian dilakukan di sistem lain, maka PR akan diletakkan disebuah interface tabel, kemudian modul PR akan membaca interface tabel dan membuat PR berdasarkan isi dari Interface tabel tersebut disertai dengan validasi.

Seperti yang dijelaskan diatas bahwa PR adalah realisasi dari budget. Untuk itu maka dalam PR disediakan kolom untuk mengaitkan budget baik secara otomatis maupun manual. Otomatis hanya bisa dilakukan jika terdapat pattern tertentu seperti tipe biaya, sedangkan manual dilakukan oleh pemohon PR. Dalam hal keterkaitan dengan Budget, PR bisa dikategorikan menjadi 2, yaitu:

1. PR Budget: PR yang dikaitkan dalam budget dan angka sisa budget masih lebih besar atau sama dengan nilai PR
2. PR Non Budget: PR yang tidak bisa dikaitkan dengan budget dikarenakan belum ada kode budget atau sisa budget tidak mencukupi

Untuk itu pengontrolan angka PR ddibanding dengan sisa budget harus dilakukan secara realtime dan uptodate. Uptodate karena angka PR berubah-ubah dan status PR yang berubah-ubah yang berpengaruh terhadap sisa budget. Menurut pendapat pribadi, inilah fitur kunci dari aplikasi PR/PO Workflow dimana fitur ini (pengontrolan sisa budget berdasarkan perkembangan dari PR-PR yang terkait) tidak bisa dilakukan baik secara manual maupun menggunakan workflow PR/PO di ERP. Dalam hal ini bukan di proses persetujuannya yang tidak bisa tapi kepada perhitungan realtime-nya.

Aplikasi ini adalah workflow berarti semua proses persetujuan ada didalam aplikasi ini. Dalam hal ini fitur workflow yang disediakan adalah workflow dibuat flexible sesuai dengan peraturan Perusahaan. Biasanya panjangnya proses persetujuan tergantung dari angka PR, tipe barang yang dibeli, tipe atau status PR berdasarkan budget. Kesemua parameter ini bisa dipakai sebagai parameter kemana PR akan diteruskan untuk proses persetujuan.

PR adalah permohonan yang diisi oleh User. Ada user yang mengerti detil spesifikasi barang yang akan dibeli, tetapi ada juga yang tidak. Untuk itu didalam proses PR akan dilewati pengisian detil fitur barang yang akan dibeli, jika dibutukan. Dengan demikian maka PO yang akan dihasilkan akan berisi daftar barang yang secara spesifikasi lengkap atau tidak menimbulkan kesalahan interprestasi.

Proses bidding dalam aplikasi PR/PO dilakukan  di modul PR. Mungkin hal ini menimbulkan beberapa pertanyaan, kenapa baru PR sudah bidding ? Bukannya bidding adalah bagian dari PO ? Berikut ini alasan kenapa proses bidding ada di modul PR, yaitu karena angka dalam PR yang digunakan untuk memotong budget. Jadi angka dalam PR adalah angka yang sudah matang. Karena angka yang diharapkan adalah angka matang yang akan digunakan untuk memotong budget, maka proses bidding dimasukkan ke dalam modul PR. Jadi dalam hal ini cukup mengubah mind set saja dari proses bidding menjadi dalam PR. Sedangkan selebihnya tidak ada katian.

Meskipun demikian apakah angka final dari PR saat dibuatkan PO masih bisa diubah ? Jawabannya bisa, tapi hal ini membutuhkan proses approval ulang.

MODUL PURCHSE ORDER (PO)

Modul PO adalah modul yang menangani pembuatan PO berdasarkan PR yang sudah ditentukan final (sudah ada pemenang bidding nya). Dalam modul PO ini tidak diperkenankan melakukan pengubahan item barang, jumlah yang dibeli, spesifikasi, harga, currency, dst. Hal yang boleh diubah-ubah dalam PO adalah isi perjanjian diluar hal-hal diatas, seperti Term of Paymen, format pencetakan PO, penggantian Supplier, dst. Itinya perubahan yang boleh dilakukan di PO adalah perubahan yang tidak ada kaitannya dengan angka PO itu sendiri. Karena pemotongan budget hanya ada di modul PR. Jika ingin melakukan pengubahan yang berhubungan dengan angka, maka semuanya dilakukan di modul PR (dalam hal ini sub modul Item PO, jika PR sudah dalam status ACCOMPLIHSED).

Dalam modul PO meskipun sudah mencantumkan angka final, tetap akan melewati proses persetujuan. Persetujuan yang dimaksud adalah persetujuan menyangkut isi perjanjian (diluar item, harga dan jumlah barang yang dibeli). Selain itu karena tetap PO akan melewati proses pencetakan, karena ini menyangkut pihak luar jadi butuh PO fisik, maka proses petujuan juga meliputi persetujuan menerbitkan PO. Seperti halnya PR proses persetujuan ini bisa berjenjang tergantung pada angka, jenis barang dalam PO.

Pencetakan PO adalah mencetak PO yang sudah berstatus disetujui, baik secara PR (item, harga, jumlah) maupun isi perjanjian (term of payment). PO dicetak karena pihak Supplier masih membutuhkan bukti fisik dari PO. Selain itu karena PO adalah dikirim ke pihak Supplier, maka tetap akan melewati tandatangan fisik terhadap PO yang sudah dicetak.

Jika PO akan dilakukan proses penerimaan di sistem lain (ERP, EAM), maka fitur yang akan ada adalah pengiriman PO disetujui ke sistem lain secara otomatis.

MODUL GOOD RECEIPT

Modul Good Receipt (GR) adalah pencatatan penerimaan untuk penerimaan yang dilakukan didalam aplikasi PR/PO Workflow. Kenapa dijelaskan diterima di aplikasi PR/PO Workflow ? Karena tidak semua penerimaan ada di aplikasi ini, seperti yang dijelaskan di modul PR. Jadi ada penerimaan yang dilakukan di sistem lain, seperti pembelian Raw Material/Packaging Material dilakukan di ERP, pembelian Spare part dan Supplies dilakukan di Enterprise Asset Management (EAM). Nah seperti apa pembelian yang diterima di modul ini ? Biasanya penerimaan yang dilakukan di modul ini adalah untuk pembelian barang-barang yang tidak di kontrol secara stok, apakah itu ? Seperti barang fix asset, stationary, office supplies, dst. Fitur pencatatan penerimaan ini meliputi keterkaitan dengan PO, proteksi penerimaan tidak boleh melampaui PO. Proses penerimaan bisa dilakukan lebih dari 1 kali terhadap sebuah PO.

Proses lanjutan dari pencatatan penerimaan adalah pencetakan Good Receipt untuk diserahkan ke Supplier. Jadi tandaterima barang tidak boleh dikeluarkan dari sistem lain, karena kalau dari sistem lain atau manual bisa menimbulkan kesalahan dalam hal item atau jumlah.

Seperti halnya PR dan PO yang memiliki proses persetujuan atau approval, dalam hal GR pun ada proses persetujuan. Untuk apa ada proses persetujuan dalam GR ? Berikut ini adalah fungsi dan alasan persetujuan dalam GR:

1. GR dilakukan oleh departemen store
2. Departemen store menerima barang hanya berdasarkan PO (part dan jumlah)
3. Untuk memastikan barang diterima sesuai spesifikasi dibutuhkan persetujuan oleh pemohon barang atau pembuat PR
4. Selain itu pemohon perlu menerima notifikasi bahwa barang yang diminta dalam PR sudah ada di store

Setiap penerimaan barang akan menimbulkan transaksi di accounting. Nah salah fitur yang ada dalam modul ini adalah pembuatan  Jurnal Good Receipt secara otomatis ke ERP. Dengan proses otomatis, maka pencatatan journal akan realtime dan mengurangi Human Error.

Proses PR dan PO adalah merupakan bagian dari sebuah proses besar dalam ERP yaitu proses Procurement atau Pengadaan. Proses pengadaan lengkap meliputi proses seperti berikut ini:

1. Purchase Requisition (PR), yaitu permohonan persetujuan untuk pembelian barang atau service. Permohonan ini biasanya berhubungan dengan persetujuan pembelian tentang nilai dari barang yang akan dibeli (jumlah barang, harga barang), spesifikasi dari barang, maupun pengaturan cash, yaitu kapan barang akan dibeli. PR disetujui akan berlanjut ke proses PO.
2. Purchase Order (PO), yaitu proses pembelian barang atau jasa berdasarkan PR yang sudah disetujui. Proses yang terjadi dalam PO meliputi bidding untuk pemilihan Supplier termasuk didalamnya tentang detil kontrak, penerbitan PO itu sendiri yang sudah sesuai dengan kontrak dan ditandatangani oleh Pejabat berwenang sampai dengan dikirim dan dikonfirmasi oleh pihak Supplier.
3. Good Receipt/Service Receipt, yaitu proses penerimaan barang atau penyelesaian pekerjaan jasa berdasarkan PO yang sudah disetujui baik oleh pihak Pemesan (Customer)  maupun oleh pihak Supplier/Vendor. Proses detil dalam GR/SR adalah penerbitan surat tanda terima barang/jasa oleh bagian Store/Warehouse kepada Supplier/Vendor, persetujuan barang diterima oleh pemohon, pengakuan inventory ke dalam sistem.
4. Invoicing atau A/P, yaitu penerimaan Invoice yang diterbitkan oleh Supplier/Vendor sesuai dengan surat tanda terima barang/jasa (Receiving). Proses yang terjadi adalah mencocokkan antara Invoice dengan PO dan GR/SR, pencatatan A/P (pengakuan hutang) ke dalam sistem.
5. Payment, yaitu proses pembayaran A/P oleh Customer kepada pihak Supplier/Vendor. Proses yang terjadi adalah persetujuan pembayaran oleh Management dan dilanjutkan dengan proses pembayaran bisa berupa penerbitan Check/Giro atau melalui Cash/Transfer.
6. Retur, yaitu proses pengembalian barang dikarenakan berbagai alasan kepada pihak Supplier/Vendor. Retur bisa terjadi sebelum atau sesudah proses Payment dilakukan.

Kembali seperti dijelaskan ditulisan terdahulu, proses lengkap diatas hampir atau boleh dikatakan pasti sudah disediakan oleh aplikasi ERP atau Backend System manapun. Pertanyaannya adalah dimana letak proses yang dikerjakan didalam atau oleh Workflow ? Kalau ditinjau secara detil proses diatas, bisa dilihat bahwa ada banyak proses persetujuan (baca workflow) yang dibutuhkan sebelum transaksi terjadi dan bisa dicatat. Berikut ini adalah workflow yang mungkin terjadi dalam proses Procurement:

1. Purchase Requisition, yaitu workflow untuk persetujuan pembelian. Persetujuan dalam PR meliputi nilai barang yang akan dibeli (jumlah dan harga), spesifikasi barang yang akan dibeli, pengaturan cash flow (kapan barang dibeli), pengontrolan terhadap budget.
2. Purchase Order, yaitu workflow untuk penerbitan PO. Persetujuan dalam PO meliputi pemilihan Supplier/Vendor (bidding), pengecekan term dalam PO seperti jangka waktu pembayaran, perpajakan, pengiriman.
3. Good Receipt/Service Receipt, yaitu workflow untuk persetujuan penerimaan barang atau pengakuan penerimaan barang. Persetujuan dalam GR/SR adalah meliputi kesesuaian spesifikasi barang/jasa oleh pihak pemohon, pengecekan fisik barang oleh bagian Store/Warehouse.
4. Pembayaran A/P, yaitu persetujuan pembayaran Invoice. Persetujuan dalam Pembayaran A/P meliputi persetujuan kelengkapan dokumen (PO, GR/SR, Invoice), persetujuan pembayaran meliputi kesesuaian term, tanggal pembayaran (pengaturan cash flow).

Dari gambaran diatas sebenarnya ada banyak workflow terjadi dalam proses pengadaan ini. Pertanyaan berikutnya adalah bagaimana jadinya proses pengadaan di Backend system/ERP dikatikan dengan integrasi dengan aplikasi Workflow ? Berikut ini adalah salah satu skenario yang bisa dibangun oleh solusi Pengadaan beserta dengan proses workflow-nya:

Berikut ini penjelasan dari gambar diatas:

1. PR di aplikasi Workflow (Lotus Notes) bisa dimulai dari pembuatan PR di ERP atau Backend System untuk barang-barang inventory berdasarkan minimum stock yang diset. Semua barang yang termasuk dalam kriteria minimum stock atau stok sudah kurang dari standard inventory untuk di order, ditarik oleh aplikasi Workflow Lotus Notes sebagai Draft PR.
2. Selain dari langkah 1, PR juga bisa dimulai langsung di aplikasi Workflow Lotus Notes terutama untuk permintaan yang sifatnya tidak tersistem. PR berdasarkan permintaan User. Tipe PR ini bisanya untuk pembelian barang-barang non stock seperti Fix Asset, kebutuhan kantor (Stationary, Computer Supplies, dll.).
3. Berdasarkan kedua sumber PR diatas (langkah 1 dan 2), terbentuk permohonan PR yang akan diroute sesuai dengan Workflow yang sudah disetting. Workflow ini biasanya sifatnya berjenjang sesuai dengan isi dari PR tersebut. Misal untuk pengajuan diatas nilai tertentu persetujuannya sampai dengan Manager, sedangkan sampai nilai tertentu sampai General Manager, dan lebih dari itu sampai ke Direktur.
4. Jika PR yang diajukan disetujui, maka melalui proses pembuatan PO, maka PO akan terbentuk sesuai dengan PR yang sudah disetujui untuk selanjut nya melewati proses PO seperti permintaan Quotation, Bidding, dan Supplier selection. Setelah pemilihan Supplier ditentukan maka PO berstatus DISETUJUI yang berarti bisa dikirim ke Supplier dan dari sisi sistem, PO tersebut akan dikirim ke ERP/Back end System sebagai Approved PO sebagai dasar untuk proses pengadaan selanjutnya seperti Receiving, Invoicing, dan Payment.

ERP atau backend system yang pernah dibangun interface-nya dalam proyek-proyek sebelumnya adalah: CRM (Axapta), EAM by Infor, Protean by Infor. Dalam kasus CRM (Axapta) interface yang dibangun adalah pengiriman PO yang sudah disetujui untuk dipakai sebagai PO disetujui. Proses selanjutnya seperti Good Receipt, pembayaran akan dilakukan di CRM (Axapta) sedangkan di aplikasi PR/PO Workflow memonitor perubahan status untuk dicatat di sistem sebagai update informasi. Untuk EAM by Infor interface yang pernah dilakukan adalah aplikasi PR/PO Workflow mengambil PR hasil perhitungan minimum stok, direct purchase, work order yang dikerjakan oleh third party. PR otomatis dibuat berdasarkan PR yang dikirim oleh EAM di Interface. Setelah di proses di aplikasi PR/PO Workflow sampai menjadi PO, kemudian PO akan dikirim balik ke EAM untuk dipakai sebagai PO disetujui dan digunakan untuk pemrosesan selanjutnya seperti penerimaan barang, pembayaran. Untuk ERP Protean by Infor, interface yang dibuat adalah seperti untuk CRM (Axapta), yaitu PR dibuat di aplikasi PR/PO Workflow, setelah PO disetujui akan dikirim ke Protean sebagai PO disetujui untuk pemrosesan selanjutnya seperti Penerimaan Barang, Pembayaran.

Demikian fungsi integerasi antara ERP/Back end system dengan aplikasi Workflow (dalam hal ini dibangun diatas platform collaboration seperti Lotus Notes software). Nantikan tulisan selanjutnya tentang detil fitur dalam aplikasi Workflow PR/PO.

Apa itu Workflow Engine dan bedanya dengan Aplikasi Workflow ?

Secara umum aplikasi workflow adalah aplikasi yang didalamnya ada proses routing atau perpindahan dokumen/record dari satu orang atau bagian ke orang atau bagian yang lain. Proses routing ini yang diartikan sebagai workflow. Sebuah aplikasi workflow mengandung 2 bagian besar, yaitu dokumen/record yang dirouting atau dialirkan dan bagian kedua adalah komponen untuk mengalirkan dokumen/record itu sendiri. Komponen untuk mengalirkan dokumen/record ini yang dinamakan Workflow Engine.

Semua aplikasi workflow pasti memiliki “workflow engine”, tetapi tidak semua aplikasi workflow membagi 2 bagian ini secara jelas. Aplikasi workflow yang baik adalah aplikasi workflow yang memisahkan 2 komponen tersebut dengan jelas. Artinya urusan routing adalah urusan workflow engine dan urusan dokumen atau record adalah urusan pembuatan form/proses. Sebagai User, pada umumnya, tahunya aplikasi workflow adalah sebuah aplikasi saja karena urusan workflow engine memang adalah urusan Software House atau Developer. Akibatnya sering kali Workflow Engine ini tidak pernah menjadi pertimbangan apapun dalam membangun aplikasi workflow dan bahkan tidak dimasukkan kedalam spesifikasi Software yang akan dibeli. Kenyataannya diawal penggunaan aplikasi workflow memang tidak ada masalah, tapi pada saat mulai masuk ke maintenance, pembuatan aplikasi workflow selanjutnya, perubahan routing barulah muncul masalahnya. Tapi sering kali inipun masih bisa disembunyikan oleh pihak Software House atau Developer dengan tetap melakukan support. Berikutnya yang terjadi adalah User menjadi tergantung pada Software House tersebut, dalam hal ini yang dipermasalahkan adalah ketergantungan untuk hal-hal yang bukan essensial, bukan pada perubahan yang mendasar. Jadi untuk itu pertimbangkanlah dengan matang-matang untuk menggunakan Workflow Engine dalam membangun aplikasi workflow.

Berikut ini adalah penjelasan terminologi dari dokumen/record dan form/proses untuk memperjelas. Yang dimaksudkan dengan form/proses adalah komponen software berupa coding untuk membuat layar entry/editing data, proses perhitungan, penanganan data/record, pencetakan laporan dan/atau proses otomatisas. Sedangkan yang dimaksud dengan dokumen/record adalah data yang dihasilkan dari form/proses yang biasanya disimpan dalam database. Dokumen/record adalah data yang dialirkan dan form/proses adalah sarana untuk menampilkan kepada user atau melakukan proses perhitungan dari data (dokumen/record). Workflow engine adalah coding atau setting untuk menentukan aliran dokumen/record yang ditampilkan mengunakan form yang merupakan pendefinisian dari bisnis proses.

Apa saja kegunaan Workflow Engine ?

Kegunaan dari Workflow Engine adalah untuk menangani masalah routing secara terpisah dari coding form/proses. Dengan pemisahaan ini maka ada beberapa keuntungan yang akan didapat, yaitu:

1. Mengubah routing tidak berarti mengubah coding. Semua Workflow Engine memiliki setting tersendiri dalam mendefinisikan alirannya. Ada Workflow Engine yang mendesign alirannya menggunakan GUI, seperti membuat workflow di Visio, atau yang hanya menggunakan text saja. Keduanya tidak ada masalah karena perubahan hanya dilakukan di Workflow Engine saja. Adalah sangat baik Workflow Engine yang memiliki GUI untuk mengubah alirannya, atau setidaknya ada tabel yang bisa diubah oleh User dengan sedikit pengetahuan. Sedangkan workflow engine yang jelek atau Aplikasi Workflow tanpa Workflow Engine adalah mengubah routing langsung ke coding.
2. Single Workflow Engine code. Jika aplikasi workflow menggunakan workflow engine, biasanya pada saat akan membangun aplikasi workflow berikutnya, workflow engine ini akan bisa digunakan lagi. Sedangkan aplikasi workflow tanpa workflow engine akan “membangun ulang atau menggunakan workflow engine dengan coding berbeda” untuk aplikasi workflow yang baru. Akibatnya ada 2 maintenance yaitu maintenance coding form/proses dan masing-masing workflow engine. Dan umunya workflow engine yang ada dalam aplikasi akan banyak bugs karena menyatu dengan form/proses. Sedangakan workflow engine itu biasanaya ibarat black box yang sudah teruji karena secara natural dibuat terpisah dan teruji dipakai dibeberapa aplikasi.
3. Single table routing. Pada penjelasaan berikutnya di komponen workflow, salah satu komponen adalah tabel struktur organisasi. Jika menggunakan workflow engine maka pastinya akan menggunakan 1 struktur organisasi yang sama untuk semua workflow. Jika ada perubahan cukup mengubah 1 table akan berdampak ke semua workflow.

Komponen apa saja yang ada dalam Workflow Engine ?

Berikut ini adalah komponen yang ada didalam workflow engine:

1. Pembuatan routing atau pendefinisian proses bisnis. Seperti yang dijelaskan sebelumnya, komponen ini bisa menyediakan versi GUI, tabel, atau yang buruk adalah mengubah coding. Hasil dari komponen ini adalah versi elektronik yang dimengerti oleh workflow engine dari proses bisnis.
2. Tabel workflow. Tabel yang disetting untuk keperluan workflow seperti struktur organisasi, role, delegasi, dst. Tabel ini akan digunakan oleh coding workflow engine untuk menentukan penyetuju atau pemilik aktivitas dari workflow.
3. Coding workflow engine. Adalah sebuah coding yang bisa membaca hasil dari pendefinisian proses bisnis (komponen no. 1 diatas) untuk mengaliarkan dokumen/record yang ditampilkan/diolah oleh coding form/proses kepada user atau penyetuju sesuai dengan setting yang ada dalam tabel workflow (komponen no. 2)

Apa saja fitur yang disediakan oleh Workflow Engine ?

Berikut ini adalah fitur-fitur yang umumnya disediakan dalam sebuah workflow engine:

1. Delegation. Yaitu proses Delegasi untuk User yang tidak memungkinkan mengerjakan workflow untuk jangka waktu tertentu.
2. Re-Assign workflow. Proses untuk mencari ulang nama pemilik aktivitas atau penyetuju ke dalam tabel workflow, biasanya jika terjadi perubahan tabel workflow setelah proses penunjukan penyetuju atau pemilik aktivitas ditentukan.
3. Re-state. Proses pemindahan workflow ke proses sebelum atau sesudahkanya dikarenakan terjadi stagnasi.
4. Workflow History. Tampilan layar untuk menjelaskan tindakan workflow yang sudah dilakukan sampai sekarang.

Jika ada memiliki kebutuhan Aplikasi Workflow atau Workflow Engine diatas Lotus Notes silahkan menghubungi saya di mailto:gunawan@workflow-solution.com

1. Permohonan disetujui oleh atasan pemohon karena terkait pada biaya yang akan ditimbulkan dari pengerjaan order tersebut
2. Permohonan akan masuk ke satu pintu, misalnya helpdesk team, untuk pengaturan atau filter awal penyelesaian permohonan
3. Permohonan akan masuk ke Team Leader untuk pengaturan penugasan ke teknikal yang kompeten dan load balancing (pemerataan beban pekerjaan)
4. Teknikal mengerjakan layanan dan memasukkan hasil pekerjaan sebagai sarana untuk pelaporan dan suatu saat bisa digunakan sebagai knowledge untuk pengerjaan yang sama di lain waktu
5. Persetujuan penyelesaian pekerjaan oleh pemohon sebagai sarana untuk konfirmasi penyelesaian dan juga bisa digunakan untuk pemberian feedback pengerjaan

Dengan melihat proses diatas maka aplikasi ticket/helpdesk/work order adalah kasus yang cocok dibuatkan workflow-nya, karena bisnis proses panjang dan bisa bervarisi.

Dalam proyek-proyek sebelumnya dari aplikasi Ticket/Helpdesk/Work Order, ada beberapa fitur yang berbeda-beda yang dibutuhkan oleh Perusahaan. Perbedaan ini dikarenakan perbedaan bisnis, perbedaan kebutuhan karena fokus yang berbeda, dan/atau perbedaan penerima jasa layanan atau user. Perusahaan yang bergerak khusus dibidang jasa layanan, dalam hal ini jasa layanan menjadi bisnis, memiliki kebutuhan fitur yang berbeda dibandingkan perusahaan yang jasa layanannya ditangani oleh internal dari perusahaan tersebut. Berikut ini adalah beberapa fitur-fitur yang pernah dibangun:

1. Charging. Penghitungan jumlah jam kerja yang dihabiskan untuk mengerjakan permohonan, karena Perusahan/Unit Kerja tersebut “menjual” jasa layanan kepada Perusahaan/Unit Kerja dari Pemohon.
2. SLA atau Service Level Agreement. Perhitungan otomatis waktu pengerjaan terkait pengukuran terhadap SLA yang sudah disepakati.
3. Knowledge Base Management, yaitu menyimpan pengetahuan tentang problem/solve terhadap permasalahan yang sering timbul.
4. Inventory, pengaturan inventory spare-part yang digunakan dalam layanan. Fungsi dari inventory ini adalah sebagai laporan stok, charging atau log jumlah pemakaian spare-part oleh pengguna layanan, pengajuan pembelian stok.
5. Asset, menyimpan informasi asset yang ditangani dalam pelayanan dalam hal ini adalah data detil tentang asset sebagai data awal untuk melakukan perbaikan, perhitungan jumlah work order yang sudah pernah dilakukan terhadap asset tersebut untuk menghitung effektifitas perbaikan.
6. Purchasing, menangani pembelian spare part dari inventory, spare part khusus terkait Work Order, dan Asset baru. Pembelian meliputi persetujuan Purchase Requisition, bidding, dan pembuatan/pencetakan Purchase Order.

Ditulisan berikutnya akan dijelaskan secara mendetil contoh dari tiap-tiap fitur diatas.

Jika ada pertanyaan silahkan hubungi mailto:gunawan@workflow-solution.com

Ticket/Helpdesk/Work Order untuk kebutuhan maintain spare part

Dengan adanya kebutuhan tersebut bisa saja kemudian aplikasi inventorynya dibuat menggunakan RDBMS, tetapi problemnya aplikasi menjadi tidak integrated. Dengan alasan integrated itulah, maka dibuatkan aplikasi Inventory ini. Hasilnya jalan dan menjawab kebutuhan yang ada.

Berikut capture screen aplikasi inventory untuk Helpdesk:

Challenges berikutnya datang untuk membuat aplikasi yang khusus berhubungan dengan Inventory system dan lucunya butuh workflow didalamnya. Aplikasinya adalah inventory system untuk konsinyasi. Workflow dibutuhkan untuk pengakuan okay oleh pihak terkait untuk benar-benar memotong inventory. Jadi kasusnya demikian, pihak supplier meletakkan barang konsinyasi di outlet, outlet setiap kali ada pemakaian melaporkan melalui sistem, kemudian laporan tersebut diteruskan atau di-workflow-kan ke bagian terkait untuk dibuatkan invoice-nya.

Berikut capture screen aplikasi inventory konsinyasi:

LS:DO- Cannot convert data from native to expected or requested datatype

Error diatas terjadi jika akan me-retrive field bertipe nvarchar, sedangkan untuk mengakses field dengan tipe lain tidak ada masalah. Error baru muncul setelah melakukan akses terhadap field, melalui odbcresultset.GetValue(), sedangkan pada saat melakukan query tidak terjadi error.

Untuk fixing bisa melalui 2 cara:

1. Membuat view di MS-SQL dengan mengconvert tipe nvarchar menjadi varchar. Formula untuk meng-convert field type adalah melalui CAST(fieldname as varchar(99)) as newfieldname
2. Pada saat melakukan query SQL langsung dilakukan convert field type nya melalui SQL command CAST. Contoh: SELECT CAST(name as varchar(50)) as name, CAST(address as varchar(100)) as address from tablename

Sumber: Notes/Domino 4 and 5 Forum

Issue selanjutnya adalah apakah user pasti membutuhkan workflow engine untuk membangun aplikasi workflow ? Jawabannya adalah ya, karena:

1. Development time, waktu yang dibutuhkan oleh membuat routing dalam aplikasi workflow adalah kira-kira 10-30% dari total project. Jadi jika menggunakan workflow engine, kira-kira waktu yang bisa di-reduce adalah 10-30%.
2. Live support, seperti dijelaskan sebelumnya salah satu komponen workflow engine adalah struktur organisasi/role, tabel ini harus di maintain, jika ada lebih dari 1 workflow dan masing-masing aplikasi memaintain tabel-nya masing-masing, maka support yang dihabiskan oleh admin akan lebih banyak dan rumit.
3. Maintenance cost, setiap coding membutuhkan maintenance, maintenance berbicara tentang biaya dan skill, dengan adanya “workflow engine” di masing-masing aplikasi berarti biaya dan skill yang dibutuhkan juga mahal dan banyak.

Hal-hal tersebut diatas belum lagi ditambahkan bahwa hampir semua corporate yang meng-implement aplikasi workflow, tidak mungkin hanya melakukan untuk 1 workflow saja. Nah berarti sangat baik atau worth untuk memiliki atau membeli workflow engine untuk membangun aplikasi workflow.

Selanjutnya apakah layak untuk membeli Lotus Workflow Engine ? Nah untuk yang ini jawabnnya pasti tidak, karena:

1. Discountinue, sayangnya Lotus Workflow Engine sudah distop pengembangannya oleh IBM. Ada beberapa personal jugdment menurut saya kenapa IBM mematikan produk ini, tapi tentu tidak baik saya menjelaskannya di forum terbuka seperti ini, belum lagi saya juga “makan” dari IBM
2. Mahal, memang mahal itu relative tapi jika ada yang free kenapa pakai yang beli

Apa maksud free ? Saya sendiri sejak awal membangun aplikasi workflow sudah terpikir untuk membuat workflow engine. Dan memang juga sudah diwujudkan, yaitu sejak tahun 1998, dimana waktu itu masih bekerja di salah satu BP IBM, sudah berhasil membangun workflow engine meskipun masih sangat sederhana. Saat ini workflow engine itu sudah saya kembangkan dan disemua project workflow engine ini selalu menemani dan tidak pernah mengalami kendala atau membutuhkan perubahan. Dan workflow engine ini saya hargai “free”.

Jadi jika membutuhkan workflow engine untuk mengganti Lotus Workflow mungkin saya bisa membantu dan harga untuk workflow engine yang ditawarkan adalah “free”. Berikut ini adalah beberapa project yang pernah dibuat yang menggunakan Lotus Workflow:

1. Perjalanan Dinas (2001)
2. Director Minutes of Meeting (2010)