Gunung es

Semua orang tahu apa itu gunung es - sepotong besar es yang mengapung di lautan. Semua orang ingat apa yang salah dengan gunung es - hanya sebagian kecil yang terlihat, yaitu di atas permukaan air, sisanya tersembunyi. Dan berapa banyak yang ada, sisanya - tidak ada yang tahu.

Situasi serupa adalah dengan data dalam sistem otomatis.

Kami biasanya melihat data itu sendiri. Dokumen, seperti faktur pengiriman atau tanda terima, transfer, pembayaran, dll. Direktori - nomenklatur, rekanan, unit. Kami melihat tugas, baik yang biasa maupun yang sedang diproses. Kita melihat sisa-sisa - berapa banyak barang dalam persediaan, siapa yang berutang uang kepada kita, berapa banyak defisit yang kita miliki, dll.

Data apa pun, secara individu atau kombinasi, membentuk keadaan tertentu. Sebagai contoh, gudang kami, setiap saat, dalam kondisi tertentu. Kami mengatakan begitu - keadaan gudang. Atau status piutang, atau hutang, atau status tugas, atau status proses.

Kami cukup mampu menilai kondisi secara instan - baik dalam sistem otomatis dan dalam kehidupan. Diperkirakan, kabur dan lupa.

Kemudian, setelah beberapa waktu, kami kembali menemukan data, atau situasi yang sama. Kami kembali membuat penilaian instan terhadap negara - kami mengatakan "semuanya baik" atau "semuanya buruk". Ini diulangi untuk yang kedua, ketiga, seratus dua puluh lima.

Jika kita menilai situasi sebagai hal yang kritis, maka, mungkin, kita akan memperbaikinya. Dan jika tidak? Ya, situasinya tidak terlalu baik, tetapi tampaknya Anda bisa hidup. Ini sering terjadi pada rapat operasional - seseorang mengajukan pertanyaan, menceritakan situasinya, memberikan penilaian. Semua orang mengerang, atau membentak lidah mereka dan ... apa? Sebagai aturan, mereka lupa. Sampai waktu berikutnya, sampai orang lain memperhatikan.

Setiap kali situasi negatif menjadi kesenangan, karena kami melihatnya seolah-olah untuk pertama kalinya. Seseorang, tentu saja, ingat - oh, itu sudah terjadi, saya tidak ingat, seperti sebulan yang lalu, atau mungkin enam bulan. Mereka menyodok dudukan memori yang terlalu bagus untuk diam - biarkan situasinya dianggap lebih baik sebersih bayi.

Mengapa ini terjadi? Apa yang hilang dalam informasi situasi negatif? Ada penilaian instan, cukup berkualitas tinggi dan detail. Bagaimana melanjutkan kalimat "semuanya buruk di sini," sehingga ia bermain dengan warna baru dan menjadi lebih informatif?

Sangat sederhana untuk melanjutkan kalimat: "semuanya buruk di sini, dan untuk waktu yang lama." Waktu atau lamanya negara adalah informasi yang diperlukan untuk keputusan yang memadai.

Dalam hidup, semua orang mengerti ini. Biarkan saya memberi Anda beberapa contoh.

“Saya tidak punya cukup uang” - penilaian instan, membutuhkan intervensi bedah. “Saya tidak punya cukup uang selama setahun sekarang” - wow, kami memiliki masalah sistemik di sini, di mana kami harus berpikir keras dan mengubah sesuatu dalam hidup.

"Sesuatu menyakiti kaki saya" - yah, Anda tidak pernah tahu, ia mungkin telah menghabiskan waktu, atau cuaca memengaruhi artritis. "Kakiku sakit selama enam bulan sekarang" - segera berlari ke klinik.

