Ada hal seperti itu di dunia, yang disebut "pemrograman bisnis." Aku belum memberitahumu tentang dia. Dan saya tidak yakin Anda akan tertarik.
Pemrograman bisnis adalah pemrograman bisnis sebagai suatu sistem. Apakah Anda memprogram sesuatu? Layanan di sana, situs web, aplikasi seluler, sistem perusahaan. Dia bekerja, tidak menyentuh siapa pun, dan Anda, sekali, mengubah sesuatu, dan itu menjadi lebih baik, lebih cepat, lebih nyaman. Ya, atau ... Apa pun bisa terjadi.
Demikian pula, Anda dapat mengubah bisnis, prinsipnya sama. Hanya ada perbedaan dalam detailnya. Misalnya, ada orang yang tidak mau melakukan apa-apa. Dan mereka bahkan tidak ingin mendengarkan Anda. Dan mereka sama sekali tidak menginginkan apa pun, kecuali gaji, serangkaian tentang polisi dan piva.
Singkatnya, artikel ini bersifat eksperimental. Senang - saya akan menulis lebih banyak. Saya memiliki seluruh buku teks tentang pemrograman bisnis. Jangan suka - persetan dengan dia, aku akan bertahan hidup. Jadi, ayo pergi.
Kemampuan untuk menganalisis dan mengoptimalkan proses adalah salah satu kunci bagi seorang programmer bisnis. Dan itu sangat berhasil bertepatan bahwa bekerja dengan proses adalah bagian yang paling sederhana, paling dimengerti dan mudah direproduksi dari seluruh teknik pemrograman bisnis.
Mungkin karena proses internal perusahaan, pada dasarnya, sangat mirip dengan proses yang terjadi dalam sistem teknik, termasuk dalam solusi terapan, seperti konfigurasi 1C. Di mana-mana ada awal, selesai, tindakan, pemain, kondisi, transisi dan pengembalian. Dalam perangkat lunak, tentu saja, para pelaksananya bukanlah manusia, tetapi kumpulan objek yang lebih luas - dokumen, modul, server, berbagai program, node dari sistem terdistribusi, dll.
Kesamaan prinsip-prinsip proses memberikan kesimpulan penting - metode optimasi sebagian besar identik, serta persyaratan untuk proses. Misalnya, proses manusia dan perangkat lunak harus berjalan dengan cepat. Seseorang tidak ingin menunggu pelaksanaan aplikasi ke unit tetangga selama lebih dari satu hari, dan kepala akuntan tidak ingin menunggu perhitungan biaya selama lebih dari 15 menit.
Publikasi yang Anda baca adalah kutipan dari buku teks tentang pemrograman bisnis. Kemungkinan besar berbeda dari publikasi saya sebelumnya, seperti Itu tidak menghibur, memotivasi atau provokatif. Ini hanya pernyataan dari metode yang konkret, dapat dipahami, sederhana dan mudah diterapkan.
Metode jalur renang
Metode lane renang adalah alat yang baik untuk menganalisis proses. Inilah metode analitiknya, karena dia tidak mengatakan apa yang perlu diubah dalam proses, tetapi memungkinkan Anda untuk dengan mudah dan cepat melihat sumber masalah potensial.
Ini terutama berlaku untuk proses lintas fungsional - di mana dua atau lebih unit fungsional atau tim berpartisipasi - secara umum, di mana proses melintasi beberapa batas.
Mari kita lihat sebuah contoh. Katakanlah kita memiliki proses tertentu - pengadaan pesanan. Manajer penjualan menerima aplikasi dari klien, manajer pengadaan harus menemukan pemasok, mengetahui harga dan ketentuan, mengoordinasikannya dengan penjual kami, mendapatkan faktur pembayaran, memberikannya ke departemen keuangan, menyetujui persyaratan pembayaran dengan mereka dan pemasok, memesan dengan pemasok, dan menunggu penyelesaian - pembayaran dan, pada kenyataannya, kedatangan barang yang diperlukan.
Misalkan pelanggan, mis. manajer penjualan, mengidentifikasi masalah proses, dalam bahasa filistin. Masalah utama disebut masalah kecepatan - dibutuhkan waktu yang sangat lama untuk menunggu eksekusi aplikasi pembelian. Ketika proses selesai, dan pesanan dibuat untuk pemasok, tidak ada masalah khusus - pemasok dapat diandalkan, mereka jarang gagal. Tetapi tahap koordinasi, pergerakan aplikasi dalam perusahaan tidak berharga.
Mari kita menggambar diagram yang disederhanakan dari proses ini dalam bentuk tabel.

