Memodelkan proses bisnis sebagai bagian dari proyek implementasi sistem ERP

Sebelum memulai proyek lain untuk menerapkan sistem informasi yang mencakup sebagian besar area fungsi perusahaan, saya memutuskan untuk menulis serangkaian artikel dengan pemikiran saya tentang kebenaran fakta bahwa perusahaan industri besar, terutama yang telah beroperasi selama beberapa dekade, memiliki lebih dari setengah proyek ERP “ mereka tidak lepas landas. " Saya akan menulis artikel ini lebih banyak untuk diri saya sendiri sebagai "sclerosis" untuk membentuk percakapan dengan manajer puncak perusahaan dan menyusun pertimbangan-pertimbangan yang saya buat berdasarkan pengalaman saya.

Artikel-artikel ini tidak dimaksudkan untuk memberi tahu dunia betapa kerennya saya atau bagaimana saya tahu cara menerapkan proyek-proyek semacam itu. Jika Anda mengatakan bahwa ini adalah "artikel lain dari seorang pecundang yang, yah, mengerti semuanya dengan tidak benar," ini akan menjadi nilai bagi saya juga, karena saya mengharapkan seseorang untuk berbagi pemikiran mereka dalam komentar.

Ada banyak masalah dalam implementasi sistem tersebut. Jika Anda dengan benar membuat daftar periksa risiko proyek implementasi sistem ERP, maka akan diperlukan lebih dari seratus baris dan kemungkinan besar akan berubah menjadi justifikasi yang cukup kuat mengapa penerapan sistem ERP tidak pernah dapat dimulai dalam kehidupan. Namun demikian, ada proyek yang sukses, kebutuhan untuk pengenalan sistem seperti itu juga berulang kali dikonfirmasi, yang berarti bahwa pengenalan sistem semacam itu bukanlah tugas yang mustahil.

Bagi saya sendiri, saya membagi semua masalah yang menghambat keberhasilan implementasi proyek ke dalam tiga kategori:

  1. Politik, disebabkan oleh ketidakcocokan tujuan proyek yang dinyatakan dengan harapan internal peserta proyek
  2. Fungsional, disebabkan oleh kurangnya kompetensi peserta proyek
  3. Teknologi, yang disebabkan oleh terlalu rendahnya sumber daya yang dibutuhkan, waktu

Ini agak besar dan kondisional, tetapi itu membantu saya secara pribadi ketika memberi peringkat risiko untuk membentuk penilaian terhadap kemungkinan keberhasilan implementasi sistem.

Saya tidak punya pengalaman dalam menerapkan sistem produksi besar menggunakan Agile atau metodologi lain selain "air terjun" standar, yang mencakup langkah-langkah utama berikut:

  1. Sebuah survei perusahaan, deskripsi proses bisnis "apa adanya", "sebagaimana mestinya."
  2. Membuat model sistem informasi.
  3. Pengembangan dan implementasi TK.
  4. Uji operasi.
  5. Operasi percontohan.

Oleh karena itu, uraian tugas dan risiko yang ingin saya struktur di kepala saya terhubung dengan metodologi air terjun dan mungkin tidak sepenuhnya dapat diterapkan pada teknologi untuk mencapai hasil yang cepat.

Mungkin akan lebih bijaksana untuk memulai dengan uraian tugas yang harus diselesaikan sebelum proyek diluncurkan, seperti mengidentifikasi pelanggan fungsional, mengumpulkan tim proyek, membentuk dan mengevaluasi kriteria keberhasilan proyek.

Namun sejauh ini saya belum menyusun pertimbangan ini dan menempatkannya di kotak yang terpisah.
Oleh karena itu, untuk membaca artikel berikut ini kita akan menganggapnya “sudah sepantasnya”: kebutuhan untuk implementasi adalah tetap, pelanggan fungsional ditemukan dan terbakar dengan proyek, anggaran ditemukan, tim proyek dikumpulkan dengan benar, sumber daya untuk implementasi diidentifikasi.

Pada artikel pertama, saya ingin memperbaiki tugas dan risiko proyek pemodelan proses bisnis. Ini jauh dari masalah paling kritis yang tersedia pada tahap awal proyek, tetapi karena tahap inspeksi perusahaan dimulai dengan pemodelan proses bisnis "sebagaimana adanya" dan "sebagaimana mestinya," saya memutuskan untuk memulai dengan itu.

Jadi, saya akan mulai.

