Eksorsisme Programmer

Ada banyak materi tentang bagaimana pengenalan sistem informasi membantu perusahaan menyingkirkan kerugian, mengurangi biaya, dan memotong pencurian. Luar biasa ketika ternyata bisa menyingkirkan kejahatan dalam volume yang begitu besar.

Artikel saya adalah tentang kejahatan kecil. Tentang sabotase implementasi, tentang yang kekal "Saya melakukan segalanya dengan benar, ini adalah program Anda untuk disalahkan", tentang kembung, tentang urusan perusahaan kecil dan penolakan terhadap perubahan.

Segala sesuatu dalam artikel ini berasal dari pengalaman pribadi, dengan contoh penggunaan. Saya tidak berpura-pura keunikan dan pengungkapan penuh topik, tidak ada kebenaran yang lebih tinggi di sini, saya mencoba untuk menghindari generalisasi, saya tidak memaksakan apa pun.

Hanya pengalaman menggunakan beberapa alat dan contoh bagaimana mereka membantu saya.

Merekam tindakan pengguna dengan parameter waktu

Sejujurnya saya tidak ingat mengapa saya melakukan hal ini, tetapi itu berguna beberapa kali. Perkembangannya sederhana dan canggung, tidak lebih dari satu jam. Tidak berlaku di mana-mana, karena dapat menghabiskan banyak sumber daya dan data membutuhkan banyak ruang disk, jadi Anda harus memantaunya.

Prinsipnya sederhana:

• catatan saat pengguna membuka formulir (dokumen, direktori, laporan, pemrosesan);
• mencatat ketika dia menutupnya;
• mencatat ketika ia merekamnya (jika itu adalah objek yang disimpan, seperti dokumen atau direktori);
• mencatat apakah itu objek baru, atau yang lama;
• mencatat semua yang perlu Anda ketahui tentang objek - tautan, ketik nama, nama pengguna, nama formulir.

Akibatnya, kami memiliki tabel besar dengan data, dan beberapa digit yang dihitung. Misalnya, kita tahu "pemeriksaan rata-rata" - berapa banyak waktu yang diperlukan untuk membuat faktur tanda terima akuntan. Kami tahu berapa kali seorang akuntan kembali ke dokumen yang dibuat sebelumnya untuk mengubahnya, dan berapa banyak waktu yang dihabiskannya untuk itu.

Saya akan memberikan contoh ketika mekanisme ini berguna.

Yang pertama adalah penghapusan sabotase kecil terhadap implementasi. Mekanisme untuk memilih pesanan di gudang diperkenalkan - pemilik toko harus menandai barang yang dikumpulkan di dalam kotak. Para pemilik toko jelas diberi tahu - tanpa fanatisme, bekerja dengan sistem hanya ketika ada waktu luang.

Sehari kemudian, manajer pengiriman datang berjalan, mengatakan para pemilik toko menolak untuk memuat mobil, mereka mengatakan bahwa mereka perlu mengarahkan data ke beberapa sistem dan butuh 2 jam sehari untuk melakukan ini. Tentu saja, saya segera menjelaskan bahwa tidak ada yang memberi mereka perintah seperti itu. Saya membuka laporan saya, saya tahu - mereka menghabiskan 20 menit sehari untuk semua orang . Dia memberi tahu manajer, dia memberi tahu para pemilik toko - itu saja, tidak ada lagi pernyataan seperti itu dari mereka.

Contoh kedua . Findir memesan beberapa fungsi untuk mengelola uang. Yang penting bukan karena ingin, tetapi karena lingkaran akuntansi ini tidak cukup untuk yang lebih tinggi. Kemudian pada pertemuan umum mereka bertanya kepadanya - mengapa, kapan data akan muncul? Dia mengatakan - ada kesalahan, itu tidak berhasil, kami akan menulis tugas untuk diselesaikan oleh programmer. Saya membuka laporan, saya menunjukkan bahwa baik dia maupun anak perempuannya tidak pernah memasukkan dokumen atau laporan. Itu saja, pengantar telah pindah.

