Sepotong buku teks tentang pemrograman bisnis.
Proses perbatasan adalah yang terbaik secara otomatis. Kedengarannya klise, tetapi rekomendasi seperti itu masih jauh dari selalu dilaksanakan.
Situasi masih umum ketika proses melintasi perbatasan tanpa menggunakan sistem otomatis. Di banyak perusahaan, memo kertas, aplikasi, pesanan, dll sedang digunakan. Tentu saja, ini tidak hanya berlaku untuk batas antara departemen - karyawan dari layanan yang sama juga berdosa dengan selembar kertas.
Jika satu karyawan menyerahkan proses ke yang lain dalam bentuk kertas, melacak status tugas ini sangat sulit. Metode dasar, luas kehilangan tugas semacam itu diungkapkan dalam ungkapan "bersih di bawah kain". Ada baiknya jika karyawan menumpukkan kertas seperti itu di desktopnya - maka volume aplikasi setidaknya terlihat. Secara teoritis, selembar kertas tertentu dalam tumpukan ini bahkan dapat ditemukan, dan tentukan sudah berapa lama antrian ini.
Metode mentransfer proses melalui email juga umum. Sayangnya, pendekatan ini juga tidak bagus. Dalam arti tertentu, itu bahkan lebih buruk daripada setumpuk kertas, karena klien email tidak memiliki fungsionalitas yang memadai untuk mengelola surat sebagai tugas. Seseorang hanya akan memiliki segunung surat, yang hampir tidak mungkin untuk menentukan keadaan antrian.
Tentang pemindahan tugas secara lisan dan tidak layak dibicarakan. Seperti yang mereka katakan, terbang ke satu telinga, terbang ke yang lain.
Ada momen tidak menyenangkan lain yang terkait dengan pengetahuan tentang perbatasan. Ketika satu orang telah menyerahkan tugas kepada orang lain - di atas kertas, secara lisan atau melalui email - maka pembawa tugas sekarang menjadi milik orang kedua. Dari sudut pandang formal, moral, dan sering teknis, yang pertama tidak bisa lagi mempelajari tugas-tugas yang kedua. Dengan struktur subordinasi tertentu, Anda tentu saja dapat menggali lebih dalam tumpukan kertas, tetapi membaca email orang lain sudah terlalu banyak. Entah bagaimana masih mungkin untuk mengetahui keadaan satu atau lebih aplikasi Anda, contoh proses Anda, tetapi hampir tidak mungkin untuk menilai keadaan umum antrian “di perbatasan”.
Jadi, kita memerlukan sistem kontrol perbatasan otomatis. Ini memiliki beberapa persyaratan penting.
Persyaratan pertama adalah bahwa sistem harus secara jelas mengidentifikasi antrian dan tugas di dalamnya. Bahkan dalam sistem otomatis yang dikembangkan, ini tidak selalu memungkinkan. Jika Anda meminta seseorang untuk menunjukkan pergantian tugasnya dalam program, ia akan dapat menunjukkan sesuatu - ia akan menunjukkan daftar dokumen, menerapkan beberapa filter dan penyortiran, dan Anda mendapatkan daftar tugas. Jika Anda bertanya kepada programmer, ia akan melakukan hal yang sama, hanya saja tidak ada dalam daftar dokumen, tetapi, kemungkinan besar, dengan menanyakan data.
Ungkapan kunci di sini adalah "jika Anda bertanya." Dan jika Anda tidak bertanya? Untuk seorang programmer bisnis, pertanyaan sederhana ini (“bagaimana jika Anda tidak bertanya?”) Dapat menjadi kriteria yang jelas untuk identifikasi perbatasan yang benar. Jika Anda, sebagai pengamat luar, dapat, tanpa meminta karyawan, melihat daftar tugasnya, maka persyaratan pertama terpenuhi - antrian diidentifikasi.
Dengan kesederhanaan yang tampak dari kriteria ini, Anda akan menemukan bahwa kebanyakan sistem otomatis tidak memenuhinya. Memahami antrian seperti itu hanya di kepala seorang karyawan, bahkan di bawah Tsar Gorokh dan memo kantor, tetap dalam sistem otomatis. Situasi ini akrab dan tampak normal, karena "semua orang memilikinya". Tetapi jika Anda, sebagai programmer bisnis, ingin meningkatkan proses ini, maka Anda harus melakukan identifikasi antrian.
Persyaratan kedua adalah bahwa antrian harus didekomposisi sebelum tugas, mis. untuk entitas sederhana yang membutuhkan tindakan yang bisa dimengerti. Terjadi bahwa antrian tampaknya diidentifikasi, tetapi tugas-tugas dari berbagai proses dicampur di dalamnya. Dalam hal ini, kemampuan kontrol dan kemampuan kontrol antrian adalah pertanyaan serius.
Kriteria sederhana: jika Anda, tanpa meminta seorang karyawan, dapat memberi tahu Anda untuk setiap tugas spesifik apa yang perlu dilakukan, maka antrian diurai dengan benar. Jika jawabannya "perlu dipahami", atau "perlu untuk memperbaikinya", atau "belum melihat", maka penguraiannya buruk. Sistem, dan prosesnya, terus bergantung pada karyawan.
Persyaratan ketiga adalah bahwa prioritas untuk menyelesaikan tugas harus jelas. Prinsipnya sama dengan kriteria sebelumnya. Jika Anda, melihat antrian dari samping, melihat urutan tugas, maka prioritasnya jelas. Jika Anda, atau konsumen proses, perlu bertanya kepada karyawan tentang prioritas, atau mengatur ulang prioritas ini setiap hari, maka antriannya tidak dikelola dengan baik.
Persyaratan keempat adalah bahwa waktu yang dihabiskan oleh tugas dalam antrian, yaitu Prinsip "Gunung Es" diterapkan. Waktu yang dihabiskan biasanya terkait dengan prioritas eksekusi, tetapi ada juga konflik.
Misalnya, sistem prioritas dibangun berdasarkan penyortiran ganda - pertama pentingnya, kemudian tanggal tugas. Dalam hal ini, dengan volume besar tugas-tugas penting, itu tidak akan pernah mencapai yang tidak penting. Jika prosesnya sedemikian rupa sehingga kekal pemenuhan beberapa tugas dianggap sebagai norma, maka tidak apa-apa. Tapi, sebagai aturan, dalam proses streaming, penting untuk menyelesaikan semua tugas.
Oleh karena itu, pengaruh timbal balik antara prioritas dan waktu yang dihabiskan dalam antrian harus dipantau. Misalnya, setelah menetapkan sistem prioritas, tambahkan koefisien bobot ke waktu yang dihabiskan dalam antrian, sehingga pada nilai tertentu, tugas akan mengambang ke permukaan, terlepas dari pentingnya.
Jadi, kriterianya sederhana: jika Anda melihat setiap tugas memiliki waktu dalam antrian, maka persyaratannya terpenuhi. Kesalahan umum adalah pendapat bahwa itu cukup untuk mengetahui dan melihat tanggal dari pernyataan masalah, karena dalam kasus ini waktu yang dihabiskan dalam antrian dapat dengan mudah dihitung. Otomasi sangat mudah dilakukan. Tetapi menghitung dalam pikiran jauh lebih sulit, dan tidak satu pun karyawan waras yang akan melakukan ini. Oleh karena itu, waktu yang dihabiskan dalam antrian tidak akan diperhitungkan dalam pekerjaan.
Persyaratan kelima adalah tidak peduli seberapa usang, tetapi pelaksana tugas harus diketahui. Jika pilihan kontraktor diatur oleh algoritma otomatis, maka momen ketika algoritma ini dijalankan harus dipahami.
Selama tugas tidak memiliki pelaksana, itu tidak akan diselesaikan. Kontraktor tidak harus ditugaskan untuk setiap tugas khusus - cukup untuk memahami bahwa solusi untuk semua tugas dari antrian yang diidentifikasi ditugaskan kepada orang tertentu.
Pilihan kontraktor sering menyebabkan antrian menjadi menganggur dalam kasus di mana kontraktor dalam proses tidak menunjuk orang tertentu, tetapi posisi atau departemen. Dalam hal ini, direkomendasikan bahwa pilihan pelaksana dilakukan sebagai tugas terpisah, yang harus dilakukan manajer atau operator tertentu. Meskipun pilihan kontraktor bukanlah tugas, tetapi hak istimewa, antrian akan terus macet pada titik ini.
Kriteria sederhana: melihat dari sisi garis, Anda harus tahu persis siapa yang akan melakukan tugas itu.
Persyaratan keenam , dari area pemrograman bisnis yang lebih tinggi: sistem harus dapat melihat dan membandingkan antrian dari berbagai proses. Dalam kasus umum, persyaratan seperti itu tidak pernah dipenuhi, jadi kita hanya bisa berbicara tentang tingkat kepatuhan.
Masalahnya, biasanya, adalah bahwa antrian, tugas, dan proses yang berbeda adalah entitas sistem yang berbeda, dengan sekumpulan properti yang terpisah. Ada contoh proses dalam satu antrian, tetapi tidak dalam yang lain. Satu tugas memiliki tanggal produksi, sedangkan yang lainnya tidak. Dll
Mengingat keragaman entitas, biasanya tidak ada yang menyelesaikan tugas mengendalikan semua antrian "dalam satu jendela" - baik dalam sistem otomatis, maupun dalam kontrol manual. Oleh karena itu, keadaan antrian - baik instan dan metrik per periode - tetap menjadi misteri, yang mengurangi efektivitas manajemen dan analisis.
Sebagian bantuan adalah sistem kontrol proses yang "merangkai" berbagai dokumen utama menjadi entitas tunggal. Ini adalah bagaimana kartu proses, tugas umum dan entitas pengalamatan muncul.
Tetapi untuk seorang programmer bisnis, sayangnya, pendekatan ini sangat tidak cocok.
Pertama, penerapan proses biasanya mengarah pada komplikasi otomatisasi - tidak begitu banyak dari periode pengembangan sebagai perubahan selanjutnya. Proses, dengan kartu, pelaksana, tindakan dan kondisi, dengan sendirinya, adalah objek otomatisasi, dengan semua konsekuensi yang terjadi - kebutuhan untuk pemeliharaan, debugging, koordinasi, dll.
Kedua, gambaran nyata dari proses, sebagai suatu peraturan, tidak dapat ditarik karena konflik “satu-banyak”. Sebagian besar sistem gambar proses ingin satu objek berjalan pada satu waktu, bahkan jika objek tersebut berganda.
Misalnya, proses mengeksekusi daftar permintaan pembelian. Jika Anda menggambar peta ujung ke ujung dari proses ini, ternyata aplikasi yang sama berjalan dari awal hingga akhir. Pemasok yang sama, dilihat dari peta proses, harus bekerja dengan setiap aplikasi secara terpisah, sebagai bagian dari contoh proses.
Pada kenyataannya, pemasok sama sekali tidak berpartisipasi dalam proses ujung ke ujung. Dia memiliki kartu sendiri, di pintu masuk yang merupakan array aplikasi. Selain itu, setiap hari - dengan volume yang berbeda (termasuk, kadang-kadang, kosong). Setelah menjalankan aplikasi spesifik dari instance pertama itu, manajemen kembali ke proses tunggal.
Proses seperti itu hanya dapat ditarik menggunakan proses bersarang, yang biasanya berhasil, tetapi kesederhanaan dan kejelasan algoritma hilang - itu menjadi teknis, dapat dimengerti oleh programmer, tetapi tidak cocok untuk orang hidup dan manajemen.
Ketiga, proses-proses semacam itu rentan terhadap birokratisasi - mereka berusaha menjadikannya “beton bertulang”, berkoordinasi, mencetak, dan meletakkannya di rak. Pendekatan ini bertentangan dengan prinsip-prinsip otomasi cepat dan, oleh karena itu, tidak cocok untuk pemrograman bisnis. Proses konkret, terutama selama periode debugging, sama dengan mencetak kode program.
Dan, keempat, pengembang mekanisme untuk proses menggambar, hanya dipandu oleh logika programmer, tidak menyediakan alat manajemen antrian. Dengan demikian, untuk menganalisis semua garis di perbatasan, untuk membandingkannya satu sama lain, saat bepergian tidak akan berfungsi. Anda masih harus menemukan alat Anda sendiri.
Metode menggambar "beton bertulang" proses dapat digunakan sebagai alat bantu, tidak akan ada banyak bahaya. Atau, dapat digunakan pada akhir proyek, sebagai cara untuk melestarikan proses yang dikonfigurasi. Sampai proyek selanjutnya.
Namun, jangan lupakan poin ketiga - kecenderungan birokratisasi. Jika menurut Anda Anda dapat mempertahankan sistem untuk sementara waktu, maka karyawan dan manajer lainnya memiliki pendapat yang berlawanan: jangan menyentuh apa yang berhasil. Sistem yang dibuat, didebug dan diimplementasikan oleh Anda akan mulai melawan Anda.
Jauh lebih baik menggunakan prinsip "Tugas Otomatis" atau serupa ketika sistem Anda memiliki entitas yang dapat "melampirkan" ke proses yang sedang berlangsung dan membangun tugas dalam antrian. Prinsip itu sendiri akan dipertimbangkan kemudian.
Sebuah entitas tunggal untuk mengelola antrian di perbatasan memberikan, pertama-tama, sistem koordinat tunggal - metrik semua proses dalam unit yang sama. Setiap proses dapat dievaluasi - baik secara instan maupun dalam retrospeksi - pada skala yang sama.
Evaluasi instan dapat diimplementasikan, misalnya, dalam panel kontrol proses umum. Tidak dalam peta proses umum tradisional, yang tidak dapat dilihat pada satu layar tanpa menggulir, tetapi dalam bentuk daftar sederhana, bahkan tanpa angka, menggunakan tampilan warna, seperti lampu lalu lintas. Ini akan menghasilkan daftar dua kolom: proses dan status.
Opsi ini sedikit lebih menarik - bukan daftar proses, tetapi daftar poin masalah. Intinya, dalam hal ini, adalah autotask, simpul tertentu dari proses tertentu, yang jelas dapat dibandingkan dengan kehidupan. Misalnya, "perjanjian kontrak oleh pengacara". Cukup dengan mendaftar semua poin, menunjukkan statusnya, dan mengurutkannya sehingga poin yang paling bermasalah muncul di bagian atas.
Penilaian seketika atas semua proses, terlepas dari kesederhanaan dan kejelasannya, sangat jarang. Sekarang kamu mengerti kenapa.
Analisis antrian retrospektif adalah kejadian yang bahkan lebih jarang terjadi karena kebanyakan sistem tidak mengandung data yang diperlukan sama sekali. Data tersebut hanya tersedia jika prinsip Iceberg sepenuhnya digunakan, ketika tidak hanya waktu keadaan sesaat disimpan, tetapi juga sejarahnya.
Secara umum, seperti yang Anda lihat, tidak ada yang rumit dalam mengotomatisasi kontrol perbatasan. Penting untuk tidak membuat kesulitan secara artifisial menggunakan proses "beton bertulang" dan mengabaikan prinsip-prinsip otomatisasi cepat. Pendekatan dan kriteria yang perlu Anda gunakan saat mengotomatiskan keadaan batas proses sekarang diketahui oleh Anda.