Programmer suka menggambar laporan alas kaki. Jika Anda memerlukan laporan penjualan, mereka akan membuang seluruh tabel penjualan, dengan rekanan, nomenklatur, organisasi, kontrak, jumlah dan jumlah.
Semuanya akan baik-baik saja, hanya dengan bantuan laporan seperti itu sulit dikelola. Analisis - mungkin jika ada banyak waktu luang. Dan siapa yang punya banyak waktu luang? Analis punya, misalnya. Oke, jika dia seorang analis. Lagipula, ada analitik dengan panggilan jiwa. Dia memiliki posisi, misalnya, sebagai manajer penjualan, tetapi dia tidak ingin menjual atau tidak tahu bagaimana, tetapi memilih angka dalam angka adalah hal yang baik.
Kepala waktu untuk memilih dalam laporan, sayangnya, tidak. Setidaknya sebagai bagian dari manajemen reguler. Dia membutuhkan informasi singkat dan komprehensif yang menjawab pertanyaan sederhana: bagaimana keadaannya? Atau dengan cara lain: apakah kita baik-baik saja?
Bagaimana menjawab pertanyaan seperti itu dengan kain alas kaki? Tidak mungkin. Tapak kaki, seolah-olah, berkata kepada kepala: apakah Anda menginginkan informasi? Nah, ini dia. SEMUA! Ayo, bereskan, dan cari jawaban untuk pertanyaan Anda.
Jika kepala sampai ke programmer dengan tugasnya, ia mencoba untuk "membantu". Misalnya, laporan rencana penjualan / fakta dibuat. Cantik, nyaman, dapat disesuaikan. Di sana Anda tidak hanya dapat membandingkan rencana dengan fakta, tetapi juga fakta dengan fakta untuk periode yang berbeda, dan secara umum - sejumlah tabel. Apa hasilnya? Alas kaki lain, hanya lebih rumit.
Jika Anda sampai ke bagian bawah programmer lagi, ia akan berkata: sial, ambil mood untuk diri sendiri dan laporkan, dan simpan pengaturan. Saring data, pilih periode sehingga hanya data yang Anda butuhkan yang ditampilkan. Nah, sebagai opsi, itu akan dilakukan. Tetapi hanya jika kepala tahu cara menyesuaikan. Dan jika Anda tidak bisa?
Ok, programmer, dengan enggan, dan tulang berderit, akan menyiapkan laporan sendiri. Dan dia akan berkata: semua, aktif, tersedak. Tentu saja, dia tidak akan mengatakannya dengan keras, tetapi dia akan memikirkannya. Segalanya, kebahagiaan telah datang?
Tidak. Pertama, pertama kali dia tidak mengatur, dia harus melarikan diri beberapa kali. Atau tulis tugas teknis yang bagus dan berkualitas tinggi. Dan ini, hampir selalu, tidak mungkin, karena pemimpin di pantai tidak tahu dalam bentuk apa dia perlu laporan.
Sementara sang pemimpin memiliki tapak kaki, tampaknya baginya sudah cukup untuk membentuk kelompok, dan dia akan dapat mengelola dengan menggunakan laporan. Setelah menerima pengelompokan, ia akan menginginkan filter. Setelah menerima filter, ia akan mengerti bahwa penyortiran diperlukan. Dan sebagainya.
Kedua, satu laporan saja tidak cukup. Lagi pula, seorang pemimpin tidak hanya tertarik pada penjualan? Juga, pergerakan uang dibutuhkan. Dan pekerjaan karyawan. Dan pesanan terlambat - baik untuk pembeli dan pemasok. Ini akan menghasilkan beberapa laporan, dan untuk masing-masing satu atau lebih pengaturan.
Ketiga, dalam banyak kasus sistem informasi adalah yang desktop. Untuk mengetahui bagaimana keadaan Anda, Anda harus menyalakan komputer. Anda masih harus mencapainya. Jika pemimpin sedemikian rupa sehingga dia duduk di depan komputer sepanjang hari, maka tidak ada masalah. Apakah ada banyak pemimpin seperti itu?
Manajer ingin menonton laporan dari jarak jauh melalui Internet. Diinginkan - dari smartphone. Ini sangat nyaman - bahkan saat makan siang, setidaknya dalam lalu lintas, setidaknya pada pertemuan yang membosankan. Programmer lagi harus khawatir.
Keempat, ada beberapa laporan. Semua orang menjawab pertanyaan mereka sendiri. Setiap orang perlu dibuka dan dilihat secara terpisah. Satu dibuka, yang kedua ditutup. Maksimum - membuat layar terpisah dan melihat dua sekaligus.
Dalam sistem desktop, Anda bahkan tidak dapat melihatnya, seperti pada smartphone - well, sehingga semua laporan jatuh ke dalam satu alas kaki yang panjang, dan Anda dapat menggulirkan jari-jari Anda dari atas ke bawah.
Manajer ingin melihat semua laporan pada satu layar. Ini adalah keinginan manusia yang normal. Tapi untuk programmer, ini neraka.
Laporan besar yang biasa, bahkan dikonfigurasikan dan difilter, hanya terlihat bagus di layar penuh. Jika Anda mempersempitnya menjadi dua, bilah gulir segera muncul yang merusak keseluruhan tayangan - bahkan jika tidak ada apa pun di belakang area layar yang terlihat, tangan itu sendiri menggulungnya untuk menggulir ke bawah atau ke samping untuk memastikan hal ini.
Dan jika ada tiga laporan? Atau empat? Ternyata pantat-s. Manajer tidak punya pilihan selain melihat laporan secara tradisional - satu per satu, dalam layar penuh.
Bahkan penyajian informasi dalam bentuk diagram tidak menyimpan jika ditampilkan, seperti dalam 1C, dalam dokumen tabel. Bilah gulir yang sama muncul, tidak mungkin untuk secara cerdas mengontrol skala bagan, emosi memanas.
Dan apa masalahnya? Dan apakah dia ada di sana?
Ada, dan sangat sederhana: programmer terlalu suka sepatu kaki. Dia diajari seperti itu, mereka bertanya sistem nilai seperti itu: mereka membuang semua yang ada dan lebih. Dan menyediakan mekanisme tuning yang chic.
Pendekatan ini baik untuk pengembang solusi kotak, karena mereka tidak punya pilihan. Mereka tidak tahu informasi apa dan dalam bentuk apa yang ingin dilihat oleh pemimpin tertentu, sehingga mereka sendiri membuat penyetelan kaki + kaki.
Tapi programmer di lapangan, mis. untuk beberapa pelanggan, karena suatu alasan, mengikuti secara buta paradigma ini. Mereka bertindak seolah-olah mereka sendiri adalah pengembang solusi kotak. Dan mereka membuat semua kain kaki baru.
Teman adalah programmer. Saya juga seorang programmer. Saya juga suka membuat alas kaki. Sederhana, menarik, bahkan indah dengan caranya sendiri. Tetapi sepatu kaki tidak cocok untuk manajemen.
Saya tidak mengatakan bahwa ada sesuatu yang salah dengan Anda, atau dengan kami. Saya hanya mengusulkan untuk memecahkan masalah teknik yang baru, menarik, dan menarik: membuat laporan kecil.
Bukan alas kaki besar dalam seribu baris, tapi piring kecil dengan dua kolom dan tiga garis. Bukan grafik yang lumayan yang tidak muat di layar, tapi grafik kecil dengan tiga kolom yang dengan jelas menjawab pertanyaan tertentu. Jangan membuang banyak angka sehingga seseorang atas dasar mereka menjawab pertanyaan, tetapi segera berikan jawaban atas pertanyaan - singkat, singkat, dapat dimengerti.
Ini sangat menarik. Dan semua ini mudah untuk di-algoritma-kan. Prinsipnya sangat sederhana - Saluran “bagaimana jika?”.
Di sini kami memiliki rencana dan fakta penjualan - tabel terpisah dengan data. Kami menggambar dua laporan - rencana dan fakta penjualan.
Tetapi bagaimana jika Anda menggabungkannya dan segera menggambar rencana dan fakta dalam satu laporan? Yah, sudah tidak buruk.
Tetapi bagaimana jika kita jatuh ke kelompok nomenklatur? Maka laporannya akan kecil, setidaknya tingginya.
Ok, kita lakukan.
Tetapi bagaimana jika Anda menggambar laporan yang sama dalam bentuk diagram? Histogram biasa dua kolom. Yang pertama adalah rencananya, fakta kedua. Anda melihat, dan Anda segera mengerti di mana rencana itu dilaksanakan, dan di mana kegagalan itu.
Tetapi bagaimana jika Anda menceritakan rencana hari ini? Setelah semua, kami membuang seluruh rencana bulanan di kolom pertama, dan faktanya akan menyusul hanya pada akhir bulan. Sepanjang bulan, melihat grafik, pemimpin akan berpikir bahwa semuanya buruk. Atau dia harus mencari tahu dalam benaknya bagian bulan apa yang telah berlalu. Tidak, jangan sampai keseluruhan rencana bulanan, tetapi bagian dari itu. Pada hari kesepuluh - sepertiga, lima belas - setengahnya, dll. Maka diagram akan menjadi lebih jelas dan lebih menarik.
Tetapi bagaimana jika kita mewarnai kolom tergantung pada apakah semuanya baik atau tidak? Bagaimanapun, kita tahu apakah rencana itu dilaksanakan dengan baik atau tidak - Anda hanya perlu membandingkan dua angka. Jadikan kolom merah jika semuanya buruk. Kuning - jika berbahaya. Hijau - jika bagus.
Tetapi bagaimana jika Anda tidak menampilkan kolom yang semuanya baik-baik saja? Misalnya, jika kita memiliki bagan yang dipecah berdasarkan grup item. Kami hanya akan menampilkan yang berwarna kuning atau merah. Baiklah, katakan kepada pemimpin bahwa jika tidak ada kolom, maka semuanya baik-baik saja. Apakah dia mengerti? Dia membutuhkan informasi untuk bereaksi dan membuat keputusan? Untuk mengatur tugas, aksen, di atas karpet menyebabkan seseorang. Jadi, biarkan sistem hanya berbicara tentang apa yang perlu Anda tanggapi.
Tetapi bagaimana jika Anda menghapus grafik sama sekali? Kami telah menyembunyikan hampir semua kolom, apa gunanya diagram, sebagai cara untuk menyajikan informasi? Kami akan menampilkan piring pendek di mana hanya akan ada kelompok item yang bermasalah - kuning dan merah. Nah, angkanya, persentasenya.
Tetapi bagaimana jika Anda sama sekali tidak menampilkan laporan kepada manajer? Mengapa membuatnya menatap suatu tempat setiap hari? Mari kita lakukan ini: jika ada masalah, kami akan memberinya sinyal. Bukan kita, tetapi sistem yang kita kembangkan. Warna kuning atau merah telah muncul - kami menulis surat, baik dalam getaran atau SMS, itu tidak masalah. Manajer akan tahu: jika tidak ada sinyal, semuanya baik-baik saja. Anda tidak dapat membuang waktu menganalisis, lebih baik hanya bekerja, melakukan sesuatu yang bermanfaat. Tentu saja, pertama kali dia masih akan datang dan menonton - dia tidak mempercayai programmer. Anda tidak pernah tahu, tiba-tiba mengirim surat pasak bangkit. Nah, biarkan tersandung dan biasakan itu.
Tetapi bagaimana jika dia tidak memerlukan informasi tentang beberapa kelompok nomenklatur? Yah, dia tahu bahwa mereka tidak untuk dijual, dan akan selalu berwarna merah atau kuning. Mengapa seseorang harus ditarik dengan sia-sia dengan sinyal yang tidak perlu? Kami membersihkan.
Tetapi bagaimana jika kita melaporkan bukan daftar kelompok buruk, tetapi satu baris - apakah semuanya baik atau semuanya buruk? Mengetahui pentingnya kelompok nomenklatur khusus, dan rencana penjualan umum, kami memperkenalkan bobot dan fungsi sederhana yang akan menghitung jawaban atas pertanyaan: apakah kita baik-baik saja? Kami akan memberikan koefisien 0,1 ke grup yang tidak menarik, 0,5 atau 0,7 ke grup yang menarik, dan itu saja, kami mendapatkan satu figur besar yang cantik. Jika kelompok utama menjual dengan baik, maka semuanya baik-baik saja dengan kami.
Tetapi bagaimana jika Anda memberi pemimpin dua angka yang berbeda? Bagaimanapun, jelas bahwa tugas-tugas dalam kelompok yang berbeda dapat berbeda secara mendasar. Misalnya, kelompok utama adalah poros penjualan yang bodoh. Tetapi suatu kelompok dengan nomenklatur baru, misalnya - peralatan baru - tidak memberikan poros dan tidak dapat memberi menurut definisi. Di sana, satu atau dua penjualan per bulan dianggap baik. Apakah kamu mengerti Bahkan jumlah itu tidak penting, tetapi kuantitasnya. Dijual satu unit peralatan baru - ini hari libur! Jika Anda hanya bekerja dengan jumlah, maka unit peralatan baru ini akan selalu disembunyikan di antara nomenklatur utama. Mengapa kita membutuhkan ini? Biarkan ada dua angka: bagaimana hal-hal yang terjadi di jalur utama, dan bagaimana hal-hal pada peralatan baru. Kriteria evaluasi berbeda, skala berbeda.
Tetapi bagaimana jika kita menempatkan dua angka ini menjadi satu? Kami menulis ulang fungsi kami dengan bobot, mengganti angka absolut dengan yang relatif. Biarkan nomenklatur utama dipertimbangkan berdasarkan jumlah, dan yang baru berdasarkan kuantitas. Dan semua ini diubah menjadi persentase. Kemudian bobot dapat diperbaiki - tingkatkan nomenklatur baru, karena itu penting bagi kami.
Tetapi bagaimana jika kita mempertimbangkan dua faktor: rencana / fakta pada titik tertentu, dan dinamika selama beberapa hari terakhir? Itu memang terjadi. Pada bulan pertama mereka melakukan pengiriman besar - segera 20% dari rencana bulanan. Dan semua grafik kami selama enam hari akan menunjukkan bahwa semuanya baik-baik saja. Namun pada kenyataannya, penjualan kami mendapat taruhan - bukan pengiriman tunggal selama hampir seminggu. Dari sudut pandang formal, semuanya tidak buruk, tetapi bukankah kita di sini untuk formalitas? Kepala harus tahu bahwa manajer menendang buldoser tanpa menjaga dinamika penjualan. Tidak ada yang rumit bagi kami - kami hanya menambahkan variabel lain ke fungsi, dinamika penjualan, dengan koefisien bobotnya sendiri. Dan itu saja, cantik.
Tetapi bagaimana jika dalam fungsi kita kita memperhitungkan tidak hanya rencana / fakta penjualan, tetapi juga rencana / fakta pergerakan uang? Kami akan mencetak angka yang sangat bagus untuk kepala, atau garis yang dapat dibaca manusia - "semuanya baik", "penjualan baik, uang biasa-biasa saja", "penjualan 120%, uang 90%", dll.
Bagaimana jika ...
Ini dapat dilanjutkan tanpa batas. Hal utama adalah berhenti tepat waktu dan membiarkan manajer menggunakan alat itu, terbiasa dengannya, merumuskan umpan balik. Sebagai seorang programmer, saya mengerti bahwa ketika memecahkan masalah corong "bagaimana jika?" ada keinginan yang tak tertahankan untuk membuatnya lebih sederhana, lebih baik, lebih informatif, lebih bermanfaat. Anda harus bisa menghentikan diri sendiri.
Yang utama adalah menganggap tugas ini sebagai rekayasa. Karena begini dan begini. Ini bukan kecantikan atau busur, ini adalah pembangunan sistem manajemen.
Pemimpin sendiri tidak akan mengatasi tugas ini, sayang. Dia tidak tahu semua kemungkinan, semua data, semua hubungan. Tapi programmer tahu. Tapi diam.
Ayo, keluar dari sudut gelapmu. Anda pemrogram dapat memberikan manfaat luar biasa untuk menjalankan perusahaan. Anda adalah insinyur. Sistem manajemen, manajemen otomasi adalah pekerjaan teknik. Dan kepala akan menjadi penggunanya. Ini akan dikelola menggunakan sistem Anda.