Contoh ketiga . Akuntansi mengatakan - kita perlu memperluas staf, kami telah meningkatkan aliran dokumen. Manajemen, yang memperhatikan laporan saya, ditanya - berikan statistik, apa yang telah tumbuh di sana dan di mana.

Hitungan pertama di dahi - jumlah dokumen dan jumlah baris di dalamnya - menunjukkan bahwa aliran dokumen tidak meningkat.

Oke, saya pikir, mungkin ada sesuatu yang rumit dalam dokumen, mungkin sebenarnya menjadi lebih sulit untuk menyusunnya.

Saya melihat "cek rata-rata" dan dinamika untuk dua akuntan - tidak, sepertinya tidak tumbuh, tidak jatuh.

Dia sadar bahwa seorang akuntan yang bekerja lama baru saja pergi cuti hamil, dan dua yang baru menggantikannya. Saya punya data untuk ketiganya, saya membandingkan - bah, ini dia. Dua akuntan baru memasukkan dokumen lebih lambat dari yang lama.

Semuanya, perluasan negara telah dibatalkan, Anda hanya harus menunggu sampai mereka mengisi tangan mereka. Pada saat yang sama - otomatisasi kecil.

Dari contoh ketiga berikut yang keempat , sudah positif. Melihat dinamika "pemeriksaan rata-rata" berdasarkan jenis objek, kami mulai menggunakannya untuk menganalisis otomatisasi operasi dan konsekuensi dari perubahan. Jika "rata-rata cek" tumbuh, maka kami menganalisis alasannya, menyaksikan orang-orang hidup dan meningkat.

Rekam nilai metrik

Secara teknis, ini adalah solusi yang sangat sederhana. Esensinya sederhana - kueri ditulis yang menghitung beberapa digit dan menyimpannya dalam sistem dengan frekuensi yang diinginkan. Akibatnya, kami memiliki dinamika dalam waktu untuk gambar.

Banyak angka yang tidak perlu diingat, karena mereka direproduksi. Misalnya, tidak perlu mengingat volume penjualan - Anda selalu dapat melihatnya secara retrospektif.

Tetapi beberapa angka hanya dapat direproduksi dengan menaikkan basis data cadangan. Misalnya, ini adalah satu-satunya cara untuk mengetahui berapa banyak saldo negatif pada barang yang Anda miliki sebulan yang lalu. Mereka yang membaca artikel saya sebelumnya mengerti bahwa ini tentang Iceberg .

Kasus penggunaan pertama . Ada masalah dengan mengimbangi pembayaran uang muka - jumlah yang agak besar hang secara bersamaan pada 60,01 dan 60,02. Fungsionalitasnya khas, tidak ada kesulitan metodologis - cukup tunjukkan analitik yang benar dalam dokumen, dan uang muka akan dihitung. Pada rapat, kata akuntansi - tidak masalah, kami akan melakukannya. Pada setiap pertemuan berikutnya ia mengulangi - kami lakukan, ada banyak pekerjaan, otomatis buruk. Mereka menatapku curiga.

Saya datang, saya menyalakan catatan indikator - jumlah uang muka yang tidak tercatat. Saya pikir - tidak, mereka akan melakukannya, mereka akan mengatakan bahwa kemajuan yang tidak disadari tumbuh lebih cepat daripada mereka memperbaikinya. Saya membagi indikator menjadi tiga bagian - jumlah pada awal tahun, jumlah pada awal bulan, jumlah untuk hari ini.

Pada pertemuan berikutnya, saya menunjukkan angka - bagaimana itu dan bagaimana jadinya. Uang muka yang tidak diakui pada awal tahun dan awal bulan adalah taruhan - mereka tidak memperbaiki apa pun. Kemajuan yang tidak diakui untuk hari ini tidak banyak berubah - yang berarti bahwa sekarang dokumen biasanya dibuat. Akibatnya, kesalahan lama diperbaiki dalam 2 hari.