"Seorang anak membawa deuce" - dilakukan dengan baik, ini saatnya, deuce dibutuhkan untuk keseimbangan. "Seorang anak hanya membawa dua orang untuk seluruh kuartal" - oh, kau bodoh di bawah umur, apa yang kau lakukan di sana, besok aku pergi ke sekolah, di mana nomor telepon guru kelasmu.

Demikian pula dalam sistem bisnis.

"Klien berhutang satu juta pada kami" - yah, bayar apa yang kau bayar. "Klien berhutang satu juta kepada kami selama enam bulan sekarang" - ibumu, di mana Anda melihat?

"Ada lima posisi mendesak dalam pernyataan defisit" - para pemasok akan memesan, itulah sebabnya orang tidak boleh ditarik. "Lima posisi mendesak telah menggantung dalam posisi defisit selama dua bulan sekarang" - itu sebabnya penjualan jatuh! Seret semua orang ke karpet, segera beli!

"Programmer sudah menunggak tugas saya" - ya mereka semua tugas jadi, jangan khawatir. Akan lakukan. "Programmer sudah menunggak tugas saya selama dua bulan" - sial, saya sudah lama ingin membubarkan bajingan ini, apa yang mereka lakukan di sana?

Seperti yang Anda lihat, durasi suatu kondisi, terutama yang negatif, memberikan informasi dimensi baru. Seolah-olah ada informasi datar dan membosankan yang tidak jelas apa yang harus dilakukan, tetapi gambar tiga dimensi diperoleh. Menganalisis situasi dan membuat keputusan menjadi lebih mudah.

Semuanya sangat jelas di sini sehingga saya bahkan tidak dapat mempercayainya - apakah hal-hal sepele seperti itu memiliki bab tersendiri dalam buku pelajaran? Untuk menjawab pertanyaan ini, lihat sistem informasi Anda.

Apakah Anda menemukan banyak kondisi dengan durasi yang diukur? Secara tradisional, ada dua laporan berdasarkan prinsip Iceberg: aset tidak likuid dan tunggakan. Apakah Anda, omong-omong, melihat aset tidak likuid? Tidak dalam semua, bahkan sistem umum, aset tidak likuid dapat dilihat.

Sayangnya, dalam sistem informasi bahkan tidak ada konsep "negara". Ada data dan cara melihatnya, dari sudut yang berbeda. Hamparan apik untuk seorang analis yang suka mencari-cari dalam jumlah besar, tetapi tidak cukup informasi yang masuk akal untuk membuat keputusan. Selain itu, tidak masalah siapa yang membuat keputusan - orang atau sistem itu sendiri.

Ada beberapa cara untuk menerapkan prinsip Gunung Es. Akuntansi batch tradisional, ketika pemisah ditambahkan ke array informasi - dokumen batch. Sebagai contoh, barang tiba di gudang - kita ingat tidak hanya nomenklatur dan kuantitas, tetapi juga dokumen penerimaan - faktur. Faktur memiliki tanggal, dan darinya kami selalu dapat menghitung tanggal jatuh tempo. Mereka melakukan hal yang sama, misalnya, dengan piutang - mereka tidak hanya menyimpan rekanan dan jumlahnya, tetapi juga dokumen yang menciptakan utang ini - misalnya, faktur pengiriman, atau pembayaran uang muka kepada pemasok.

Dalam istilah teknis, dokumen partai menciptakan banyak kesulitan.

Pertama, ini meningkatkan jumlah catatan dalam tabel. Satu entri “Selongsong, 10 buah” dapat berubah menjadi sepuluh entri - “Selimut 1 pc dari 09/01/2017”, “Selimut 1 pc dari 12/09/2017”, dll.

Kedua, algoritma pembatalan batch diperlukan. Misalnya, saat pengiriman (mis. Menghapus barang), Anda perlu tahu dari batch mana menjadi minus sisanya. Atau ketika membayar dari pembeli, Anda perlu menunjukkan dokumen pengiriman mana uang itu berasal. Dua pendekatan digunakan: perhitungan otomatis batch atau indikasi manualnya. Pemilihan batch otomatis adalah strategi penghapusan terkenal FIFO (pertama, batch paling awal) dan LIFO (pertama, batch terbaru). Identifikasi batch manual umumnya digunakan dalam memposting pembayaran.

