Menerapkan ERP di perusahaan industri: Alevtina Svetozarovna dan Excel terhadap arsitek keras dan pabrik Inggris

Menerapkan sistem ERP itu menyakitkan. Ini adalah jodoh, air mata, jeritan, terkadang ancaman pembalasan fisik (sayangnya, ini juga terjadi dalam latihan kami). Tapi ini normal - perubahan serius menyebabkan banyak emosi dan mempengaruhi karier orang, dan menerapkan ERP di perusahaan Rusia untuk perubahan kecil adalah buang-buang uang.

Kesulitan bisa berbeda, dan mereka muncul pada berbagai tahap proyek. Saya ingin berbagi pengalaman kami dalam menyelesaikan masalah selama operasi percobaan, ketika semua proses bisnis dalam sistem baru sudah dijelaskan, perannya dikonfigurasi, modifikasi dibuat, instruksi dikeluarkan dan Anda hanya perlu mulai bekerja. Untuk setiap masalah, saya akan menjelaskan penyebabnya dan memberikan 1 atau 2 kasus - contoh pemecahan masalah tersebut dari pengalaman kami.

Pada tahap operasi percobaan, sangat penting untuk merumuskan rencana kerja yang dapat dikerjakan untuk masing-masing proses bisnis, menunjukkan tanggal dan kontraktor, memilih daftar objek yang relatif kecil yang sedang diuji dan membuat penyesuaian pada sistem, dan menetapkan prosedur kontrol. Kuncinya di sini adalah kelayakan. Banyak kesulitan menunggu Anda bahkan tanpa ini, tidak perlu semakin memperburuk situasi dengan rencana mustahil.

Kami melakukan semua ini pada proyek kami.

Masalah nomor 1. Rencana kerja tidak sepenuhnya dilaksanakan

Dari pengalaman, paling sering bahkan rencana yang telah disepakati dan layak ini tetap tidak terpenuhi. Alasan utama yang disuarakan oleh para pemain adalah kurangnya waktu. Meskipun daftar lengkap alasannya sedikit lebih banyak:

• Prinsip: “Yang utama adalah menghasilkan produk, dan yang lainnya akan menunggu.”
• Momen psikologis: pemain jauh lebih mudah melakukan rutinitas biasa daripada sesuatu yang baru.
• Penolakan terhadap ideologi sistem oleh pelaku: “Sistem Anda tidak akan berfungsi. Kami memiliki Alevtina Svetozarovna - wanita paling cerdas, berusia 60 tahun di pabrik, mengingat semuanya, tidak ada sistem yang memperhitungkan semua yang ia ingat. "
• Alasan obyektif:
  
  • literasi komputer yang rendah dari karyawan pelanggan.
  • Sebagai aturan, selama otomatisasi, kompleksitas entri data tumbuh - akuntansi menjadi lebih rinci, lebih banyak informasi diperlukan untuk dimasukkan ke dalam sistem, dan ini membutuhkan lebih banyak waktu.

Saya sengaja mengecualikan dari daftar barang-barang seperti sabotase dan kekurangan nyata pekerja - ini tidak terjadi sesering yang orang mungkin pikirkan.

Apa yang harus dilakukan dalam kasus seperti itu?

Seperangkat tindakan untuk memecahkan masalah No. 1:

• Meningkatkan prioritas sistem . Pelaku perlu terus menyuarakan betapa pentingnya implementasi sistem ERP untuk perusahaan. Selain itu, tidak hanya untuk terus-menerus "menetes ke otak" tentang hal ini (yang, kebetulan, harus dilakukan tanpa gagal), tetapi juga menjelaskan secara logis mengapa ini perlu: bahwa Alevtina Svetozarovna sudah berusia 85 tahun, ia menginginkan pensiun yang sudah lama layak, yang tanpa Sistem ERP untuk menetapkan akuntansi dan perencanaan normal tidak berfungsi, dan ini pada akhirnya menyebabkan kebangkrutan dan PHK, dll. Mungkin ada banyak argumen, tetapi hasil utama yang diharapkan dari tindakan ini - implementasi sistem harus menerima setidaknya prioritas yang sama dengan pekerjaan saat ini.
• Perubahan budaya perusahaan . Ada 2 fungsi manajemen - ini adalah pemeliharaan dan peningkatan. Yang pertama diperlukan untuk memastikan kepatuhan dengan standar teknologi, manajerial dan organisasi saat ini. Dan peningkatan adalah langkah-langkah yang bertujuan untuk meningkatkan standar kerja yang ada. Menurut Kaizen, perusahaan terburuk adalah mereka yang hanya fokus pada fungsi pertama. Mereka akan menghadapi keruntuhan sebagai akibat dari kompetisi atau perubahan kondisi pasar. Ketika diterapkan pada perusahaan industri, ini berarti bahwa sudah dari tingkat manajer toko, manajemen harus lebih memperhatikan peningkatan, daripada “rutin”. Artinya, perlu untuk menyampaikan kepada manajemen perusahaan kebutuhan untuk beralih dari gambar seperti itu:

untuk yang ini:

• Kontrol dan tekanan konstan pada pemain dari atas . Semuanya sederhana di sini: tidak ada kontrol - tidak ada pekerjaan. Penting untuk mengatur prosedur ini, untuk menggambarkan apa yang tepat dan dengan frekuensi apa yang akan diukur. Kontrol bukan dialog seperti ini:

"Nah, Ivanitch, apakah Anda bekerja di sistem yang baru?" - "Kami bekerja diam-diam" - "Bagus, bagus sekali. Anda akan mencoba di sana, sang jenderal bertanya kepada saya, "

seharusnya seperti ini:

“Ivan Ivanovich, kemarin komisi memeriksa bengkel Anda, hanya 5 bets bagian dari 300 bets yang ada di bengkel Anda yang disertai dokumen yang dicetak dari sistem ERP di dekatnya. Ini hanya 1,7% daripada 95% yang harus Anda berikan. Minggu depan akan ada pemeriksaan ulang, jika hasilnya sama, Anda tidak akan melihat bonus triwulanan. "

• Bukan untuk berteori, tapi untuk memilah pekerjaan tertentu . Anda tidak dapat menerapkan sistem ERP saat duduk di kantor Anda. Jika seorang karyawan mengatakan bahwa dia tidak punya waktu untuk bekerja dalam sistem, Anda harus pergi ke tempat kerjanya dan melihat bagaimana dia bekerja. Mungkin dia hanya menggunakan instruksi yang salah atau monitornya terlalu kecil.
• Untuk mendidik, mendidik, dan mendidik lagi . Anda harus yakin bahwa semua pemain dilatih untuk bekerja dengan komputer dan bekerja dengan sistem, bahwa setiap orang memiliki instruksi dan hak yang sesuai.
• Kelanjutan pekerjaan pada pengoptimalan stasiun kerja berkinerja . Semakin banyak orang bekerja dengan sistem, semakin banyak umpan balik berharga yang mereka berikan. Ketika Anda mendapatkan umpan balik yang berarti ini, Anda dapat mengoptimalkan pekerjaan untuk mengurangi waktu yang diperlukan untuk memasukkan informasi. Tapi itu layak dilakukan hanya setelah orang aktif bekerja dengan sistem selama setidaknya satu bulan.

Kasus 1. Jangan berteori, tetapi pergi ke pekerjaan

Masalah : Salah satu pelanggan kami. Pada tahap peluncuran sistem, ada kesulitan dengan pemilik toko, yang mengeluh bahwa dia tidak punya waktu untuk mendaftarkan pergerakan inventaris dalam sistem. Workstation pemilik toko lebih dioptimalkan, kami membuatnya perlu untuk memasukkan informasi minimum. Tidak ada yang membantu.

Bagaimana masalah itu diselesaikan : kepala akuntan perusahaan datang ke penjaga toko ke gudang dan mengukur dengan stopwatch berapa banyak waktu yang dihabiskannya untuk bekerja. Ternyata 80% dari waktu dihabiskan mengisi kartu kertas untuk barang dan bahan. Kepala akuntan memiliki wewenang yang cukup untuk mengoptimalkan proses, para pemilik toko berhenti menuntut kartu kertas, dan masalah kurangnya waktu menghilang.

Masalah nomor 2. Keinginan untuk melakukan semuanya sekaligus

Item ini memiliki kesamaan dengan masalah No. 1. Jika rencana yang layak dibentuk, disetujui dan disetujui, maka hanya ada satu cara - itu harus dipenuhi . Tetapi seringkali, sebagai gantinya, orang-orang membuat perubahan, menambahkan pekerjaan baru, dan kemudian mereka tidak bisa mengatasi apa yang terjadi. Berikut ini beberapa contoh dari pengalaman kami:

• rencana operasi uji coba termasuk peluncuran hanya satu jenis produk dalam sistem ERP, dan kemudian memutuskan bahwa itu entah bagaimana tidak serius, dan menambahkan beberapa produk jadi lainnya. Akibatnya, tidak ada satu pun produk yang dibuat sampai akhir pekerjaan.
• dalam hal operasi uji coba, hanya satu bengkel yang diletakkan, tetapi "ini bukan skala kami, mari biarkan beberapa bengkel bekerja dalam sistem". Akibatnya, manajemen gagal menyediakan waktu yang cukup untuk memantau semua lokakarya, dan tidak satu pun dari mereka yang dapat menghasilkan uang secara normal.
• berencana untuk meluncurkan akuntansi dalam satu sistem ERP untuk satu gudang, dan kemudian meningkatkan jumlah gudang. Akibatnya, proses tersebut tidak sepenuhnya diluncurkan di salah satu gudang.

Penyebab masalah ini adalah:

• Cinta akan tantangan. Orang-orang kami tidak tertarik melakukan apa yang tampak sederhana, mereka menginginkan tantangan dan cobaan.
• Meremehkan kompleksitas tugas / penilaian kembali kekuatan sendiri. Manajer tidak selalu membayangkan berapa banyak pekerjaan yang dapat dilakukan oleh karyawan departemen mereka. Kadang-kadang orang terbiasa berjanji lebih banyak pada rapat daripada yang bisa mereka lakukan, dengan harapan bahwa mereka akan lupa untuk menanyakan hasil pada pertemuan berikutnya.
• Diprioritaskan dengan tidak tepat. Misalnya, perlu untuk berurusan dengan kesalahan dalam data normatif dan referensi, yang tanpanya tidak mungkin untuk memulai pada prinsipnya, dan pelanggan dengan keras kepala tidak mau berurusan dengan masalah nyata ini dan membombardir kita dengan melaporkan masalah untuk layanan ekonomi - pelaporan yang diperlukan jauh kemudian dan hanya jika itu benar " peraturan ".
• Takut akan kepemimpinan. Ini terjadi ketika manajer proyek di pihak pelanggan adalah direktur umum atau pemilik, yang tidak hanya tidak berpartisipasi, tetapi juga tidak secara khusus mempelajari proses implementasi. Pada saat yang sama, ia muncul pada titik kontrol tertentu dan memberikan kata perpisahan yang signifikan: “Tidak perlu mengatur taman kanak-kanak di sini! Bagaimana menjalankannya hanya dalam satu bengkel? Mengapa Anda membutuhkan 2 bulan untuk operasi percobaan? Saya memberi Anda 3 minggu untuk diluncurkan secara penuh, Anda harus memenuhi tenggat waktu ini atau Anda tahu apa yang akan saya lakukan dengan Anda. " Dan jika manajer proyek tidak memiliki keberanian untuk menjawab: "Tidak ada mukjizat, 9 wanita dalam sebulan tidak melahirkan 1 anak," maka ia kemudian menyiarkan "instruksi berharga" ini dan "tanggal yang layak" kepada para pemain. Semua orang mengerti bahwa rencana itu tidak layak, tetapi mereka akan menciptakan penampilan kerja sehingga tidak ada alasan formal untuk menemukan kesalahan pada mereka - pada saat yang sama, waktu yang berharga terbuang untuk dipajang, yang dapat digunakan untuk bisnis.

Apa yang bisa dilakukan dengan ini?

Seperangkat tindakan untuk memecahkan masalah No. 2:

• Beranjak dari yang sederhana ke rumit : menyetujui rencana kerja yang bisa dikerjakan, selesai, pindah ke rencana dengan lebih serius. Dengan setiap langkah, akan menjadi jelas berapa banyak pekerjaan yang benar-benar mungkin dilakukan dengan sumber daya saat ini, ini akan memungkinkan kita untuk merencanakan lebih akurat. Selain itu, hanya dengan cara ini dimungkinkan untuk menilai sejauh mana masalah itu terjadi, yang akan memungkinkan untuk membuat keputusan manajerial yang bermakna, dan tidak menyembunyikan kepala seseorang di pasir.
• Kemampuan menyederhanakan . Sangat penting untuk dapat, jika perlu, untuk sementara waktu mengabaikan persyaratan untuk menyelesaikan tugas secara keseluruhan: sering melakukan tiga poin lebih baik daripada tidak melakukan sama sekali.