Kasus penggunaan kedua . Otomatis rantai pasokan, fungsinya sederhana - program mengatakan berapa banyak yang Anda butuhkan untuk memesan dari pemasok, ambil dan pesanlah. Secara terpisah, mekanisme yang ditentukan menulis tingkat defisit saat ini. Kami melihat - defisit menurun di beberapa posisi, dan tumbuh di posisi lain. Orang yang berbeda bertanggung jawab untuk posisi tersebut. Pada pertemuan itu semua orang berkata - ya, kami melakukan semua yang diperintahkan, kami melihat, kami memesan. Mengapa defisit tumbuh - kami tidak tahu, otomasi mungkin buruk, jumlahnya salah dihitung. Semua orang menatapku dengan curiga.

Saya berbicara langsung - saya melihat pesanan yang diberikan kepada pemasok. Segera saya tidak bisa mengetahuinya, karena dokumen dimasukkan dan diubah tidak segera - ini normal, karena Proses persetujuan mungkin memakan waktu beberapa hari, dan akan disesuaikan selama ini.

Saya mencatat dua indikator secara terpisah untuk setiap pemasok - berapa banyak barang yang tersedia untuk dipesan di pagi hari, berapa banyak dari mereka yang dipesan pada siang hari. Dan voila - manajer "baik" (gadis rapi) memesan 85-100% dari apa yang dibutuhkan sistem, yang "buruk" - 15%. Semuanya, bekerja dengan disiplin telah hilang. Apa yang menarik - pemasok, melihat laporan ini, diminta untuk memberikannya kepada mereka untuk digunakan (pemasok itu sendiri, dan bukan supervisor mereka). Perbedaan antara saya dan laporan mereka sederhana. Laporan mereka menunjukkan residu saat ini, dan saya masih menunjukkan "seumur hidup" residu ini. Semua Gunung Es yang sama.

Memperbaiki ide

Beberapa kali saya mendengar dari programmer bahwa ide-ide dicuri dari mereka, terutama para bos. Mereka mendengarkan ide itu, kemudian mereka mengatakan bahwa itu bukan tentang apa-apa, dan setelah beberapa waktu mereka menganggapnya sebagai milik mereka.

Saya biasanya punya banyak ide, saya tidak akan menilai kualitas, tetapi sebenarnya ada banyak. Saya perhatikan beberapa tahun yang lalu bahwa saya tidak ingat mereka. Kebetulan saya punya ide beberapa kali.

Kemudian saya melihat di situs web studio Artemy Lebedev bahwa mereka sedang menulis ide , dan mereka pikir itu berguna. Saya memutuskan untuk melakukan hal yang sama - dalam sistem akuntansi tugas saya membuat diri saya sebagai dividen, di mana saya mulai menuliskan ide-ide ini. Itu hanya tersedia di bawah hak penuh, seperti Saya hanya butuh.

Kemudian perusahaan memutuskan untuk mensistematisasikan pekerjaan dengan proposal rasionalisasi - pengarsipan, penilaian, akuntansi implementasi, dll. Saya ditanya apakah mungkin untuk mengotomatisasi, kataku - semuanya sudah otomatis, menunjukkan mekanismenya. Saya memodifikasinya sedikit sehingga ada suara, komentar, implementasi akuntansi, pengaturan tugas, dll. Tapi bukan itu intinya.

Intinya adalah bahwa ide-ide tersebut telah menjadi publik dan tetap, dan menjadi sulit untuk mencurinya. Punyaku hampir mustahil, karena pada saat sistem dibuka untuk pengguna, itu sudah berisi beberapa ratus catatan saya.

Kasus penggunaan pertama bahkan tidak memerlukan partisipasi saya. Banyak orang membaca ide, dan ketika seseorang membuat proposal di suatu tempat, pembaca secara terbuka mengatakan kepadanya - baik, ada ide seperti itu, lihat di sistem, ada diskusi di sana. Jika saya tidak hadir dalam percakapan ini, maka penemu dikirim kepada saya, dan biasanya dia memulai frasa dengan "Anda mengusulkan ide ini, saya membacanya, ini menarik, mari kita terapkan ...".