Masalah ketiga, lebih merupakan masalah metodologis, adalah bahwa kehidupan nyata tidak mematuhi algoritma penghapusan lot. Pemilik toko akan mengambil bagian dari rak, tetapi bukan yang dipilih oleh program. Dia tidak tahu apa itu FIFO.

Ternyata sistem yang secara teknis rumit, yang hasilnya jarang digunakan. Saya tidak berbicara tentang akuntansi atau akuntansi manajemen, yang menggunakan banyak untuk menghitung biaya penghapusan. Saya berbicara tentang mengukur durasi keadaan negatif - aset tidak likuid. Berapa banyak yang Anda harus lihat benar-benar, secara teratur dan efektif bekerja pada proses aset tidak likuid?

Cara kedua adalah tidak menyimpan durasi semua negara, tetapi menghitungnya jika perlu. Ini adalah perkiraan durasi instan. Misalnya, seseorang dapat menemukan aset tidak likuid di gudang tanpa menyimpan banyak. Ada banyak cara - misalnya, memahami saldo saat ini, secara retrospektif melihat pergerakan barang. Jika tidak ada pergerakan, maka di depan kami adalah aset tidak likuid.

Metode ini tidak memiliki kelemahan dari akuntansi batch - tidak memerlukan penyimpanan sejumlah besar data dan tidak menyulitkan pekerjaan saat ini. Tetapi keuntungan utama dari akuntansi batch - penyimpanan durasi - tidak ada di dalamnya. Anda melihat perkiraan durasi hanya secara instan, pada titik waktu tertentu. Kami masuk, melihat, menghargai, keluar - evaluasi durasi lenyap.

Di satu sisi - oke, tidak apa-apa. Anda dapat mengambil algoritme untuk menghitung durasi, dan menyematkannya dalam proses - biarkan sistem bereaksi ketika keadaan negatif terus berlanjut. Tapi, sayangnya, perkiraan sesaat dari durasi tidak begitu instan - sumber daya sistem dihabiskan untuk perhitungan sehingga hanya biaya kebisingan, setiap menit Anda tidak berjalan.

Perkiraan instan durasi dapat digunakan untuk proses yang tidak terlalu penting yang tidak perlu dipantau setiap hari. Misalnya, aset tidak likuid yang sama saat Anda membangun proses pembuangannya - sebulan sekali Anda membuat perhitungan, menentukan daftar barang yang paling terakumulasi, dan membentuk tugas membuangnya (misalnya, menjual dengan diskon atau diskon).

Cara ketiga adalah menghitung, memisahkan, menyimpan, dan melacak status yang dipotong.

Misalnya, Anda memiliki pernyataan defisit - daftar barang yang perlu Anda beli. Untuk produksi, penjualan, perbaikan, dll. Tidak masuk akal untuk memantau seluruh pernyataan defisit - posisi yang cukup kedaluwarsa. Posisi masa lalu ini patut disorot, karena jumlah mereka tidak banyak?

Simpan saja di tempat terpisah dalam sistem daftar item kadaluarsa, dengan jumlah dan, yang paling penting, tanggal terjadinya. Lagi pula, tidak selalu ada posisi kedaluwarsa di sana? Begitu mereka muncul - ingat, dan tanggal penampilan akan menjadi titik awal durasi.

Kemudian sistem melakukan semuanya dengan sendirinya. Periksa defisit secara berkala - periksa apakah ada posisi kedaluwarsa. Jika tidak, sangat baik, maka keadaan negatif telah berhenti. Daftar posisi tertunda yang disimpan dapat dilupakan dan dihapus dari sistem (di sini, atas pertimbangan Anda, Anda dapat menyimpannya dalam memori, mis. Untuk analisis retrospektif atau sistem motivasi). Jika posisi kedaluwarsa masih terbatas, ini juga baik (untuk sistem), karena Anda tidak perlu melakukan apa pun, jam terus berdetak dan durasinya bertambah.