Selain itu, kita tidak berbicara tentang cara melakukan nilai C dan tenang. Biasanya, semuanya terjadi seperti ini: mereka mendapatkan nilai C, perlahan setelah beberapa saat mereka mencapai empat, dan kemudian setelah 3-4 tahun, ketika sistem menjadi sudah asli, mereka baik mencapai lima padat, atau mereka mengerti bahwa keempat sudah optimal dalam hal rasio upaya dan hasil yang dihasilkan adalah opsi.

• Konsentrasi pada tugas-tugas penting . Pertama-tama, perlu untuk melakukan tugas-tugas yang diperlukan sekarang untuk memulai sistem, dan bukan apa yang menyebabkan lebih banyak suara.

Yang terpenting adalah, pertama-tama, tugas yang memungkinkan membebaskan manajer dari tindakan rutin.

Kasus 2. Kemampuan untuk menyederhanakan

Masalah : Salah satu pelanggan kami. Peluncuran sistem ERP melambat karena fakta bahwa pelanggan percaya bahwa operasi normal sistem membutuhkan pembentukan berbagai rute operasional. Para teknolog mengatakan bahwa mereka akan membutuhkan 5 tahun kerja untuk membuat rute operasional yang diperlukan.

Bagaimana masalah itu diselesaikan : pelanggan mengakui bahwa dengan pendekatan seperti itu ia tidak akan pernah memulai. Setelah itu, data dari razsehovok diambil sebagai dasar otomatisasi dan menerapkan akuntansi untuk pergerakan antar bengkel suku cadang dan unit perakitan. Ini cukup untuk perencanaan dan akuntansi penuh. Sekarang kita secara bertahap bergerak dari razsehovok ke rute operasional dengan sistem ERP yang sudah berfungsi.

Kasus 3. Fokus pada yang penting

Masalah : Juga salah satu pelanggan kami. Sejumlah besar informasi referensi yang ditransfer dari sistem samopisnaya lama, pelanggan memahami bahwa ada banyak kesalahan. Sebagian besar pertanyaan terkait dengan kebenaran rute. Dalam cara yang baik, semuanya perlu diperiksa dan disesuaikan, tetapi ini adalah sejumlah besar informasi, dan teknologi dan desainer sudah dimuat. Selain itu, muncul pertanyaan: bagaimana cara memverifikasi bahwa semuanya sudah diperbaiki dengan benar jika tidak ada yang bekerja dalam sistem?

Bagaimana masalah itu diselesaikan : pelanggan mengakui bahwa dia tidak membutuhkan "normatif" secara penuh. Diputuskan bahwa hanya posisi yang sedang diproduksi yang akan disesuaikan: setiap kali bagian memasuki Departemen Kontrol Kualitas, pengontrol membandingkan rute dan peta rute dari sistem. Jika ada perbedaan, maka bagian tersebut tidak ditransfer lebih lanjut, dalam waktu 15 menit teknolog tiba dan melakukan penyesuaian pada sistem. Ada 2 poin kunci yang memungkinkan untuk berhasil:

• berkonsentrasi pada produk yang sedang diproduksi;
• menjadikan pekerjaan memperbaiki rute dalam sistem sebagai prioritas.

Masalah nomor 3. Pelaku tidak memiliki pemahaman bahwa kegiatan unit lain bergantung pada pekerjaan mereka

Ketika mengerjakan desain fungsional, analisis mendalam dari proses bisnis dilakukan, semua peran dan fungsi, input dan output, dan hubungan antar departemen ditentukan dengan jelas.

Namun seringkali para pelaku tidak mengerti bagaimana hasil dari pekerjaan mereka akan mempengaruhi sisanya. Contoh:

• dalam bahan dokumentasi desain dan teknologi dan pembelian ditunjukkan tanpa mempertimbangkan apakah mereka pada dasarnya dapat ditemukan di pasar.

Mungkin ada keberatan dari seri ini: “Mengapa desainer atau teknolog berpikir tentang apa yang ada di pasaran? Ada persediaan untuk ini. " Saya percaya bahwa akan adil jika kepemimpinan pada awalnya mengatakan kepada desainer dan teknolog: "Anda adalah pencipta, jadi jangan membatasi diri Anda dalam memilih warna untuk lukisan indah Anda," dan departemen pasokan diberitahu: "Segala sesuatu yang akan diminta oleh orang-orang ini harus dikirimkan tepat waktu. Jangan menyisihkan uang, mengambilnya bahkan dari Kutub Utara, tetapi kreativitas tidak boleh berhenti. " Sayangnya, bahkan setelah menyuarakan bagian pertama, mereka melupakan bagian kedua - persediaan harus selalu dibeli semurah mungkin dan tidak melebihi anggaran.