Contoh kedua terkait dengan promosi sistem proposal rasionalisasi. Secara alami, saya melampirkan pelacakan bacaan ke fungsi memperbaiki ide. Dan ternyata karyawan dari beberapa departemen, yang benar-benar berusaha mengubah pekerjaan mereka menjadi lebih baik, mulai mengajukan proposal mereka ke sistem. Tetapi hanya proposal yang terkait dengan otomatisasi yang diimplementasikan, karena mereka ditujukan kepada saya, tetapi itu menarik bagi saya.

Pada rapat, manajer ditanyai pertanyaan - bagaimana Anda dengan implementasi proposal? Adakah ide yang bermanfaat dari staf Anda? Banyak yang menjawab dengan ramah - tidak, tidak ada yang menarik, semua omong kosong. Saya tunjukkan laporan - mereka tidak masuk sistem sama sekali, mereka tidak membaca satu ide pun, belum lagi implementasinya. Untuk berjaga-jaga, mereka bertanya kepada karyawan - dapatkah Anda memberikan manajer Anda secara lisan atau mengirim saran? Tidak, kata mereka, tidak ada spawn seperti itu, dan secara umum kami takut mengangkat kepala.

Data yang disediakan, prosesnya telah terhenti.

Pengambilan data

Tujuan dari mekanisme ini adalah untuk memperluas kemampuan versi. Biasanya versi (baik standar dan non-standar) menangkap perubahan dalam data primer - direktori, dokumen, dll. Dalam praktik nyata, ini tidak cukup.

Misalnya, "terbang kembali" dengan berbagai variasi "lalat". Cara tradisional adalah dengan melihat perubahan pada dokumen yang dapat mempengaruhi, atau meningkatkan cadangan, mengunggah detail ke Excel dan membandingkan revolusi.

Masalahnya juga adalah bahwa seseorang harus melacak momen "spin-off".

Akibatnya, ia membuat mekanisme sederhana yang dengan indah menyimpan struktur revolusi yang berbelit-belit dan bereaksi terhadap perubahan. Dan area data untuk diperbaiki, dan konvolusi, dan periodisitas - dikonfigurasi melalui kueri.

Tanpa merinci, mekanisme memberi sinyal tentang perubahan di area data ("turnaround telah terbang") selama satu jam (ini adalah frekuensi operasi tugas.), Menunjukkan area data, menunjukkan periode, dan memungkinkan untuk menemukan data primer.

Ya, dan diizinkan untuk "menerima perubahan" - jika semuanya jujur, maka data yang diubah menjadi referensi, dan pelacakan sudah berlangsung.

Kasus penggunaan pertama . Orang-orang mulai mengeluh tentang lonjakan di gudang ("Saya melihat jam 10 pagi, saya melihat jam 5 saat makan siang, dan saya sudah berjanji pada klien, dan saya bukan orang bodoh, saya melihat bahwa tidak ada gerakan selama seminggu"). Akuntansi mengatakan - kita tidak ada hubungannya dengan itu, semua dokumen dieksekusi dalam sehari, tidak ada koreksi surut. Kami melihat mekanisme - voila, saldo hari ini berubah, karena momentum untuk bulan sebelumnya telah berubah. Menyodok - akuntan memperkenalkan dokumen baru sebulan yang lalu. Kami bertanya - apa yang kamu lakukan? Saya tidak punya waktu, katanya.

Kasus penggunaan kedua . Saya mencatat data penjualan - hanya karena saya menguji mekanisme pada area data ini. Diyakini bahwa data penjualan berubah selama maksimal satu minggu, dan kemudian dalam kasus yang jarang terjadi ketika kesalahan dibuat. Dan di sini saya melihat - penjualan bulan lalu telah berubah. Anda mengerti, selama sebulan terakhir, manajer penjualan telah menerima penghargaan. Saya melihat bahwa akuntan telah berubah - apa yang Anda katakan? Ternyata manajer itu memaksa, karena dia terlalu pintar, dia membingungkan klien. Setelah kejadian ini, akuntan berhenti melakukan ini.