Seseorang yang mengawasi defisit yang sudah lewat akan senang. Pertama, dia tidak bisa lagi mengawasi - cukup mengatur pemberitahuan tentang penundaan tersebut. Kedua, Anda tidak perlu lagi mencari tahu apakah penundaan sudah lama muncul - durasinya akan ditampilkan secara otomatis. Ketiga, tidak perlu melacak saat hilangnya penundaan - sistem akan memberi tahu Anda ketika semuanya berjalan dengan baik.

Akan lebih mudah bagi Anda, sebagai programmer bisnis, untuk membangun proses respons dalam sistem bisnis. Meskipun tidak ada pemahaman tentang durasi, Anda dipaksa untuk segera menarik orang itu, segera setelah keadaan negatif muncul. Dan "kedutan" Anda akan menggantung terus-menerus di depan hidung Anda, seperti kain merah.

Ketika ada durasi, pengaturannya menjadi lebih baik - Anda sendiri yang memilih saat kapan menunjukkan masalah kepada seseorang. Anda juga dapat memilih tampilan warna berdasarkan durasi kondisi negatif. Misalnya, kuning - satu hari, merah - dua hari atau lebih, dll.

Pada saat yang sama, Anda dapat membangun sistem respons hulu. Misalnya, pertama-tama perlihatkan penundaan defisit kepada pemasok. Sehari kemudian, jika tidak dihilangkan, ke kepala pasokan. Tiga hari kemudian, kepada direktur komersial. Dalam seminggu - kepada direktur.

Selain itu, Anda mengerti: esensinya tergantung pada tingkat di mana tugas telah meningkat. Anda meminta pemasok untuk menghilangkan penundaan - dia harus memesan posisi. Anda meminta manajer persediaan untuk memperhatikan dan, mungkin, memindahkan posisi ke pemasok lain. Anda mengatakan kepada direktur bahwa seluruh layanan pasokan entah bagaimana bekerja dengan aneh, perubahan sistem diperlukan.

Fitur utama dari metode ini: penyimpanan data status yang terpisah dan pembaruan otomatisnya. Secara teknis diimplementasikan menggunakan prinsip "Auto Task", yang akan dibahas nanti.

Dalam prosesnya, Anda pasti akan menemukan cara lain untuk menentukan durasi negara, mis. besarnya gunung es bawah laut. Anda mungkin pemrograman dalam sistem di mana metode yang saya daftarkan tidak berfungsi - maka Anda harus mencari sendiri.

Hal utama - jangan lupa tentang prinsip "Gunung Es" saat pemrograman sistem bisnis.

Terutama jika Anda ingin menggunakan akuntansi partion - itu perlu diletakkan kembali selama desain, secara retrospektif digunakan dengan kesulitan besar.

Penilaian instan durasi, seperti "AutoTasks", dapat dimasukkan kapan saja. Yah, matikan juga. Dalam terang ini adalah keuntungan mereka.

Saya akan memberikan beberapa contoh penggunaan Gunung Es dari tempat praktik saya.

Contoh pertama adalah sistem manajemen tugas. Ada tugas, atau tugas, atau memo. Ada inisiator, ada pemain. Ketika tugas diterima ke dalam pekerjaan, semuanya jelas - ada tenggat waktu, dan Anda dapat dengan cepat menentukan apakah semuanya dengan tugas itu baik atau tidak.