Apa yang bisa dikatakan seseorang dengan melihat proses ini? Masalah apa yang terlihat - nyata atau potensial? Tampaknya prosesnya cukup standar, dalam satu atau lain bentuk ditemukan di sebagian besar perusahaan. Di mana kecepatannya hilang?
Dan satu pertanyaan lagi: bagaimana cara melihat potensi masalah dari proses tanpa mengetahui isi kolom βAksiβ - memiliki informasi hanya tentang para pemain? Lakukan semacam analisis cepat, dengan cepat, tanpa menyelam ke rincian tindakan yang dilakukan.
Di sinilah metode jalur berenang berguna. Nama ini diambil dengan analogi dengan jalan di kolam renang, dipisahkan oleh penekan gelombang - tali berwarna cerah membentang di seluruh panjang kolam.
Dalam metode kami, trek adalah unit fungsional yang berbeda. Secara umum, itu bisa saja orang yang berbeda dalam tim atau layanan yang sama.
Kami menggambar proses yang sama menggunakan metode lane renang, hanya menyisakan jumlah tindakan dan pemain. Dalam kasus kami, ada tiga pemain, jumlah trek yang sama akan. Prosesnya berjalan dari atas ke bawah, nomor tindakan ada di kolom eksekutornya.

Sejauh ini, kejelasan belum ditambahkan. Hanya terlihat bahwa manajer pengadaan melakukan paling banyak tindakan. Masalah potensial dari proses terlihat, di mana ia kehilangan kecepatannya, macet atau bahkan hilang? Tidak, ada sesuatu yang hilang.
Mari kita coba menambahkan panah - arah transisi antar tindakan. Garis solid menunjukkan transisi utama, garis putus-putus menunjukkan transisi tambahan, jika terjadi kegagalan dalam proses dan kembali ke tindakan sebelumnya (misalnya, jika penjual tidak puas dengan harga yang ditawarkan oleh pemasok).

Dengan panah, prosesnya terlihat agak kurang dapat dibaca, tetapi secara umum dapat dipahami jika Anda menggerakkan jari Anda di sepanjang panah dari digit ke digit. Sekarang, melihat gambar ini, Anda bisa mengerti di mana hambatannya? Tidak sampai terlihat.
Kembali ke analogi jalur kolam renang. Jika Anda adalah orang dewasa, orang yang serius dan memadai, datang ke kolam renang untuk berenang bebas, untuk berlatih lima puluh meter dengan kuningan, siapa yang dapat mengalihkan perhatian Anda dari proses ini dan kehilangan kesabaran? Anda telah memilih trek yang jumlah orangnya lebih sedikit, atau tidak ada sama sekali, dan Anda siap untuk bersenang-senang.
Tetapi Anda bukan satu-satunya, dan di sini beberapa orang bijak juga menyelami jalan Anda. Di belakangnya - satu lagi, lalu yang lain dan lebih. Dan menjadi jelas mustahil untuk berenang - Anda harus membatasi gerakan Anda agar tidak menyentuh tangan dan sisi basah orang lain.
Anda terpaksa mengubah trek. Sepertinya tidak apa-apa - mereka berlayar di bawah Waveguard, mungkin lebih dari sekali (jika jalur bebas tidak berdekatan dengan Anda), dan kembali menikmati prosesnya. Tapi situasinya terulang lagi - orang-orang berlarian dan mereka mengganggu Anda. Situasi ini diperburuk oleh masuknya anak-anak yang tidak akan bergaul sepanjang waktu di jalur yang sama - mereka akan bermain, bermain-main, menyelam, berenang di beberapa trek melintasi perdebatan, dll.
Selama sesi berenang Anda harus mengganti trek beberapa kali, berenang di bawah pemadam gelombang.
Dalam kasus proses, mengubah trek adalah transisi dari aliran aksi lintas batas. Sebagai perbatasan, kami memilih unit fungsional. Di kolam, Anda perlu beberapa detik untuk mengubah jalan, tetapi dalam proses internal perusahaan jam, hari, kadang-kadang minggu bisa diperlukan untuk mengatasinya.
Mari kita lihat gambar terakhir dari proses - sama seperti yang terakhir kali, hanya kita akan menandai dengan melintasi saat-saat transisi dari satu trek ke yang lain.

