Migrasi dari satu sistem ERP ke yang lain

Seringkali, peralihan perusahaan ke sistem ERP baru tidak menghentikan biaya keuangan dari pembelian dan penyelesaian, tetapi kebutuhan untuk bermigrasi dari sistem yang lama. Mereka memiliki ratusan atau bahkan ribuan pengguna yang melakukan proses bisnis mereka dalam satu program, dan entah bagaimana mereka harus ditransfer semua ke yang lain tanpa berhenti untuk bisnis.

Dalam beberapa tahun terakhir, kami telah melakukan hal ini beberapa kali, dan kami telah mengembangkan cara yang paling tidak menyakitkan untuk melakukan ini.

Kesulitan

Hari ketika Bison menghormati desamu dengan kehadirannya, menjadi hal terpenting bagimu dalam hidup. Tetapi bagi saya itu hari Selasa.
- Bayson, Pejuang Jalanan

Proses transisi sering dipersulit oleh kenyataan bahwa banyak karyawan pelanggan yang mudah dipengaruhi dalam keadaan panik untuk pertama kalinya, karena bagi mereka ini kemungkinan besar merupakan migrasi pertama dalam karier mereka. Bagi kami, ini adalah peristiwa biasa, yang biasanya terjadi sesuai dengan skenario yang sama.

Ketika seseorang menukar satu produk dengan yang lain, hal pertama yang dia perhatikan adalah bahwa dia diambil darinya dan belum menyadari apa yang dia terima . Oleh karena itu, sering kali reaksi pertama adalah: “omong kosong apa yang kamu selipkan di sini - lakukan apa adanya.” Dalam praktiknya, kami memiliki situasi di mana satu pengguna mengeluh bahwa dia tidak nyaman dengan tindakan baru, yang dilakukan dalam sistem lama dalam lima transisi antar formulir. Tetapi ia telah menyempurnakan automatisme sedemikian rupa sehingga bagi seseorang itu pada awalnya lebih cepat untuk melakukannya daripada melakukan dua tindakan baru, tetapi jauh lebih sederhana.

Kesulitan lain adalah bahwa selama masa transisi, pelanggan suka mengubah proses bisnis ke visi mereka. Ini harus diperlakukan dengan sangat hati-hati, karena proses “sebagaimana adanya” saat ini dijamin akan berhasil. Proses yang tertanam dalam produk, sebagai suatu peraturan, juga berfungsi, sebagaimana digunakan oleh pelanggan lain. Tetapi secara teori penemuan-penemuan baru mungkin terlihat indah, tetapi dalam praktiknya penemuan-penemuan itu akan menjadi sepele, sehingga seluruh proses dapat terhenti.

Skenario

Dalam praktiknya, ada dua skenario utama untuk berpindah dari satu sistem ke sistem lainnya:

Sesaat

Tanggal transisi ke sistem baru ditentukan. Semua fungsi dikembangkan untuk membongkar data dari sistem lama dan memuatnya ke yang baru. Pada hari X, migrasi dimulai pada malam hari, dan di pagi hari semua pengguna dengan semua proses bisnis mulai bekerja di sistem baru dengan cara yang baru.

Semuanya indah di atas kertas. Namun dalam praktiknya setidaknya ada empat kategori masalah:

1. Pelatihan Pada saat transisi, sebagai suatu peraturan, banyak pengguna yang terlatih sepenuhnya melupakan apa yang diajarkan kepada mereka. Mereka mulai menyodok segalanya, dan sebagai akibatnya mereka menghentikan pekerjaan mereka dengan kata-kata "tidak ada yang berhasil". Masalah ini dapat diatasi dengan bantuan staf pendukung lini pertama yang dapat membantu saat ini. Tetapi akan ada begitu banyak permintaan seperti itu pada hari pertama transfer sehingga tidak mungkin untuk memenuhi mereka dengan jumlah karyawan yang tersedia. Atau Anda perlu memiliki cara untuk entah bagaimana cepat menambah nomor mereka selama transfer, yang juga cukup sulit dilakukan.
2. Perbaikan dan kesalahan . Sebagai aturan, sistem ERP baru membawa serta proses bisnis baru (jika tidak mengapa mengubahnya). Jelas bahwa segera sebelum implementasi mereka entah bagaimana diusir, tetapi pada saat "pemeriksaan perang" yang sebenarnya, banyak sekali nuansa yang keluar, karena seringkali prosesnya tidak dapat dijalankan. Oleh karena itu, sekali lagi jumlah peningkatan tersebut dengan prioritas segera tumbuh seperti bola salju, dan ada kebutuhan yang tajam untuk sumber daya programmer yang secara fisik tidak akan dapat menutup sejumlah permintaan seperti itu.
3. Data Biasanya, para pengembang sistem lama tidak terlalu tertarik untuk membantu mengunggah data (bagi mereka ini umumnya merupakan peristiwa menyedihkan kehilangan klien), dan jika mereka membantu, kualitas unggahan meninggalkan banyak hal yang diinginkan. Dan inkonsistensi, sebagai suatu peraturan, ditemukan pada hari-hari pertama pengoperasian sistem baru. Akibatnya, diperlukan untuk memperbaiki pembongkaran, dan entah bagaimana memuat ulang data, dengan mempertimbangkan sudah berubah selama operasi.
4. Performa . Selama proses pengujian, tidaklah mudah untuk mereproduksi beban "nyata" sepenuhnya pada sistem. Jika fungsionalitas dasar dari produk biasanya sudah diuji dan menunjukkan parameter kinerja normal, maka peningkatan "pribadi" untuk klien dapat, dalam keadaan tertentu, "duduk" server. Ini, pada gilirannya, juga membutuhkan sumber daya programmer untuk optimisasi.

Ketika keempat masalah ini terjadi pada hari atau minggu pertama transisi pada saat yang sama, maka kerugian bisnis tidak dapat dihindari. Oleh karena itu, skema semacam itu hanya bekerja secara efektif pada proyek-proyek kecil. Misalnya, ketika jumlah pengguna kurang dari seratus dan prosesnya tidak kritis.

Jelas bahwa Anda dapat menghabiskan lebih banyak sumber daya untuk melatih dan menguji sistem segera sebelum transisi, dan kemudian akan ada lebih sedikit masalah. Namun dalam hidup, karyawan pelanggan biasanya merujuk pada proses ini "tanpa lengan" dan bergantung pada "mungkin". Atau mereka hanya keliru, berharap bahwa proses tertentu akan dapat menghasilkan uang dalam pengaturan tertentu, tetapi pada kenyataannya, tampaknya nuansa kecil akan mengurangi segalanya.

Bertahap

Dengan pendekatan ini, sistem dibagi secara horizontal (berdasarkan proses) atau secara vertikal (oleh pengguna) menjadi beberapa bagian, yang diperkenalkan secara berurutan. Ini memungkinkan Anda untuk menyebarkan semua masalah di atas dalam waktu dan menyelesaikannya karena mereka menerima lebih sedikit daya.

Lebih lanjut, saya akan menjelaskan proses migrasi sistem ERP berdasarkan platform lsFusion terbuka dan gratis untuk rantai toko ritel, karena kami berspesialisasi dalam industri ini. Tetapi kami menerapkan prinsip yang sama untuk klien dari area lain.

Pembacaan data

Biasanya, bagi perusahaan yang mendukung sistem lama, berita tentang mengganti program mereka dan kehilangan klien adalah pukulan besar. Beberapa jatuh ke dalam kondisi yang tidak memadai dan mulai mengancam klien dengan segera menghentikan dukungan. Secara alami, ini tidak pernah berhasil, dan tidak pernah bisa membalikkan keputusan. Namun, jarang mungkin untuk setuju dengan mereka yang mendukung sistem lama bahwa mereka menyediakan tabel di mana semua data yang diperlukan untuk transisi disimpan.

Pertama, Anda perlu menentukan di mana DBMS informasi yang diperlukan disimpan dan bagaimana mengaksesnya. Selama beberapa tahun terakhir, kami harus berurusan dengan DBMS berikut yang digunakan sistem lama:

• Akses Karena platform ini ditulis dalam Java, adalah mungkin untuk menggali perpustakaan kuno yang tahu cara terhubung ke mdb (meskipun hanya untuk membaca). Ini bekerja sangat aneh, karena meskipun filter itu membaca seluruh tabel, tetapi bagaimanapun itu sudah cukup. Kami beruntung bahwa layanan TI pelanggan mengetahui struktur basis data dengan cukup baik dan memberi tahu kami apa dan di mana disimpan.
• MS SQL Sistem lama adalah Axapta 2000-an. Kami mengatur akses ke sistem pengujian, tempat kami meluncurkan GUI dan SQL Profiler. Lalu kami bergantian di direktori, dan melihat apa yang dihasilkan permintaan Axapta. Mudah dipahami dari mereka di mana tepatnya informasi ini atau itu disimpan.
• Visual Foxpro Itu semua sederhana, karena ada transisi dari sistem lama kami dan tidak sulit untuk mendapatkan informasi. Satu-satunya kesulitan adalah menemukan perpustakaan Java yang dapat bekerja tidak dengan tabel DBASE, tetapi dengan format Visual Foxpro.
• Oracle Transisi dari program kotak supermag. Kami bekerja sesuai dengan skema yang mirip dengan skema Axapta: GUI dan kueri di Pengembang SQL untuk kueri terbaru. Struktur dasar dan antarmuka di sana jelas jauh lebih sederhana daripada di Axapta, jadi tidak ada masalah besar.
• Kemajuan / OpenEdge . Transisi dari program Gestori kotak. Mengingat bahwa DBMS, secara halus, sama sekali tidak populer, kami tidak menemukan profiler. Namun, ada dump di file teks. Ini memungkinkan untuk masuk ke GUI server uji dan mencari melalui file teks untuk mencari data yang terlihat di layar. Untungnya, di situs resmi DBMS ini ada peluang untuk mengunduh driver JDBC, dan membuat pertanyaan ke database SQL. Lalu itu masalah teknologi.

Berkat pendekatan seperti itu, saya tidak pernah harus beralih ke pengembang sistem lama, yang secara signifikan menghemat pengeluaran pelanggan, karena biasanya mereka hanya mengeluarkan sejumlah besar uang untuk kerja sama.

Data master

Semuanya dimulai dengan mengimpor data master. Khususnya, untuk perdagangan eceran, impor direktori kelompok barang, barang, kontraktor dan toko adalah yang pertama kali direalisasikan. Dengan transisi bertahap, ada dua pendekatan untuk mengimpor data master:

• Impor data satu kali, dan kemudian gandakan entri ke sistem lama dan baru.
• Pembaruan data terus menerus yang terus-menerus dari yang lama ke sistem yang baru.

Ada kasus ketika pendekatan pertama digunakan, tetapi terlalu memakan waktu dan sangat rentan terhadap faktor manusia dengan kemungkinan kesalahan. Karena itu, kami selalu menggunakan hanya opsi kedua.

Idealnya, sistem lama dapat mengakumulasi perubahan dan entah bagaimana berkomunikasi bahwa itu perlu diimport ulang. Tetapi biasanya tidak ada yang akan mengubah atau memodifikasi apa pun di sistem lama. Oleh karena itu, satu-satunya skema kerja yang kami gunakan adalah sebagai berikut:

1. Ada permintaan ke direktori sistem lama, yang membaca semua data darinya.
2. Data yang dibaca dibandingkan dengan saat ini di sistem baru dan perubahan terdeteksi.
3. Perubahan ditulis dalam satu transaksi ke sistem baru.

Kode pada platform untuk mengimpor direktori produk akan terlihat seperti ini:

Ini akan berfungsi sebagai berikut:

• BACA mempertimbangkan seluruh direktori dengan kode dan nama dalam memori
• IMPORT akan menulis semua data ke properti lokal (yaitu, tabel sementara dalam database)
• Siklus pertama akan membuat semua barang yang belum ada di database baru (cari berdasarkan kode produk). Terlepas dari kenyataan bahwa FOR ditulis di sana, ia mengkompilasi ke dalam satu permintaan ke database, yang hanya akan bekerja dengan tabel sementara.
• Siklus kedua akan memperbarui bidang untuk semua produk (termasuk yang baru dibuat). Dalam hal ini, hanya nilai yang diubah yang akan ditulis ke tabel sementara.
• Tindakan ketiga DELETE mendeteksi semua barang yang ada di database baru, tetapi tidak dalam data yang dibaca dan akan menghapusnya.
• BERLAKU akan memulai transaksi dan menulis semua perubahan ke database berdasarkan tabel sementara yang dihasilkan oleh perintah sebelumnya.

Bahkan, tindakan ini pada saat peluncuran sepenuhnya menyinkronkan direktori lama dan baru. Itu tidak menyimpan informasi tambahan, sehingga dapat dimulai kembali kapan saja, bahkan jika pertukaran sebelumnya selesai dengan kesalahan.