Tetapi masalahnya juga memiliki beberapa kondisi perantara. Misalnya, pemrakarsa menulis, mengirimnya, dan pelaksana harus menerimanya untuk bekerja. Penerimaan dalam pekerjaan adalah tanda tertentu dalam suatu tugas. Sampai kontraktor meletakkannya, status tugasnya adalah bagian bawah laut dari gunung es. Tidak ada hal yang jelas ketika dia akhirnya berkenan untuk melakukannya.

Saya bertindak sederhana - saya menambahkan tanggal penerimaan untuk bekerja sebagai bidang terpisah dalam tugas. Diterima - tanggal diingat. Dan tanggal pengiriman tugas ke pelaksana sudah ada di sana. Dengan demikian, kita mendapatkan dua durasi keadaan negatif. Sampai tugas diterima, durasi adalah perbedaan antara tanggal saat ini dan tanggal pengiriman. Namun, ketika kontraktor menerimanya, interval yang tepat antara penerimaan dan pengiriman muncul, yang selamanya diingat dalam sistem dan digunakan untuk analisis lebih lanjut.

Situasi serupa, dengan durasi yang tidak dapat dipahami, terjadi ketika kontraktor melakukan pekerjaan dan mengirimkannya ke pemrakarsa untuk verifikasi. Ketika dia memeriksa di sana, itu tidak diketahui. Setiap programmer yang layak bekerja secara langsung dengan pengguna akhir akan mengkonfirmasi bahwa tugas-tugas sangat sering macet saat ujian. Apalagi secara fisik sudah bisa dicek, pengguna suka semuanya, tapi dia tidak repot-repot login ke sistem dan membuat catatan.

Solusinya mirip. Kami menambahkan dua tanggal ke tugas - ketika kontraktor mengirim untuk verifikasi, dan ketika inisiator bereaksi, ia menerima hasilnya atau dikembalikan untuk revisi. Karenanya, durasi status verifikasi selalu ada, dan kami dapat menormalkan waktu verifikasi tugas. Ya, jadi tidak.

Contoh favorit saya adalah pengadaan. Semuanya sederhana dengan tugas - selalu ada objek tempat tugas ini direkam, dan Anda bisa menambahkan bidang ke objek ini yang menyimpan data selama durasi negara.

Dan pengadaan adalah sebuah arus. Tidak ada seorang pun di sana, yang waras, akan melakukan tugas yang terpisah. Bayangkan diri Anda - seorang gadis duduk, memesan bushing. Setiap hari Busing yang sama. Dan juga poros, baut, mur, logam, tempa, cap, dll.

Hanya ada informasi tentang apa yang perlu dipesan. Ya, itu terjadi pada berbagai tingkat detail - terkadang hanya daftar barang dan jumlah, kadang-kadang - oleh penerima, kontraktor, pesanan, unit, dll. Tetapi informasi ini selalu instan, seperti flash. Saya masuk - Anda lihat, Anda perlu memesan 1020 buah. Semenit kemudian dia masuk - wow, sudah 1.200, karena situasinya telah berubah.

Pengusaha memahami ini dan memanfaatkannya. Pada pertemuan, pembekalan dan operasi, pembeli sering mencoba untuk sampai ke dasar, tetapi dari mereka, seperti air dari bebek. Mereka memberi tahu mereka - eh teman-teman, dan busing apa yang hilang? Jadi kemarin, hanya kebutuhan yang muncul! - jawab itu. Bagaimana dengan kemarin? Ya kemarin. Saya bersumpah saya pergi ke kekurangan tadi pagi, tidak ada semak!

Untuk membuktikan bahwa selongsongnya kemarin, Anda hanya bisa dengan menaikkan cadangan. Tentu saja, orang yang masih hidup tidak akan mengambil cadangan setiap hari, sehingga penjual dan produsen yang lelah menghasilkan versi mereka sendiri dari Iceberg - cetakan. Misalnya, mereka memasuki sistem pada hari Senin, melihat defisit, dan mencetaknya. Ketika masalah muncul, atau parut dengan pemasok, tunjukkan pada mereka selembar kertas ini.