Pertanyaan untuk kontrol

Tugas kontrol fungsional, proyek, dll. ada, misalnya, dalam 1C: Manajemen dokumen, mungkin banyak yang telah melihatnya. Di sana Anda dapat mengontrol objek apa pun (atau hampir semua), mengatur tanggal, dan pengingat muncul.

Saya tidak suka yang biasa, karena itu tidak memungkinkan Anda untuk membuat kontrol multi-tahap - misalnya, untuk membuat pengingat muncul 10 kali dalam interval seminggu. Oleh karena itu, saya membuat mekanisme sederhana saya, perbedaan utama adalah bahwa hal itu memungkinkan Anda untuk menyimpan sejarah kontrol dan merentangkannya untuk waktu yang lama.

Misalnya, saya memulai perubahan dalam proses bisnis. Saya menulis surat, mengadakan pertemuan, dll. Saya menulis pertanyaan ini ke sistem saya, meletakkan titik kontrol - dalam seminggu, saya menulis komentar seperti "tanya Vasya lagi". Setelah seminggu saya melihat pengingat, saya bertanya lagi kepada Vasya, Vasya berkata, "aah, dengar, kami memiliki penyumbatan, sejauh ini tidak ada waktu." Ok, kataku, saya menempatkan poin berikutnya - dalam seminggu. Saya melihat pengingat, saya masuk - saya melihat sebuah cerita. Saya bertanya lagi kepada Vasya, Vasya lagi-lagi mengalami penyumbatan. Saya katakan - Vasya, Anda sudah mengatakan itu. Vasya bersumpah bahwa ini adalah yang terakhir kalinya. Setelah satu minggu, gerakan masih dimulai.

Sepertinya semacam sampah, dan sepertinya semua ini bisa diselesaikan melalui surat, tetapi, seperti yang dinyatakan di awal artikel, saya tidak berpura-pura kebenaran. Penggunaan alat dan pendekatan ini telah membantu saya beberapa kali ketika basi untuk mendapatkan sesuatu dari orang yang tidak mematuhi Anda. Anda tidak dapat mengatur tugas untuk mereka, dan untuk melampaui itu dalam situasi khusus ini tidak dengan cara anak-anak - orang tidak akan melakukan apa pun sama sekali.

Akuntansi biaya otomatisasi

Secara teknis, ini sangat sederhana. Ada akuntansi tugas dan proyek dalam sistem. Dalam setiap tugas ada penilaian biaya tenaga kerja tertentu - baik jam atau skor untuk perencanaan poker. Kami tahu gaji programmer. Pelanggan, unit dan manajernya dikenal.

Kami mengambil gaji programmer dan mendistribusikannya ke tugas yang diselesaikan dalam sebulan. Ternyata biaya untuk menyelesaikan masalah tertentu. Itu dapat dirakit oleh proyek, oleh pelanggan, oleh unit.

Contoh penggunaan pertama adalah perlindungan terhadap benturan seperti "mereka tidak berurusan dengan kita, mereka tidak menyelesaikan masalah kita". Kami membuka laporan, lihat - ya, perusahaan menghabiskan 250 tr pada otomasi akuntansi selama sebulan terakhir. Atau 1,5 juta rubel setahun, misalnya.

Di sini masalahnya adalah bahwa itu dihargai dalam rubel - unit ukuran yang dapat dimengerti oleh direktur. Jika Anda mengatakan "kami telah menyelesaikan 113 tugas dari departemen akuntansi", maka dia tidak akan melakukan penetrasi - dia akan mengatakan bahwa lebih banyak yang harus dilakukan. Dan ketika Anda mengatakan "Anda menghabiskan 1,5 juta untuk tugas mereka", dia akan malu untuk mengatakan "menghabiskan 2 juta lagi uang saya untuk mereka!". Lebih sering daripada tidak, dia menghela nafas dan bertanya kepada kantor pembukuan tugas apa yang harus dihabiskan 1,5 juta rubel.

