Saya tidak mengatasinya, tetapi saya setuju bahwa
rasa sakit diperlukan untuk memahami solusi dan kegunaannya, atau, seperti yang dikatakan orang-orang berjas,
sakit . Jika Anda tidak mengalami kesulitan dengan kekurangan, kelebihan stok, keterlambatan pengiriman, dan gejala lain dari perencanaan yang buruk - bagus sekali, artikel itu bukan untuk Anda, dan dengan kemungkinan besar masalah yang tercantum di sini tidak akan merespons dalam jiwa Anda.
Jika Anda pernah mengalami, atau sekarang mengalami rasa sakit karena perencanaan di 1C, maka mari kita sakit bersama dan mencoba untuk pulih.
Artikel ini ditulis terutama tentang SCP. Beberapa masalah telah dihapus dalam ERP (pada saat yang sama menambahkan yang baru), tetapi rasa sakitnya masih ada sampai hari ini.
Jadi ayo pergi.
Keamanan
Pertama dan terpenting, bagaimana Anda tahu kebutuhan mana yang dipenuhi dan mana yang tidak? Jadi saya punya pesanan pelanggan, atau rencana penjualan, atau pesanan internal, atau pesanan produksi - ini adalah kebutuhan saya (lebih tepatnya, pembeli). Ada stok di gudang, ada pesanan ke pemasok (pembelian dan pemrosesan), ada rencana pembelian pada akhirnya - ini adalah sumber daya saya. Bagaimana menjawab pertanyaan - kebutuhan mana yang dipenuhi dan mana yang tidak? Nah, segera pertanyaan petugas - apa yang hilang? Apa yang perlu Anda beli atau hasilkan?
Tidak ada jawaban sederhana untuk pertanyaan ini dalam konfigurasi 1C. Meskipun tugas, pada pandangan pertama, sepele - mengambil semua sumber daya, mendistribusikannya sesuai dengan kebutuhan Anda, dan Anda akan bahagia. Tampaknya laporan sederhana seharusnya membantu, tetapi ternyata tidak.
Saya, seperti Anda juga, melakukan laporan seperti itu. Untuk jawaban kasar atas pertanyaan yang diajukan, laporan itu cukup cocok, tetapi siapa yang butuh jawaban kasar? Orang-orang memiliki bisnis, jawaban atas pertanyaan tergantung pada biaya uang, aset tidak likuid, kesenjangan uang tunai, hubungan dengan pelanggan.
Dalam upaya untuk mengklarifikasi jawabannya, laporan saya mulai tumbuh menjadi kondisi dan reservasi. Sebagai contoh, rekanan ini adalah yang utama, harus diberikan stok di gudang terlebih dahulu. Tapi dia tidak masuk akal untuk mengambil stok dari gudang ini - ini adalah ujung lain negara itu, hanya dengan pesawat yang bisa dibawa, dan hanya dalam keadaan darurat. Atau gudang ini hanya untuk unit X, tetapi jika ada kebutuhan khusus, atas perintah direktur, orang-orang dari unit Y dapat mengambil sesuatu dari gudang ini, tetapi mereka harus menempatkan pesanan internal yang akan dijalankan dengan relokasi.
Kemampuan skema tata letak dan bahasa kueri tidak lagi cukup untuk menggambarkan semua kondisi untuk menghitung keamanan, dan penyetelan manual muncul. Laporan mulai terlihat semakin mirip monster yang menakutkan, dan di sini semakin banyak masalah baru dengan kualitas data yang terus ditemukan.
Kemudian mimpi buruk lain terjadi - proses bisnis berubah, pada saat yang sama struktur staf berubah, campuran departemen, jumlah gudang berlipat ganda, muncul rencana produksi, dokumen baru jenis “Permintaan Pembeli” muncul, yang mendahului pesanan pembeli, dll. Singkatnya, ada begitu banyak alasan atas kematian Laporan sehingga tidak lagi menentang.
Asisten perencanaan
Bagian dari masalah penghitungan keamanan di SCP diputuskan oleh "Asisten Perencanaan". Saya sangat suka alat ini, ia memiliki ide dan pendekatan yang keren. Namun, sayangnya, ia tetap menjadi prototipe untuk memecahkan masalah bisnis yang nyata. Saya tidak akan memberi tahu lama tentang asisten kakek, jika Anda mau, Anda dapat dengan mudah menemukan banyak informasi tentang batasannya (bottleneck, misalnya).
Sehubungan dengan perhitungan keamanan, kelemahan utama dari "Asisten Perencanaan" adalah kebutuhan untuk terus
menggunakannya . Gambaran nyata tentang keamanan berubah setiap menit, atau setidaknya setiap jam, dan asisten dirancang untuk penggunaan yang relatif jarang.
Kelemahan penting kedua adalah bahwa asisten tidak memberikan jawaban atas pertanyaan "dengan biaya apa disediakan?". Itu hanya memberi tahu apa yang hilang, mis. menjawab pertanyaan yang menyertainya, melewatkan yang utama.
Reservasi dan Akomodasi
Pada titik tertentu, saya memperhatikan reservasi (di gudang) dan penempatan (dalam pesanan ke pemasok dan pesanan internal). Ini dia, sepertinya, apa yang saya butuhkan! Reservasi memberikan jawaban yang jelas untuk pertanyaan utama - karena kebutuhan disediakan. Dikatakan langsung - ambil sepotong besi dari gudang ini dan pergi dengan damai, dan sepotong kayu akan tiba dalam seminggu dari pemasok dengan pesanan No. 23123.
Tetapi ilusi itu menabrak kenyataan. Pemesanan terjadi pada saat dokumen (pesanan pelanggan, misalnya), dan tempat cadangan (gudang atau pesanan ke pemasok) disimpan di dalamnya. Seseorang membuat kesalahan tiga hari yang lalu - semuanya, rantai reservasi tiga hari terbang ke neraka. Membatalkan pesanan ke pemasok dua minggu lalu - dapatkan minusnya di register cadangan. Mereka mengambilnya dari gudang tanpa cadangan, atau menghapus kekurangan - untuk memulai semuanya dari kompor.
Harapan terlintas dalam bentuk dokumen "Reservasi barang" - ini memungkinkan Anda untuk menyesuaikan semua cadangan dalam satu waktu. Lepaskan, transfer, tempati sumber daya yang lebih relevan - mis. menghilangkan semua kerugian yang dijelaskan di atas
Harapan bertahan lama, bahkan tumbuh menjadi beberapa proyek. Saya, dan mungkin Anda, melakukan hal-hal seperti itu, auto-recalculation of reserves atau workstation besar untuk mengelola cadangan, sehingga Big Dispatcher dapat mentransfer cadangan bolak-balik, menghapus dan menginstal, dengan mempertimbangkan kebutuhan dan semua perubahan dalam kehidupan nyata. Manipulasi orang ini dengan mudah masuk ke dalam dokumen "Reservasi barang", dari sudut pandang programmer, ia baik-baik saja - hampir ada catatan langsung dalam register.
Tapi di sini, tidak semuanya lancar. Masalah dengan urutan tetap di tempatnya, karena secara surut mengubah persyaratan atau dokumen cadangan juga dapat mengubah register cadangan menjadi minus. Big Dispatcher tidak bisa lagi mengandalkan data yang terus berubah. Dia baru saja mengalokasikan cadangan, semenit kemudian dia masuk ke AWP-nya, dan melihat bahwa dia telah mendistribusikan sumber daya yang tidak ada (dan dengan naif dia juga memanggil orang-orang dan menjanjikan sesuatu).
Plus, kelemahan yang sama seperti pada asisten perencanaan - redundansi, termasuk. AWP, Anda harus terus
menggunakan . Pergilah, ikuti, tekan sesuatu. The Big Dispatcher, sekali lagi, diperlukan.
Yang terburuk adalah bahwa cadangan, dengan demikian, saya tidak perlu. Saya hanya ingin tahu apa yang disediakan untuk saya, apa yang disediakan, dan apa yang saya lewatkan. Dan reservasi adalah "jangan sentuh milikku!", Yaitu. seluruh proses bisnis. Yang, apalagi, di perusahaan manufaktur, orang-orang di gudang (di mana tidak ada sistem WMS keren) suka istirahat. Dia adalah satu-satunya yang rooting untuk produksi dengan jiwanya, dan ketika dia menerima bagian yang langka, dia hanya menyembunyikannya di sudut "sehingga penjual yang terkutuk tidak akan diambil". Jenis reservasi apa yang ada di sana.
Saya, seperti Anda, mungkin, mencoba membuat sistem reservasi dan alokasi otomatis. Tampaknya tugasnya sederhana, lebih teknis, mirip dengan akuntansi batch. Penting untuk mengambil semua kumpulan cadangan dan mendistribusikan di antara mereka yang membutuhkannya. Tetapi kesulitan-kesulitan itu lahir sama seperti dalam akuntansi batch - kebutuhan untuk mengembalikan konsistensi, algoritma yang kompleks, kekritisan terhadap perubahan dalam proses bisnis dan skema akuntansi.
Tetapi saya hanya ingin mencari tahu apa yang diberikan kepada saya, apa yang disediakan, dan apa yang perlu dibeli.
Analog
Topiknya sangat usang sehingga bahkan mungkin tidak muncul di konferensi. Tahun berlalu, kereta tidak bergerak.
Di mana pun saya bekerja dengan perencanaan, saya harus mempertimbangkan analog.
Opsi termudah adalah pertukaran suku cadang yang biasa. Dalam pemesinan, misalnya, case umum persis sama dengan potongan besi, tetapi dibuat menurut versi berbeda dari dokumentasi desain. Misalnya, dari berbagai tingkatan baja. Atau satu dari penempaan, dan yang lainnya dari stamping. Atau salah satu pabrikan mereka sendiri, yang lain dibeli. Atau kekasarannya berbeda karena metode pemrosesan yang berbeda dari pemasok.
Saling dipertukarkan dari bagian-bagian tersebut dapat ditunjukkan baik di soft starter dan di ERP. Di suatu tempat, informasi ini bahkan akan diperhitungkan - misalnya, ketika memilih bahan dalam laporan produksi untuk perubahan. Dan ketika merencanakan dan menghitung keamanan, saya ingin tidak membeli bagian, analog yang sudah saya miliki dalam stok.
Dalam kehidupan nyata, menghitung analog tentu saja lebih sulit.
Sebagai contoh, pertukaran dapat tergantung pada klien - yang satu membutuhkan baja yang berbeda, yang lain membutuhkan 40X darah hidung. Satu dibuat di Cina, yang lain adalah patriot.
Tapi ini semua - kasus sederhana ketika analog dihubungkan satu-satu.
Itu terjadi lebih sulit. Misalnya, ketika membuat paket polimer, film dengan lebar yang sesuai diambil. Jika pelanggan memesan gulungan kemasan dengan lebar 1000 mm, kami mengambil lebar 1.100 mm, memotong sepanjang tepinya sebesar 50 mm (sehingga merata), dan semua orang senang. Tetapi ada situasi ketika kita tidak memiliki film 1100 lebar, dan ada 1105 mm. Tentu saja, kita tidak mandi uap dan mengambilnya - hanya akan ada sedikit lebih banyak limbah. Dan kita dapat mengambil 1.110 mm, kita dapat 1.115 mm, kita bahkan dapat mengambil 1.300 jika urutan pembakaran dan klien adalah favorit kami.
Ternyata rumus yang rumit untuk menghitung analog. Setiap film adalah nomenklatur yang terpisah, mis. kombinasi untuk setiap film akan berjumlah puluhan. Tetapi penerapan kombinasi analog tergantung pada konteks - lebar produk yang perlu kita dapatkan. Kami menambahkan di sini bahwa film dengan lebar yang sama memiliki sifat yang berbeda, tetapi dapat saling menggantikan dalam kondisi tertentu. Dan gulungan selebar 1000 mm dapat dipotong setengah untuk menyelesaikan pesanan di mana dibutuhkan lebar 450 mm. Dan itu bisa dipotong menjadi tiga bagian, dan belum tentu sama.
Singkatnya, neraka adalah neraka. Tapi saya ingin itu entah bagaimana diperhitungkan, dan jawaban untuk pertanyaan "apakah kita disediakan atau tidak?" sistem memberi.
Anda mungkin tahu skema penggantian bahan yang lebih canggih. Katakan padaku untuk tidak malu. Semua sama, tidak ada yang berencana untuk mengotomatiskan akuntansi analog kami.
Fleksibilitas
Lebih tepatnya, bukan fleksibilitas, tetapi kekurangannya. Saya, mungkin seperti Anda, telah mendengar frasa ini berkali-kali - Anda perlu beradaptasi bukan 1C untuk proses Anda, tetapi proses Anda ke 1C. Ketika dia bekerja di sebuah waralaba, dia sendiri suka mengulangi slogan ini untuk pelanggan.
Tidak ada fleksibilitas dalam perencanaan dan penghitungan keamanan di 1C. Fleksibilitas adalah ketika Anda bisa, tanpa pemrograman neraka, memilih alat yang paling cocok, sedikit tune dan dapatkan skema perencanaan yang diperlukan.
Saya sangat nyaman dengan SCP, tetapi tidak banyak yang bisa dipilih dalam keputusan perencanaan. Ini bahkan bukan fleksibilitas, tetapi Great Nothing, ruang hampa udara, lapangannya bersih. Bisakah dikatakan bahwa tidak ada yang fleksibel? Tentu saja Ini adalah pesona SCP, untuk ini saya mencintainya, terutama dalam hal perencanaan - melakukan apa yang Anda inginkan, itu tidak akan lebih buruk.
Misalnya, untuk melampirkan pengadaan soft starter sesuai dengan metode BBV (drum-buffer-rope) adalah tugas yang sederhana, bahkan oleh pemrograman biasa, tanpa alat universal di sana. Dan tidak mungkin merusak apa pun di sistem dengan modifikasinya, seperti bekerja di Great Tidak ada yang dilakukan. Ini seperti meledakkan bom nuklir setengah dari Mars ke Venus - tata surya tidak akan melihat apa-apa.
ERP sudah memiliki banyak pilihan - ada empat cara untuk memenuhi kebutuhan Anda. Tetapi ERP, seperti yang dikatakan pengembangnya pada konferensi mitra, adalah sistem berorientasi proses yang ditulis untuk proses. Ubah metode dukungan dalam ERP - untuk meledakkan bom nuklir yang sama, hanya sudah ada di Bumi. Terutama mengingat perubahan konstan dari staf editorial ke staf editorial.
Namun demikian, usaha itu bermanfaat, ada banyak untuk dipilih. Saya berbicara dengan pengembang, mengajukan pertanyaan kepada mereka tentang rasa sakit saya, menerima jawaban yang mengecewakan - rasa sakit tidak diobati dengan pil ini. Tidak ada laporan tentang keamanan, tidak ada analog, menambahkan atau mengubah metode keamanan - hanya melalui konfigurator, Anda tidak akan dapat memperhitungkan objek metadata Anda dalam skema keamanan.
Saya tidak tahu tentang Anda, tetapi dalam perbandingan ini Tidak Ada yang Hebat.
Objek metadata khusus
Benar, tidak ada yang perlu diceritakan di sini. Setiap objek metadata yang ditambahkan tidak termasuk dalam skema perencanaan atau jaminan.
Contoh objek metadata darurat, dan saya, dan Anda tahu jutaan. Jika Anda menggabungkan SCP dengan solusi industri, maka objek buatan sendiri akan muncul sendiri. Tak satu pun dari mereka akan berpartisipasi dalam perencanaan, dan konfigurator sangat diperlukan di sini.
Jika objek tidak ditambahkan secara langsung, tetapi alat peraga, misalnya, maka ke mana pun ia pergi, ia akan muncul setidaknya dalam pemilihan asisten perencanaan.
Dalam konteks objek buatan, bahkan bagus bahwa dalam 1C perencanaan seperti itu. Bayangkan jika itu seperti RAUZ - integral, teruji, bekerja, mandiri. Banyak dari kita mempertaruhkan hidup kita dengan menambahkan dokumen yang benar-benar baru untuk pergerakan barang, dan memasukkannya ke dalam semua rantai RAUZ? Atau menambahkan rincian pada nomenklatur, yang akan memengaruhi keputusan SLAU? Tetapi perencanaan tidak seperti itu - itu tidak masalah bagi Anda di mana Anda menambahkannya, itu akan berlalu begitu saja.
Ringkasan
Sebelumnya, saya sering mendengar ungkapan bahwa perencanaan adalah proses yang unik untuk setiap perusahaan, dan tidak mungkin menghasilkan solusi standar untuk semua pilihannya.
Setelah kalimat ini, saya suka perencanaan sebagai kelas tugas.
Di satu sisi, frasa menyimpan 1C (dan pengembang mana pun secara umum) dari kebutuhan untuk membuat solusi standar.
Di sisi lain, frasa ini mengilhami pengganggu - ayolah, bertindak, tidak ada hukum, aturan, keputusan benar dan salah di bidang ini! Lakukan itu!
Saya bekerja selama beberapa tahun, mungkin Anda juga. Sesuatu ternyata, sesuatu yang tidak, di suatu tempat di jalan ada perencanaan mengerikan dan sistem cadangan, laporan liar dengan pengaturan dan algoritma yang tidak dapat dibaca yang saya sendiri tidak tahu sekarang.
Dan semua itu karena ungkapan ini. Buat, buat setiap waktu, karena tidak ada solusi standar.
Kemudian baru disadari bahwa frasa itu salah, tidak terucapkan, ada sesuatu yang hilang di dalamnya.
Tidak ada solusi standar untuk
klien . Atau dengan cara lain - tidak ada solusi kotak untuk
pengguna . Tidak ada program seperti itu di dunia di mana pengguna membuat perencanaan sendiri. Ada sebuah program di mana pengguna akan melakukan akuntansi sendiri. Akuntansi akan kita semua mengetahuinya.
Tetapi mereka tidak kaya dengan implementasi tunggal, ada juga programmer 1C di sana. Pengguna - dia hanya tahu cara menekan tombol, dan itupun dia salah sepanjang waktu. Si programmer, dia menulis kode, dia tahu skema tata letak, dan skema penyimpanan data, dan melihat metadata, dan tujuan perencanaan tahu, dan prosesnya tahu ... Apakah Anda mengerti?
Tidak ada solusi standar untuk tugas perencanaan untuk pengguna, tetapi untuk programmer.
Harus ada solusi tugas perencanaan yang khas untuk programmer . Alat
- memiliki tingkat abstraksi tertentu (tetapi tidak sebagai konfigurator, tentu saja);
- memecahkan algoritma dasar tugas perencanaan agar tidak khawatir tentang mereka di setiap implementasi;
- mampu menggunakan semua data sistem yang diperlukan untuk keperluan perencanaan;
- yang untuk setup tidak memerlukan pemrograman, tetapi juga tidak masuk ke dalam vulgar enikey.
Secara umum, Anda memerlukan alat yang dibuat oleh programmer untuk programmer.
Analogi jelas terdekat adalah
Konversi Data . Bukan alat yang sangat sederhana, tetapi bukan alat yang rumit yang memecahkan area tugas yang spesifik dan dapat dipahami - pertukaran data - dan berisi semua fungsi yang diperlukan untuk penyelesaian masalah yang berhasil.
Konversi hampir sepenuhnya memenuhi kriteria yang saya sajikan ke sistem perencanaan:
- memiliki tingkat abstraksi tertentu (tidak tahu apa-apa tentang metadata, tahu cara bekerja dengan platform yang berbeda, tahu cara mentransfer semua atau sebagian, dll);
- memecahkan algoritma dasar masalah transfer data sehingga tidak perlu khawatir tentang mereka pada setiap implementasi;
- mampu menggunakan semua data sistem yang diperlukan untuk keperluan transfer;
- itu tidak memerlukan pemrograman * untuk mengkonfigurasi, tetapi juga tidak masuk ke vulgar.
* - Itu tidak benar di sini, pemrograman dalam konversi biasanya diperlukan. Tetapi ada banyak contoh ketika itu tidak perlu.
Dari sudut pandang saya, dan dalam konteks artikel, Konversi Data adalah contoh yang hampir sempurna dari solusi khas untuk seorang programmer. Konversi bahkan tidak mencoba untuk berpura-pura bahwa itu untuk pengguna, jadi dia tidak harus membawa kegunaan, pendekatan proses, pengaturan yang mudah, memerlukan organisasi data khusus dan solusi pemberat lainnya untuk pengguna.
Lain yang layak disebut adalah
Penganggaran dalam SCP . Ini adalah sistem yang memungkinkan Anda mengumpulkan data dari sistem menggunakan kueri, dan menyusun perencanaan anggaran darinya. Biasanya tidak berfungsi langsung, tetapi jika Anda menempatkan programer di belakang pengaturan, Anda bisa mendapatkan hasil positif dengan cukup cepat.
Saya akan menindaklanjuti dengan alat yang menurut saya pribadi benar -
Monitor ERP . Tujuan dari alat ini adalah beragam, tetapi pada saat yang sama sangat sederhana - untuk memberikan informasi tentang bisnis dengan cara yang benar. Hal utama - di monitor ERP Anda dapat menulis diagram tata letak, menentukan indikator Anda sendiri, aturan untuk perhitungan dan kontrol mereka. Tentu saja, pengguna tidak akan melakukan ini, meskipun upaya telah dilakukan untuk membuat antarmuka konfigurasi untuk pengguna - ada indikator, strategi, tujuan yang telah ditentukan. Tanam programmer dengan pernyataan masalah yang benar - ia akan menciptakan sistem pengendalian cerdas untuk perusahaan.
Sekarang, pada kenyataannya,
pertanyaan utama : di mana alat untuk mengatur perencanaan dan menghitung keamanan, serupa dalam fleksibilitas dan kemampuannya untuk konversi data, penganggaran, dan monitor ERP?
Konfigurasi 1C yang khas - mereka, seperti, untuk "akuntansi dan manajemen". Dasar manajemen adalah perencanaan dan pengendalian. Pengendalian, setidaknya, dapat dibangun. Untuk membangun perencanaan yang benar dan modern, yang mampu dengan cepat menanggapi perubahan lingkungan, dengan mempertimbangkan kekhasan pendekatan akuntansi Rusia, hampir tidak mungkin.
Itu sebabnya gulungan dalam frasa "akuntansi dan manajemen" pada kata pertama. Dan saya ingin keseimbangan, satu hal mengikuti dari yang lain.
Semua hal di atas adalah pendapat pribadi penulis, tentunya.
NB Nah, saya akan bertanya pada diri sendiri, ini sangat menarik, mungkin Anda tahu - dan siapa yang mengambil keputusan, bagaimana membuat alat yang tepat dalam soft starter atau ERP, dan yang salah? Mengapa penganggaran benar dan perencanaan salah.