Sulit membayangkan bahwa salah satu pemilik atau manajer puncak perusahaan industri besar memperoleh sistem ERP demi mode. Dengan satu atau lain cara, jika Anda mulai berbicara tentang memperoleh sistem, maka manajemen puncak tidak puas dengan analis yang ada untuk membuat keputusan, proses bisnis yang ada, kecepatan dan kualitas perubahan di dalamnya (kami tidak memperhitungkan akuisisi sistem ERP untuk pencucian uang atau politik, tujuan gambar).

Proses bisnis selalu ada dalam suatu perusahaan dan tidak masalah apakah itu didokumentasikan atau tidak. Selain itu, di perusahaan industri besar, ada kemungkinan bahwa proses bisnis yang sebenarnya sebagian besar atau tidak sepenuhnya bertepatan dengan proses bisnis yang terdokumentasi. Dengan satu atau lain cara, permintaan pengiriman masih sampai ke gudang, ekonom masih menghitung kebutuhan produksi, dan master masih menghasilkan tugas shift-harian dalam beberapa sistem, menggunakan pensil pada kartu punch atau "edrena materi" verbal.

Pertanyaan lain adalah bahwa proses bisnis yang mapan ini tidak optimal, berlebihan, dan kadang-kadang juga tidak memiliki nilai untuk bisnis dan peserta dalam proses bisnis. Sebagai contoh, ini adalah pembentukan beberapa jenis pelaporan manajemen, yang semua orang sudah lupa tentang tujuan, yang analisisnya tidak ada yang terlibat dan kebutuhan untuk membuat pelaporan ini diperdebatkan pada tingkat “Maria Ivanovna selalu meminta untuk melakukan ini, tetapi mengapa, Tuhan tahu, tanyakan padanya dia. "

Tentu saja, tidak ada yang mau menyeret proses bisnis yang tidak optimal ini ke dalam sistem ERP. Secara teori, pada tahap desain sistem, manajemen puncak menyatakan tujuan untuk mengoptimalkan proses bisnis dan regulasi mereka. Dan bahkan berlangganan tesis "memaksimalkan model proses bisnis perusahaan yang ada di bawah fungsi khas dari sistem yang diterapkan."

Dalam praktiknya, semuanya terlihat jauh lebih menyedihkan. Pelaku biasa tidak siap untuk mengubah proses bisnis, bahkan yang paling dasar. Mungkin ini secara pribadi adalah praktik gagal saya bekerja di prom. perusahaan, mungkin ini adalah tren nyata, tetapi jangan berharap bahwa ungkapan "sekarang Anda tidak perlu melakukan pesanan pengeluaran untuk persetujuan dengan berjalan kaki selama 3 kilometer, tetapi dapat dilakukan secara otomatis dalam sistem dalam 3 detik", Anda akan menerima kegembiraan sebagai tanggapan. Seorang pemain biasa, yang pekerjaannya terdiri dari 60% dari waktu berjalan dengan dokumen, segera memutuskan bahwa ia akan dipotong, ia akan diberi pekerjaan di mana ia tidak berpikir atau akan mengurangi gajinya. Logika dalam pertimbangannya tidak selalu ada, tetapi karyawan biasa dapat memberikan perlawanan terhadap perubahan dengan cukup jelas. Selain itu, seperti pada tahap mengumpulkan persyaratan untuk sistem,ketika dia akan membuktikan nilai berlarian dengan selembar kertas ("Dan MikhalKuzmich dari departemen anggaran organisasi kepala mengatakan bahwa mereka hanya menerima pemindaian dokumen dengan semua tanda tangan dari kami"), dan selama pengoperasian sistem, ketika ia hanya mencetak pesanan dari sistem yang lama dan memakainya dengan kaki Anda ("tetapi tidak ada yang mengatakan kepada saya bahwa sistem baru sudah bekerja", "oh, ya, itu lebih cepat dengan kaki saya", "tapi saya mengirimnya ke sistem Anda ini, dan tidak ada yang menjawab di sana", dll)."Saya mengirimnya ke sistem Anda ini, dan tidak ada yang menjawab di sana", dll.)."Saya mengirimnya ke sistem Anda ini, dan tidak ada yang menjawab di sana", dll.).