Secara total, 5 persilangan pada tindakan utama, 4 - pada bantu, total (maksimum) - 9. Sembilan kali proses dipaksa untuk mengatasi batas-batas unit fungsional.
Setiap penyeberangan perbatasan adalah kerugian. Secara teoritis, ini adalah potensi kerugian, karena ada proses yang diatur dengan cermat dalam kehidupan yang mengalir tanpa tersandung di perbatasan. Namun dalam praktiknya, mengganti trek selalu merupakan kehilangan kecepatan.
Proses transisi fisik tidak akan dianggap sebagai batasan - sekarang, dalam kebanyakan kasus, proses ini otomatis. Aplikasi, faktur, biaya, dll. ditransmisikan secara elektronik, yaitu secara instan.
Tetapi transfer informasi hanyalah awal dari menunggu di perbatasan. Setiap lagu, mis. unit atau pemain, menjalani kehidupan mereka sendiri, sesuai dengan aturan, peraturan, dan proses internal mereka. Konsep antrian muncul hampir di mana-mana.
Manajer pengadaan tidak terburu-buru untuk mengevaluasi setiap permintaan segera setelah diterima. Dia memiliki aplikasi ini - dua lusin sehari. Dengan demikian, aplikasi berbaris untuk diproses. Jika seorang karyawan cenderung untuk mengoptimalkan pekerjaannya, ia akan mengelompokkan permintaan - misalnya, ia akan memilih item baris yang sama untuk pesanan dari beberapa permintaan dan membuat permintaan kepada pemasok.
Pemodal, dengan cara yang sama, tidak bekerja dengan setiap aplikasi secara individual, terutama pada tahap pembayaran. Uang ditransfer ke pemasok melalui registrasi, dan biasanya sekali atau dua kali sehari. Karenanya, dalam antrian untuk pembayaran, akun akan diam selama setidaknya satu hari. Dengan prosedur koordinasi dan penganggaran yang rumit - misalnya, jika permohonan pembayaran perlu diajukan dalam seminggu - prosesnya bisa sangat macet di perbatasan.
Bahkan tanpa melihat posting dan fitur spesifik dari pekerjaan mereka, selalu ada penundaan dalam menanggapi informasi - setidaknya karena seseorang tidak melihatnya langsung, pada saat transmisi. Hanya sedikit orang yang duduk di depan komputer dan segera membaca semua surat masuk. Beberapa umumnya tidak duduk di depan komputer sama sekali - penjual yang sama dapat pergi untuk rapat dengan klien, dan tidak melakukan tindakan nomor 5 selama 24 jam (analisis profitabilitas transaksi).
Seperti disebutkan di awal, metode ini tidak menjawab pertanyaan βbagaimana mengubah proses?β, Tetapi ini menunjukkan area masalah yang potensial dengan sangat jelas. Seperti yang Anda lihat sekarang, metode ini juga sangat mudah digunakan.
Dengan sedikit latihan, Anda dapat menghitung jumlah titik transisi dalam beberapa detik tanpa menggambar apa pun - cukup dengan melihat deskripsi prosesnya, dalam bentuk apa pun itu dijalankan.
Beberapa format, atau notasi dari deskripsi proses, terutama visual, dan secara harfiah meminta seseorang untuk menghitung trek dan transisi di antara mereka. Sebagai contoh, qualigrams.
Metode jalur renang dapat digunakan, misalnya, dalam sebuah wawancara - jika Anda telah bergabung dengan perusahaan baru dan melamar posisi atau kegiatan yang terkait dengan proses. Hanya meminta untuk menunjukkan kepada Anda deskripsi proses masalah (jika majikan tidak melakukan ini sendiri), atau menggambar dengan spidol di papan tulis.
Kemudian, dengan suara misterius, katakan: "Proses yang bagus, hanya saya melihat setidaknya 12 titik berbahaya di sini" dan menunjukkan poin-poin ini. Di sini Anda dapat berbicara secara singkat tentang metode, tujuan dan prinsip-prinsip dasarnya. Untuk pertanyaan "Bagaimana proses ini dapat dioptimalkan?" jawabannya "ada beberapa pilihan, tetapi perendaman yang lebih dalam dalam rinciannya" sudah cukup.
Meskipun, tentu saja, Anda dapat langsung memberikan rekomendasi yang lebih tepat - metode kontrol perbatasan, yang akan kita bahas nanti.