Contoh kedua lebih menarik. Seringkali, programmer mengeluh bahwa mereka melakukan semacam fungsionalitas atas instruksi pengguna, dan kemudian dia tidak menggunakan fungsionalitas ini. Pada saat yang sama, ia terus mengeluh bahwa karyanya tidak terotomasi secara otomatis.

Kami memutuskan untuk menjadi lebih menarik. Dalam tugas yang diselesaikan, mereka mulai menunjukkan tidak hanya pelanggan, tetapi juga nama-nama metadata - dokumen, direktori, dll. Yang dibuat atau diselesaikan dalam menyelesaikan masalah ini.

Nah, maka itu sederhana. Dia meminta kepala layanan kualitas untuk mengotomatiskan verifikasi instrumen pengukuran. Solusi sederhana secara teknis - ada alat ukur, jadwal kalibrasi dan dokumen yang memperbaiki fakta verifikasi. Setelah otomatisasi, seperti yang diharapkan, pengguna memasukkan satu alat ukur, satu dokumen verifikasi dan satu grafik.

Dan kami telah menghitung biayanya. Katakanlah ini 30 tr. Kita tahu metadata, jumlah objek yang kita tahu, membaginya satu sama lain - ternyata dalam sistem kita 30 tr dihabiskan untuk menghitung satu instrumen pengukuran Meskipun alat pengukur sendiri harganya 1 tr.

Ketika kepala layanan kualitas di pertemuan berikutnya mulai memberitahunya bahwa dia perlu mengotomatiskan sesuatu, kami bertanya dengan sopan - bagaimana "kaliper vernier emas" lakukan, untuk akuntansi yang mana verifikasi satu perusahaan menghabiskan 30 tr?

Mendukung akuntansi biaya

Pada kami pada dukungan teknis duduk satu orang - petugas jaga. Saya sering mendengar darinya sesuatu seperti "bagaimana dia mendapatkannya, si bodoh, menanyakan hal yang sama setiap hari." Pada awalnya saya tidak memperhatikan - Anda tidak pernah tahu, orang itu tidak ingat, atau kita yang harus disalahkan. Kemudian, secara tidak langsung, saya mengetahui bahwa beberapa pengguna dengan sengaja meluncurkan serangan DDoS pada dukungan teknis, karena mereka tidak menyukai departemen TI.

Mengatur solusi pemrograman sederhana. Mereka membuat dokumen untuk memperbaiki panggilan ke dukungan teknis. Secara umum, ketika seseorang perlu mengotomatisasi sesuatu, dia tetap menulis tugas, tetapi ketika dia hanya memiliki pertanyaan, dia menelepon atau menulis di Skype.

Orang yang bertugas hanya memasukkan nama belakang dan perkiraan waktu layanan ke dalam dokumen. Dimungkinkan untuk membaca log Skype melalui API, tetapi memutuskan untuk tidak melakukannya - Anda tidak akan menghitung komunikasi pribadi dan korespondensi dengan cara ini.

Nah, maka itu sederhana. Total biaya dukungan teknis diketahui oleh kami dari paragraf sebelumnya. Kami membagi uang pada saat mengajukan banding, kami mendapatkan angka - orang dan departemen seperti apa yang dihabiskan oleh perusahaan sendiri.

Kasus penggunaan pertama adalah hal biasa. Ketika seseorang mengatakan bahwa mereka tidak menjawab pertanyaannya, dan dia melakukannya dengan buruk, kami menunjukkan angka tersebut. Lihat, teman saya, perusahaan menghabiskan 20 tr untuk pertanyaan Anda per bulan.

Contoh penggunaan kedua lebih menarik. Kami menyebutnya "biaya ketidakmampuan." Sayangnya, SDM kami tidak terlalu berpengalaman dalam seluk-beluk akuntansi, dan mereka tidak tahu bagaimana memeriksa persyaratan lowongan "Pengetahuan tentang Program 1C", tetapi tidak ingin mengirimkan kepada kami tes. Jadi kami mendapat akuntan yang tidak tahu cara menyimpan catatan di komputer.