Jauh dari selalu siap untuk perubahan dalam proses bisnis dan manajer menengah dan bahkan manajer puncak. Mengubah proses bisnis mengarah pada perubahan fungsi personel bawahan dan mampu mengidentifikasi kekurangan personel yang berkualitas dan pelepasan personel karena pengurangan biaya tenaga kerja untuk melakukan fungsi tertentu. Ini adalah faktor politik tersembunyi yang dapat sangat memengaruhi pengambilan keputusan dalam mengubah proses bisnis. Pada tahap awal desain sistem, itu dapat dianggap tidak signifikan dan diselesaikan secara organisasi di tingkat pemilik proses. Tetapi pada tahap uji coba atau operasi industri percontohan dengan kurangnya potensi manajerial, penerapan proses bisnis bahkan dapat mengarah pada sabotase pekerjaan proyek oleh manajer menengah.Kurangnya sumber daya dapat dideteksi selama OPE dan secara langsung memengaruhi jalannya operasi, dan kurangnya ketersediaan atau kualifikasi personel akan disembunyikan oleh manajer dengan dalih kompleksitas pengoperasian "ini sistem Anda" dan mengarah pada persyaratan untuk mengubah sistem baru ke proses bisnis yang sudah ada sebelumnya.

Bahkan pemilik proses dan manajemen puncak mungkin tidak siap untuk perubahan dalam proses bisnis. Kunci keluar dari satu proses bisnis adalah input ke proses bisnis lain. Dan aturan biasa dalam memodelkan proses bisnis ini cocok sekali di atas kertas, tetapi menemui perlawanan kuat dalam praktiknya. Alasan ketidakkonsistenan proses bisnis dalam kasus ini bersifat politis dan solusi untuk ketidakkonsistenan ini agak menyakitkan.

Situasi buku teks ketika rencana penjualan disetujui di perusahaan secara terpisah dari rencana produksi. Dan ketika membentuk rencana pengadaan, baik rencana penjualan maupun rencana produksi tidak diperhitungkan. Pada tahap alur kerja kertas, kesenjangan dalam proses bisnis ini tidak terlihat begitu jelas, atau lebih tepatnya, mereka terlihat, tetapi pemilik proses telah belajar untuk mengatasinya di tingkat operasional. Setiap pemimpin pergi ke direktur untuk menandatangani rencananya sendiri. Dan dia membuat analisis fakta-rencana secara eksklusif sesuai dengan rencananya. Pada saat yang sama, integritas gambar kehidupan perusahaan hilang, istirahat dalam analis diakui praktis tidak dapat dihindari, manajemen manajer puncak dilakukan secara manual berdasarkan data yang tidak relevan, tidak lengkap.

Penting untuk mengidentifikasi kontradiksi dan kesenjangan dalam proses bisnis sedini mungkin dan mengambil keputusan mereka ke tingkat tertinggi. Peta strategis yang diperbesar dari proses-proses bisnis "bagaimana akan" harus dirasakan dan didukung oleh pemilik proses sebagai konstitusi. Sistem ERP yang diperkenalkan tidak akan menyelesaikan kontradiksi dan inkonsistensi proses bisnis ini secara otomatis, tidak akan menguburnya, tetapi akan membawanya ke permukaan dan menyelesaikan masalah ini selama tahap operasi akan jauh lebih mahal. Dan keterlambatan penyelesaian kesenjangan proses bisnis sangat sering mengarah pada penangguhan proyek dengan semua konsekuensinya, atau untuk otomatisasi dan penyimpangan sebagian dari tujuan proyek.

Apa yang bisa dilakukan untuk perubahan paling produktif dalam proses bisnis?


  1. - « » -, -. , , . , 8 , . - , . 10 .

    , - . , - - . - -. ( « , , »), , .
  2. - . - . , , . , , .
  3. - . -, . , -, . , . , -, , , « » . . , . , 10 - , , , .
  4. . ERP-, -. . - - . - , , .
  5. , ERP-, « ». , .
  6. KPI -. KPI , ..

Ringkasan: Saya pikir bahwa proyek untuk mengimplementasikan sistem ERP akan memiliki peluang sukses yang jauh lebih besar jika semua peserta proyek di sisi pelanggan berbagi tesis bahwa sistem informasi berfungsi untuk mengotomatisasi proses bisnis yang ADA, siap untuk menyusunnya, meletakkan informasi di rak, menyiapkan analitik, tetapi itu bukan pengganti otak para pemain dan tidak akan menjadi penyelamat jika manajemen perusahaan itu sendiri tidak siap untuk menghadapi kekacauan yang ada.

Source: https://habr.com/ru/post/undefined/


All Articles