• saat membeli, karena sedikit perbedaan dalam nama barang, mereka dimasukkan di bawah kode yang berbeda. Semuanya baik-baik saja dengan persediaan - nomenklaturnya dikapitalisasi, bahkan jika posisi yang sama duduk di bawah artikel yang berbeda. Tetapi para perencana “tenggelam” dalam pergantian pemain, semua perencanaan gagal.

Penyebab masalah ini adalah:

• Pelaku tidak tahu keseluruhan proses, tidak menyadari interkoneksi antar departemen.
• Seniman mengerti bagaimana prosesnya bekerja, tetapi sangat sibuk sehingga mereka tidak mampu memikirkan sisanya.
• Proses ini membutuhkan peningkatan: misalnya, seorang karyawan dapat berubah menjadi “tautan tambahan” dalam rantai - ia mengambil informasi dari satu unit, memasuki sistem, dan kemudian unit lain menggunakannya. Sulit untuk berharap bahwa seseorang dalam kondisi seperti itu entah bagaimana akan memverifikasi informasi dan menjaga kebenarannya.

Dengan tidak adanya otomatisasi atau otomatisasi lokal dalam departemen yang sama, masalah dengan interaksi unit tampaknya tidak muncul, mereka tidak terlihat. Dan ERP adalah produk terintegrasi yang tidak akan membiarkan untuk mengabaikan ketidakkonsistenan dan ketidaksempurnaan proses.

Seperangkat tindakan untuk memecahkan masalah No. 3:

• Pelatihan pengguna berkelanjutan . Dianjurkan setelah menyelesaikan pelatihan dengan menandatangani dokumen bahwa dia sekarang memikul tanggung jawab penuh untuk semua yang dia lakukan dalam sistem. Dokumen ini mungkin tidak memiliki kekuatan hukum, tetapi akan memiliki efek psikologis.
• Pertemuan Secara berkala mengadakan pertemuan dengan beberapa departemen untuk membahas situasi di mana satu departemen menderita dari tindakan yang lain.
• Kegiatan pendidikan . Dalam situasi tertentu, undang pelaku untuk mengoreksi hasil kesalahan mereka sendiri.
• Optimalisasi proses . Hindari "tautan ekstra", tutup kemungkinan kesalahan sebanyak mungkin.

Di sini, pada prinsipnya, tidak ada item yang ditambahkan untuk mengurangi beban pada pemain, sehingga mereka punya waktu untuk berpikir tentang bagaimana pekerjaan mereka mempengaruhi sisa departemen. Sementara karyawan tersebut percaya bahwa sejumlah besar pekerjaan adalah alasan untuk pekerjaan berkualitas rendah dan menyabot kegiatan rekan-rekannya, ia akan dibebani dengan perbaikan jambs-nya sendiri.

Kasus 4. Pabrik Inggris

Pabrik adalah bahasa Inggris, oleh karena itu, tidak ada bagian "Masalah" dan "Bagaimana masalah itu diselesaikan" dalam kasus ini, itu dimasukkan dalam artikel ini bukan sebagai contoh.

Pada suatu waktu, kolega saya berkenalan dengan satu sistem ERP di sebuah pabrik Inggris, di mana mereka membuat peralatan untuk penerbangan. Mereka kagum bahwa setiap karyawan yang mereka dekati dan bertanya apa pekerjaannya terdiri, mencoba untuk berbicara tentang bagaimana proses secara keseluruhan diatur, dan bukan hanya tentang bagiannya. Artinya, masing-masing pemain memahami keseluruhan proses dan pengaruhnya terhadap keseluruhan pekerjaan.

Saya tidak dapat dengan tegas mengatakan bahwa fakta ini berkorelasi dengan yang pertama, tetapi pabrik itu memiliki lebih sedikit karyawan daripada yang serupa di Rusia, dan mereka menghasilkan jumlah yang sama.

Masalah nomor 4. "Mengapa kamu tidak memberi tahu kami tentang ini?"

Pada tahap desain, setiap proses ditunjukkan. Ini menjelaskan berbagai mode operasi sistem dan fitur-fitur penting yang dapat digunakan di masa depan.

Tetapi ini tidak cukup. Pada banyak proyek, ketika memulai operasi uji coba, muncul pertanyaan:

• "Mengapa kamu tidak memberi tahu kami tentang ini sebelumnya?"
• "Mengapa mode operasi ini tidak dijelaskan dalam instruksi?"

Penyebab masalah ini adalah:

• Sebelum Anda memahami beberapa fitur yang Anda butuhkan untuk tumbuh, masuk akal untuk membahasnya hanya setelah mereka "terjebak" dalam praktik. Dari pengalaman saya sendiri, saya dapat mengatakan bahwa bahkan ketika saya memberi tahu klien sebanyak mungkin tentang semua fungsi yang setidaknya secara teoritis mungkin diperlukan pada proyek, di masa depan semua sama, pertanyaan serupa muncul - orang mendengarkan, tetapi menyaring apa yang mereka pikir tidak terlalu kuat pada waktu itu. cocok.
• Bahkan jika TK ditulis dengan baik, terkadang persyaratan tambahan muncul. Beberapa mode pengoperasian pada awalnya tidak dimaksudkan untuk digunakan pada awalnya, oleh karena itu mereka tidak diberitahu tentang mereka.
• Sistem ERP modern sangat berlebihan dalam fungsi (setidaknya sehingga memungkinkan untuk mengotomatiskan kegiatan perusahaan mana pun), oleh karena itu akan selalu ada fungsi-fungsi yang tidak diceritakan oleh integrator kepada klien.

Seperangkat tindakan untuk memecahkan masalah No. 4:

• Penerimaan Anda hanya perlu menerima fitur ini dan menangani masalah saat mereka muncul.

Kasus 5. "Saya mengerti tipuan Anda"

Setelah keberhasilan implementasi sistem ERP, seorang karyawan kunci dari pelanggan sambil minum teh memberi tahu kami:

"Aku mengerti tipuanmu. Anda memberi kami informasi dalam dosis tertutup sehingga kami tidak takut. Jika kami telah mewakili seluruh ruang lingkup pekerjaan sejak awal, kami akan meninggalkan proyek. Jadi - tanpa mengangkat kepala, terus-menerus menyelesaikan masalah, mereka menyelinap masuk dan mendapatkan sistem kerja. "

Masalah nomor 5. "Dua yang kami tulis, tiga dalam pikiran"

Ketika mengerjakan desain fungsional, analisis mendalam dari proses bisnis dilakukan, semua peran dan fungsi, input dan output, dan hubungan antar departemen ditentukan dengan jelas.

Dan kemudian pada tahap operasi uji coba "rincian" muncul, ketika menurut semua peraturan, pekerjaan dilakukan dalam satu cara, tetapi pada kenyataannya - berbeda. Semua orang tahu tentang ini, tetapi untuk saat ini mereka tidak mengatakan "orang asing":

• Menurut teknologi, bagian diproses di bengkel No. 1, tetapi semua orang tahu bahwa mesin dipindahkan ke bengkel No. 21 sejak lama dan pesta sedang diangkut di sana. Tidak ada waktu untuk mengubah teknologi, dan mengapa, jika semua orang sudah tahu segalanya?

“Dan sekarang cari tahu bagaimana merefleksikan ini dalam sistem ERP, sehingga Anda tidak membuat rute baru, dan tidak membuat perubahan apa pun pada yang sekarang, dan semuanya akan belajar dengan benar! Tidak bisa Jadi sistem Anda tidak memahami fitur kami dan tidak cocok untuk kami! "

• Bagian yang masuk ke produk jadi dicat sebagai bagian dari produk setelah perakitan, dan jika bagian tersebut digunakan sebagai suku cadang untuk dijual, maka itu dicat secara terpisah. "Dan mengapa dalam dokumen Anda konsumsi cat dan operasi yang sesuai tidak ditunjukkan di mana pun?" "Aku tidak tahu. Namun demikian, sudah disadari bahwa suku cadang untuk dijual dicat. ”

Alasan untuk ini:

• Kemalasan pemain.
• Kurangnya disiplin kerja.

№5:

• . . . Di mana-mana. Selalu.

, . . . Di mana-mana. Selalu.

№6. « - »

-. , : « , – ».

« »:

• « , ERP ? !»
• « , . , , , , . , . , , , , 60 ».

:

• .
• , , , ERP-, . . , , « ». ERP- – , , .

№6:

• . , .
• . , .
• KPI . , 100%, .
• , . , , . , , .

6. « »

: , (3-4 ) , «» . «» – , . – , , . (- , , ), .

, . . – , , , : , , , /, . .

Itu saja. ERP, , . . . . Di mana-mana. …