Tetapi mudah untuk menghindari selembar kertas seperti itu. Penjual berkata - apa yang Anda selipkan di sini? Ya, tidak ada lengan baju yang cukup pada hari Senin, jadi apa? Sudah pada hari Selasa ada begitu banyak sehingga semua orang akan memiliki banyak Dan apa yang Anda lihat dalam sistem hari ini baru muncul kemarin.

Kemudian mereka juga dipaksa untuk berpartisipasi dalam urusan kertas - mereka tidak hanya mencetak kekurangan, tetapi juga memberikan tanda tangan kepada pemasok. Dan tanggal pengiriman diminta untuk ditempelkan. Anda mengerti bahwa proses dalam hal efisiensi sangat-sangat-begitu.

Iceberg Prinsip bekerja dalam tugas, tetapi tidak bekerja dalam persediaan. Penjual memahami bahwa sesuatu harus dilakukan, dan mereka mulai menetapkan tugas untuk pembelian - mereka secara langsung menciptakan objek, memasukkan daftar posisi ke sana, dan menunggu eksekusi. Pada awalnya itu mulai berhasil, kemudian para pemasok mulai dengan bodoh menolak tugas-tugas seperti itu, dengan komentar seperti "kita tidak perlu meletakkan instruksi terpisah untuk pekerjaan rutin kita". Secara umum, komentar yang benar adalah bahwa jika Anda menetapkan tugas untuk semua orang, maka pembersih harus terhubung ke sistem.

Masalahnya dipecahkan oleh tugas-otomatis dan Gunung Es, yang ada secara default. Autotask hanya menampar defisit, memecah posisi yang hilang oleh pemain, dan membentuk beberapa objek yang berisi informasi tentang apa yang perlu dipesan dari pemasok. Tanggal pembentukan tugas otomatis diperbaiki secara otomatis, serta tanggal eksekusi, mis. penempatan posisi dengan pemasok.

Jika perlu, misalnya, 100 busing, dan pemasok memesan 70, maka autotask tidak menutup, tetapi hanya disesuaikan - sekarang Anda perlu menempatkan 30 posisi. Yang penting adalah tanggal mulai dari keadaan negatif, mis. Defisit tetap sama. Seseorang memesan 70 posisi untuk satu interval waktu, dan 30 untuk yang lain.

Dengan penerapan Iceberg, masalahnya diselesaikan dengan sangat cepat, karena tidak mungkin menyembunyikan apa pun. Pertama, memperhitungkan durasi defisit dilakukan dalam konteks posisi dan kuantitas, dan kedua, dengan merujuk pada kontraktor.Segera, tentu saja, KPI tertentu lahir untuk pemasok - berapa persen posisi yang dia pesan tepat waktu (tampaknya dia harus memenuhi hari itu, sejak saat diperlukan).

Gunung es jatuh pada akuntansi. Bagi mereka, bagaimanapun, selalu ada sesuatu yang salah di suatu tempat. Saldo negatif hadir, dalam berbagai akun, atau dalam register yang mereka benci. Uang muka tidak dihitung, meskipun penerapan pemulihan urutan pemukiman. Belum lagi saldo total tanpa kuantitas, dan sebaliknya.

Dalam keadaan normal sistem, tanpa Gunung Es, sulit untuk sampai ke departemen akuntansi. Satu-satunya cara untuk membuktikan bahwa kontra telah menggantung selama sebulan adalah cadangan. Tetapi mereka juga tidak bodoh - mereka akan mengatakan bahwa ya, ada kontra sebulan yang lalu, lalu kami menghapusnya, dan sekarang kami keluar lagi, Anda para programmer yang telah mencampuradukkan sesuatu. Jika pemasok hanya memaafkan diri mereka sendiri tanpa mengalihkan masalah ke orang lain, maka akuntan telah lama memikirkan - saya tidak tahu, secara sadar atau tidak - metode seperti tekanan waktu buatan.