Dan sekarang ada seorang akuntan yang dibayar 30 tr. per bulan, tidak termasuk pajak. Dan ada biaya dukungan teknis yang diberikan kepada akuntan ini. Misalnya, 20 tr per bulan - programmer mahal. Ternyata akuntan merugikan perusahaan 50 tr per bulan. Sebagai contoh, wakil kepala akuntan menghabiskan biaya dalam jumlah yang sama.

Direktur itu sedikit tercengang oleh angka-angka ini. Satu hal yang perlu didengar: “kami menghabiskan 50 tr. per bulan untuk dukungan teknis pengguna ”- oke, Anda harus melakukannya. Masalah yang sama sekali berbeda - “ketidakmampuan akuntan ini menghabiskan biaya 20 tr. per bulan. " Ada lebih sedikit panggilan untuk dukungan teknis.

Tak terlupakan

Ketika kami menyebut biaya otomatisasi, pelanggan mengalami ketidaknyamanan, tetapi hanya sementara. Dia akan dimarahi, mungkin mereka akan menulis beberapa denda, dan lupa. Dia menerima kesenangan, dan dapat memulai dari awal lagi.

Pendekatan ini tidak cocok untuk kita, karena semuanya kembali ke situasi "programmer buruk." Oleh karena itu, kami bertindak sederhana - kami mulai menggunakan statistik akumulasi biaya otomatisasi.

Secara teknis, ini sederhana - kami sudah memiliki semua data, oleh pelanggan, departemen, dan metadata. Dan kami mulai menghapuskan indulgensi.

Ketika percakapan datang lagi bahwa kami tidak menyelesaikan beberapa masalah, atau seseorang tidak terotomatisasi secara otomatis, kami hanya mengangkat laporan dan menunjukkan jumlah yang terakumulasi. Karenakami memiliki statistik yang dirinci berdasarkan metadata, jumlah itu dibagi menjadi dua bagian - baik dan buruk.

Bagus adalah fungsi yang digunakan. Buruk - tidak digunakan. Seseorang yang jahat dua kali lebih baik.

Penguraian versi

Sistem versi di 1C dan dalam CouchDB yang sama bekerja dengan cara yang sama - mereka hanya menyimpan versi objek pada saat merekam. Beberapa menyelesaikan sistem ini - misalnya, jangan menyimpan versi jika tidak ada dalam objek yang berubah.

Pengguna kami, setelah mencari-cari bahwa kami menganalisis pekerjaan mereka, termasuk menggunakan versi, mulai menulis ulang dokumen lebih sering. Yah, untuk jaga-jaga.

Kami kesal karena bisa kehilangan salah satu instrumen pengaruh dan perlindungan kepentingan mereka. Tetapi pikiran programmer menyarankan solusi - biarkan mereka menulis ulang diri sendiri sebanyak yang mereka inginkan, kami akan mengurai dan menganalisis versi untuk perubahan yang berarti.

Akuntan, misalnya, adalah orang yang licik, tetapi mereka takut merusak akuntansi - jika mereka menimpa objek, mereka mengubah beberapa alat peraga yang tidak penting, seperti komentar. Secara formal, versi ini baru, bahkan jika difilter dengan adanya perubahan.

Kami telah menambahkan entitas seperti pandangan kebermaknaan. Mereka hanya mendaftarkan properti objek, perubahan yang, kemungkinan besar, adalah refleksi normal dari pekerjaan seseorang, dan bukan IDB. Ada beberapa tampilan pada jenis objek yang sama. Misalnya, mengubah item dalam pengiriman adalah perubahan besar. Mengubah akun tidak begitu serius, tetapi masih merupakan pekerjaan. Mengubah waktu dokumen dalam satu tanggal - tidak, sayang, hanya kenakalan masa kanak-kanak.

Jadi kami mendapat statistik perubahan dalam hal kebermaknaan. Pengguna, tentu saja, meraba-raba dan mulai lagi DDoS'it - mengubah atribut penting, dalam satu menit, atau sehari kembali. Naif.

