Selamat siang
Saya ingin menawarkan tamasya kecil ke dalam aplikasi praktis dari teori kendala untuk TI. Yaitu, dalam hal menghitung "throughput" departemen untuk mengembangkan perangkat lunak internal perusahaan.
Tentang CBT (Theory of Constraints) dan mega-book "Goal" oleh Elia Goldratt, banyak yang telah ditulis, termasuk tentang Habré, jadi saya akan langsung ke intinya.
Departemen yang saya pimpin mendukung dan mengembangkan beberapa yang disebut "inhouse" sistem informasi, yang utamanya adalah WMS dan TMS - gudang dan sistem manajemen transportasi. Selanjutnya saya akan fokus hanya pada sistem ini dan hanya satu bagian dari bisnis - layanan dari operator logistik.
Setiap hari, selusin tugas baru dituangkan ke dalam kotak surat kami, banyak di antaranya ditandai "Mendesak!", "Penting!" dll.
Saat ini, jaminan simpanan telah berkembang menjadi sekitar tujuh ratus tugas dengan kategori kompleksitas yang berbeda.
Untuk mengelola volume ini, kami telah memperkenalkan sistem prioritas, sesuai dengan tingkat pengaruhnya terhadap bisnis:
Kegagalan sistem-A, atau masalah yang tidak memungkinkan untuk sepenuhnya memenuhi kewajiban kontraktual (untuk bisnis utama).
B - tugas yang berkaitan dengan pertumbuhan pendapatan perusahaan - yaitu, kedatangan pelanggan baru.
C - tugas yang berkaitan dengan peningkatan profitabilitas, yaitu tugas untuk mengoptimalkan produktivitas (sistem total, proses kerja, orang, pertumbuhan produksi, dll.).
D - peningkatan atas permintaan pelanggan kami (laporan, integrasi dengan perusahaan transportasi, dll.).
Di dalam kategori-kategori ini ada tingkat divisi lain (A1, A2, ...), tetapi untuk keperluan artikel hari ini, ini tidak penting.
Logikanya, pelaksanaan tugas harus diatur dalam urutan: ABCD.
Dalam praktiknya, rencana pembangunan adalah hasil dari sejumlah besar kompromi. Sebagai contoh, tugas kategori D sering datang ke bagian paling atas dari simpanan (fokus pelanggan, ya).
Faktanya, sistem prioritas hanya memberikan arahan umum untuk perencanaan, tetapi tidak memungkinkan semua orang memberikan jawaban obyektif untuk pertanyaan: "Mengapa tugas saya tidak begitu lama?"
Kami juga memiliki masalah klien kecil dan besar, yang menghabiskan kira-kira sumber daya IT yang sama. Secara teoritis, pelanggan yang lebih gemuk harus menjadi prioritas, tetapi Anda tidak boleh meninggalkan yang kecil, apalagi, yang kecil sering kali memerlukan perhatian khusus, seolah-olah kapal itu tidak mengirim dua rusa seminggu, tetapi setidaknya kereta kontainer.
Memahami ini dan memahami bahwa perusahaan adalah organisasi komersial, bukan amal, dan pertama-tama harus menguntungkan, kami memutuskan untuk memompa sistem perencanaan menggunakan teori pembatasan.
Keterbatasan dalam kasus kami adalah sumber daya pengembangan.
CBT memperkenalkan konsep baru untuk throughput bisnis, "tingkat pendapatan pendapatan" bersyarat, yang harus terus ditingkatkan. Tidak seperti biaya, pertumbuhan bagian ini secara teoritis tidak dibatasi oleh apa pun dan dapat (mungkin) cenderung tak terbatas.
Dalam kasus pengembang, kami akan menggunakan laba atas jam kerja, dalam rubel, sebagai ukuran bagian.
Algoritme adalah sesuatu seperti ini:
- Untuk setiap tugas, perlu menilai dampak ekonomi dari implementasi. Ini bisa berupa penghematan jam kerja kerah biru, atau penghematan sumber daya lain (misalnya, meter persegi yang langka di area ekspedisi, atau tempat palet di area penyimpanan, atau jam loader). Diinginkan, dalam ribuan rubel / tahun. Pelanggan harus melakukan penilaian seperti itu. Jika dia tidak bisa melakukan ini sendiri, maka dia akan menghubungi atasannya.
- Setelah tugas dievaluasi dalam hal efek, ia pergi ke studi Timlid, atau ke salah satu signorees. Sebagai hasilnya, kami mendapatkan estimasi awal biaya tertentu.
- Membagi yang pertama menjadi yang kedua, kita mendapatkan bagian - kecepatan mencapai efek.
- Kami memberi peringkat tugas-tugas di dalam simpanan dalam urutan peralihan.
- Potong sepotong simpanan di atas rencana / sprint berikutnya.
Misalnya, ada masalah, efek yang diperkirakan pelanggan di 100 ribu rubel. per bulan, atau 1,2 juta rubel. per tahun.
Untuk bagian kami, implementasi akan membutuhkan 40 jam pengembangan.
Lulus, sebagai hasilnya, akan menjadi 1200/40 = 30 unit konvensional.
Untuk tugas lain, efek yang diharapkan dari 50 ribu rubel. per bulan, tetapi implementasinya akan memakan waktu 100 jam. Total, 600 ribu rubel / 100 = 6 c.u.
Pada akhirnya, kami akan melakukan kedua tugas tersebut. Tapi pertama, pertama, dan kedua.
Kembali ke kategori prioritas, kami membentuk aliran koreksi terpisah (kategori A), kemudian meluncurkan klien baru (tugas direncanakan sesuai dengan tenggat waktu yang ada), dan sisa waktu dibombardir oleh pengembangan sistem penilaian kelulusan baru.
Keuntungan dari teknologi ini adalah bahwa itu obyektif. Bahkan dengan semua asumsi - bagaimana pelanggan memperkirakan efek, ketidakakuratan dalam penilaian kompleksitas, tingkat pengembang yang akan mengimplementasikannya - itu memberikan gambaran nyata dari tugas-tugas penting dan tidak penting dari sudut pandang bisnis.
Dan bagaimana dengan kategori D, Anda bertanya? Bagaimana keinginan pelanggan, terutama yang kecil? Bagaimana mereka masuk ke dalam skema baru?
Pertanyaan ini masih terbuka.
Untuk membangun gambaran objektif, perlu juga mengevaluasi dampak ekonomi dari mereka, tetapi, secara kondisional, tidak langsung. Artinya, reputasi perusahaan, fokus pelanggan, potensi pertumbuhan bisnis dari para pelanggan ini, menarik referensi yang baik. Ada hal-hal yang lebih halus, kami, bersama dengan penjualan dan layanan pelanggan, membahas bagaimana mendigitalkan indikator-indikator ini.
Tujuan utamanya adalah untuk mendapatkan sistem transparan obyektif dalam membangun tugas yang memungkinkan Anda memaksimalkan penggunaan sumber daya pengembangan. Mungkin, sebagai harmoni, seseorang hanya dapat memperjuangkannya, bagaimanapun, teori pembatasan dengan tegas menyatakan bahwa "Tujuan" dapat dicapai.
Sesuatu seperti itu.
Dengan kesiapan bagian rebus berikutnya, saya akan membagikan hasilnya.
PS Untuk saat ini, masalah refactoring dan berbagai tugas infrastruktur ditinggalkan, kami akan kembali kepada mereka nanti.