Ada seorang programmer yang layak di perusahaan yang mengurus keadaan akuntansi. Dia melihat kontra di belakang, dan memberitahu akuntan - bibi sayang, apa yang kamu lakukan, mari kita hilangkan itu! Pada awalnya mereka mengatakan - ya, tentu saja, kami akan menghilangkan, itu demi kepentingan kami. Kontra akan sangat menghalangi kita saat menutup kuartal, pastikan untuk menghilangkannya. Pada saat ini - katakanlah, ini Mei - tidak ada tekanan waktu, mis. tidak ada yang memiliki waktu terbatas untuk menyelesaikan masalah. Oleh karena itu, tugas memulihkan pesanan, seperti yang diharapkan, ditunda ke kotak jauh.

Hampir tidak mungkin untuk mencegah penciptaan residu negatif dengan metode pemantauan pekerjaan harian saat ini. Bahkan jika Anda melarang penghapusan hingga minus - ada koreksi paroki. Oleh karena itu, programmer kami yang layak mengeluh dan menunggu.

Sebelum akhir Juni, programmer, misalnya, mengingatkan akuntan beberapa kali bahwa akan baik untuk menghapus kontra. Semakin dekat tenggat waktu, semakin agresif jawaban itu - persetan, itu bukan urusan Anda, jangan mengajari kami cara bekerja, dan, pada akhirnya, abaikan sepenuhnya.

Dan kemudian datang bulan Juli, perlu untuk menutup kuartal. Sekarang masalahnya harus diselesaikan dalam mode tekanan waktu - secepat dan seefisien mungkin, karena masih ada banyak hal yang harus dilakukan, kecuali untuk minusnya. Jika Anda bekerja sebagai programmer di pabrik, maka Anda tahu apa yang terjadi saat ini - tugas dengan cepat dan indah bergeser dari akuntansi ke programmer.

Sudah terlambat untuk marah, meskipun programmer mencoba. Tetapi akuntan memberikan argumen besi - semuanya, sekali, perlu untuk menyerahkan pelaporan, dan ada denda soooo bahwa perusahaan harus ditutup. Tidak ada yang tersisa bagi pemimpin yang memoderasi penyalahgunaan programmer dan akuntan bagaimana memihak yang terakhir - ancamannya terdengar terlalu nyata. Si programmer sedang merengek sesuatu di sana, seperti ini adalah pekerjaan seorang akuntan, mereka tahu apa yang harus dilakukan, dan secara umum seorang programmer membebani perusahaan tiga kali lebih banyak daripada seorang akuntan, dan semua ini salah, tetapi semuanya sudah terlambat, tetapi sudah terlambat - masalah waktu buatan telah dibuat.

Biasanya berakhir seperti ini: programmer setuju untuk memperbaiki minus dengan tangannya sendiri, dan manajer dan akuntan berjanji untuk mengatasi masalah sistemik ini setelah menghilangkan tekanan waktu. Dan - setiap saat.

Solusi untuk masalah ini mirip dengan penawaran. Kami melakukan tugas-otomatis untuk setiap varian kusen - misalnya, kami menghitung dan menunjukkan minus dalam turnaround, mengatur yang bertanggung jawab dan, yang paling penting, tanggal tugas muncul untuk mendapatkan Iceberg. Sekarang, segera setelah minus muncul, tugas otomatis muncul, dan itu dapat digunakan sebagai argumen dalam perselisihan.