Bagaimanapun, kami memiliki kesempatan untuk membandingkan versi tidak secara berurutan, tetapi, misalnya, yang pertama dan terakhir, dan mengabaikan perubahan menengah. Ketika kuartal ditutup, dokumen, dengan probabilitas tinggi, sudah dalam kondisi target, dan Anda dapat dengan aman membandingkannya dengan versi terbaru pada tanggal pembuatan.

Otomasi Korelasi dan KPI

Banyak programmer, atasan dan direktur mereka khawatir tentang dampak otomatisasi pada bisnis. Ada biaya untuk programmer, menyelesaikan proyek, dan menyelesaikan tugas. Dan ada KPI orang, departemen, arahan dan pemimpin mereka.

Diasumsikan bahwa otomatisasi harus bermanfaat, atau, seperti yang mereka katakan dalam lelucon, “manfaat”. Tetapi apa yang sebenarnya terjadi biasanya tidak diketahui.

Berdasarkan hal di atas, jelas bahwa kami memiliki banyak angka tentang otomatisasi. Dan ada departemen KPI yang memesan otomatisasi ini. Sesuatu dianggap otomatis dalam sistem - misalnya, penjualan. Sesuatu dianggap secara manual, di Excel atau di tempat lain. Tetapi ada semua KPI - mereka hanya memperkenalkan semacam sistem motivasi.

Kami, sebagai programmer nyata, pertama-tama mengotomatiskan akuntansi semua KPI. Yang tidak dapat dihitung menurut sistem, hanya diunduh dari Excel. Kami memiliki semua angka yang menjadi ciri pekerjaan karyawan dan departemen perusahaan.

Dari diri kami sendiri, kami menambahkan satu indikator lagi - jumlah karyawan di departemen. Hanya karena ada stereotip seperti itu - otomasi dapat sangat mengurangi jumlah personel yang diperlukan, terutama pemeliharaan, seperti pembukuan atau ekonom.

Dengan KPI dan biaya otomatisasi, sangat mudah untuk menghitung korelasinya, karena semua data disimpan dengan mengacu pada tanggal. Misalnya, kami menyelesaikan proyek otomatisasi senilai 200 tr. pada bulan Januari - KPI unit masing-masing harus berubah. Tidak segera, tetapi, katakanlah, pada bulan Februari, atau pada bulan Maret, atau bahkan pada bulan Juni. Tetapi harus. Kalau tidak, apa gunanya?

Anehnya, ada korelasi. Misalnya, dalam pekerjaan pengadaan, kami telah melakukan proyek otomatisasi TOC, dan KPI mereka telah berkembang. Bahkan penjualan telah tumbuh sejak itu mereka adalah tujuan dari otomatisasi pengadaan, pada akhirnya.

Namun ada contoh kurangnya korelasi. Misalnya, implementasi CRM tidak membawa apa-apa. Membuat situs, bukan yang sebelumnya, tidak membawa efek apa pun.

Semua otomatisasi akuntansi hanya membawa efek negatif, terutama pada ukuran staf mereka, terlepas dari semua upaya kami untuk menahan kanker perusahaan ini.

Tetapi otomatisasi ekonom akuntansi memiliki efek positif - kami kehilangan dua karyawan. Mereka tidak dipecat - mereka sendiri pergi, karena alasan mereka sendiri. Tetapi kami menyarankan - jangan mengambil yang baru, lihat bagaimana kelanjutannya, kami otomatis banyak di sana. Direktur setuju, dan semuanya berhasil.

Setelah korelasi dihitung, manajemen mulai melihat berbeda pada otomatisasi. Ya, untuk programmer, tentu saja. Terutama mengingat fakta bahwa tidak ada yang memerintahkan kami untuk menghitung korelasi ini - ini adalah inisiatif kami.

Benar, lalu sutradara diganti, dan semuanya harus dimulai dari awal. Tapi, sekitar enam bulan kemudian, direktur baru juga menghargai perhitungan korelasinya.