Karena semua tindakan dikompilasi ke dalam query SQL tanpa iterasi, ini semua dilakukan dengan cukup cepat dan aman. Biasanya, menukar direktori barang 100-200 ribu catatan membutuhkan waktu beberapa menit. Pada saat yang sama, karena PostgreSQL diversi versi, tidak ada pemblokiran pekerjaan pengguna yang terjadi saat ini.
Dengan cara yang sama, harga pemasok, matriks bermacam-macam, jadwal pemesanan dan informasi lain yang diperlukan untuk pekerjaan secara konstan disinkronkan. Namun, di sini muncul masalah bahwa logika domain dalam sistem lama tidak sesuai dengan logika domain baru. Misalnya, dalam sistem kami, kami memiliki riwayat versi matriks dan konsep tingkat produk di dalam matriks. Jika dalam sistem lama bermacam-macam toko saat ini disimpan datar sebagai boolean untuk toko dan barang, maka satu matriks dibuat untuk setiap toko dengan tepat satu tingkat.

Paling sering, kami mengaktifkan tindakan untuk menyinkronkan semua direktori dengan sistem yang lama sekali dalam satu jam, sambil memberi pengguna kesempatan untuk memulai pertukaran secara manual.

Prosesnya

Dalam ritel, kami biasanya membagi proses penerjemahan secara vertikal antara toko-toko dan secara simultan secara horizontal dari proses toko ke proses kantor.

Langkah pertama adalah memilih satu toko di mana transfer ke sistem baru akan dimulai. Impor saldo saat ini dan harga toko dari sistem lama dalam bentuk dokumen masuk dengan jumlah dan harga yang sesuai:


Beberapa minggu sebelum dimulainya toko, impor implementasi dari sistem POS terhubung. Ini diperlukan agar ada data historis untuk pembentukan pesanan di hari-hari pertama kerja.

Sangat sering, proses produksi sendiri ditransfer sedikit lebih lambat daripada proses utama. Dalam hal ini, pembongkaran ke dalam sistem dokumen lama tentang pergerakan bahan baku dan impor produk jadi dari sana dilaksanakan.

Pada hari transfer, impor dimulai pada malam hari, dan kemudian staf dukungan pelanggan dan jalur dukungan pertama kami dikirim ke toko. Mereka membantu pengguna memulai dalam sistem baru tanpa harus mengikuti pra-pelatihan. Dalam hal ini, biasanya untuk beberapa waktu, mengubah dokumen dalam sistem yang lama tidak menutup, karena orang salah, dan mereka membutuhkan kemampuan untuk memperbaiki kesalahan. Setelah beberapa minggu, sisa-sisa diimpor kembali, dan kemudian larangan perubahan dalam sistem lama sudah ada.

Setelah semua masalah yang dijelaskan di atas diidentifikasi dan diselesaikan di toko pertama, setelah sekitar dua minggu toko lain ditransfer. Sekali lagi iterasi untuk mengidentifikasi dan memperbaiki masalah. Dan kemudian semua yang lain diterjemahkan dengan sangat cepat, tergantung pada sumber daya dari layanan dukungan pelanggan dari klien. Selama ini, data master terus dimasukkan dalam sistem lama sehingga toko dapat berfungsi pada sistem lama.

Kemudian, ketika semua toko ditransfer, baik secara bertahap atau semua impor dari sistem lama segera dimatikan, dan pengguna mulai memasukkan data master ke dalam sistem baru.

Ringkasan informasi dari sistem lama dan baru diperoleh baik dalam akuntansi atau dalam sistem BI, di mana kedua sistem diunggah secara bersamaan. Di sana Anda bisa mendapatkan laporan ringkasan untuk interval, yang mencakup waktu di sistem lama dan baru.

Kesimpulan

Terlepas dari kompleksitas transisi yang jelas dari satu sistem ke sistem lain, setelah melewati jalur ini beberapa lusin kali, Anda memahami bahwa dengan skema yang disadap, semuanya sebenarnya tidak terlalu menakutkan. Lebih banyak masalah muncul dengan fakta bahwa sebagian besar karyawan klien cukup konservatif dan, pada kesempatan sekecil apa pun, menuntut untuk melakukan "sebagaimana adanya". Dan di sini sangat penting bahwa pelanggan memiliki seseorang dengan wewenang yang cukup yang dapat membandingkan proses lama dan baru, menentukan mana yang lebih optimal dan dapat "memecah" karyawan. Atau modifikasi proses sesuai dengan skema "sebagaimana adanya", jika ternyata sebaliknya.