Jelas bahwa akuntansi akan mengabaikan tugas-tugas ini. Tetapi kemudian sesuatu yang kurang dimiliki programmer pada pertemuan dengan manajemen akan muncul - fakta. Inilah kusennya, ini adalah tanggal kemunculannya, di sini adalah durasi keadaan negatif - sebulan, misalnya. Yang terpenting adalah mengirimkan informasi dengan benar - lihat, pemimpin terkasih, akuntansi kami telah dalam keadaan tidak terkendali selama sebulan sekarang, kami tidak tahu berapa biaya gudang kami, berapa biaya yang kami keluarkan, karena kami memiliki kerugian. Anda mengerti, pemimpin yang terhormat, intinya bukan di minus, tetapi dalam kaitannya dengan akuntansi. Minus adalah situasi yang ekstrem, kesalahan yang jelas dan nyata. Dan masih ada yang tersirat yang tidak terlihat oleh mata, tetapi menghalangi Anda kesempatan untuk menggunakan data. Baik dan sebagainya.

Bahkan Iceberg secara langsung meminta proses apa pun di mana ada kesepakatan. Aplikasi untuk menghabiskan uang, kontrak, spesifikasi, anggaran, rencana, penerbitan pakaian khusus dan sebagainya, hingga tak terbatas.

Birokrat suka koordinasi, tetapi bukan sebagai proses yang perlu dilakukan, tetapi sebagai proses yang bisa tertunda tanpa henti. Programmer naif, yang ditugaskan untuk menambahkan persetujuan dari kepala akuntan atau direktur keuangan untuk kontrak, bertindak sederhana dan bersahaja - menambahkan bidang tertentu, seperti "Setuju", ke dalam kontrak ini. Dia tidak tahu tentang Iceberg, jadi dia mengalami proses negosiasi perjanjian untuk kematian yang lambat dan menyakitkan.

Koordinasi tidak akan ada habisnya secara dinamis jika kontrak tidak terlalu signifikan dan tidak dalam bidang visi direktur. Dan para penggagas perjanjian tidak akan punya pilihan selain berlari secara berkala ke akuntan kepala untuk mencari tahu kapan sakramen besar akan terjadi.

Gunung es memecahkan masalah dengan segera dan cepat. Dalam hal ini, cukup mengetahui dua tanggal - kapan dikirim untuk persetujuan, dan kapan itu terjadi. Durasi keadaan inkonsistensi dalam kasus ini dihitung secara elemental, dan Anda dapat menormalkan waktu ini secara sepele.

Saya melakukan ini dengan koordinasi kontrak, di mana rantai terdiri dari beberapa orang - kepala unit, pemodal, akuntan dan pengacara. Masing-masing diberi satu hari untuk persetujuan, dan Iceberg membawa persentase hit pada periode ini menjadi 90%.

Namun, kemudian masalah dimulai - ketika perjanjian disetujui dan ditandatangani di atas kertas, kedua salinan dikirim ke rekanan untuk membubuhkan tanda tangan dan stempel. Dengan demikian, selembar kertas kemudian harus kembali untuk masuk ke arsip departemen hukum.

Tetapi orang-orang yang sebelumnya mengeluh tentang persetujuan panjang tidak terburu-buru untuk menyerahkan aslinya kontrak kepada pengacara. Mereka umumnya lupa tentang itu - cukup bagi mereka bahwa kontrak ditandatangani, dan Anda dapat bekerja dengan rekanan. Di sini para pengacara melolong - tidak mungkin tanpa dokumen asli, setiap cek akan sesuai dengan perusahaan Auschwitz sedemikian rupa sehingga tampaknya tidak cukup.

Dengan demikian, gunung es lain tampaknya menyerahkan dokumen asli kontrak. Mengalokasikan satu bulan untuk biasa, dan 100 hari untuk perjanjian perdagangan luar negeri. Dan semuanya berhasil. Terutama ketika pengacara mulai menolak kontrak baru sampai yang lama diserahkan. Gambaran jumlah dan waktu kontrak yang gagal selalu tersedia dalam sistem, dan, mengingat pentingnya masalah ini, itu berada di bawah kendali konstan manajemen. Tidak ada yang ingin terlalu sering memasuki ruang lingkup sutradara, sehingga dokumen aslinya hampir selalu dikirimkan tepat waktu.