Menggabungkan sistem akuntansi cabang terpencil dan integrasi mereka dengan struktur induk adalah tugas yang agak sulit bahkan di dalam Rusia. Dan ketika pelanggan berada di luar negeri, seluruh proyek dapat menyulitkan kurangnya keahlian dalam undang-undang pajak lokal dan konflik mentalitas. Nama saya Stanislav Gotz, saya adalah kepala departemen pengembangan sistem ERP Lamoda dan dalam posting ini saya akan memberi tahu Anda tentang pengalaman ini - tentang penerapan sistem ERP di cabang Jerman kami.

Anak perusahaan kami di Jerman membeli barang dan menjualnya ke badan hukum Rusia. Sistem Tsenit yang digunakan di dalamnya memungkinkan menyimpan catatan hanya pada tingkat data keuangan: siapa, siapa, dan berapa banyak uang yang terhutang, ketika pembelian atau penjualan berlangsung, dll. Tidak mungkin untuk melakukan akuntansi barang dan tugas logistik menggunakan alat Tsenit, untuk menyelesaikan masalah ini, alat tambahan harus digunakan, yang secara negatif mempengaruhi kecepatan dan keandalan seluruh sistem. Data sebagai hasilnya tersebar di beberapa basis data.
Selain itu, badan hukum Jerman harus menyerahkan laporan, membayar pajak, dan lulus audit - dan dengan sistem akuntansi yang ada, tidaklah mudah untuk menyelesaikan masalah tersebut.

Untuk memahami mengapa transaksi keuangan ini atau itu dilakukan di Tsenit dan menjawab pertanyaan sederhana dari otoritas pajak atau auditor, saya harus secara manual menyekop sejumlah besar data di Excel dan menghubungi departemen logistik.

Pada titik tertentu, diputuskan untuk menggabungkan akuntansi dan keuangan dengan logistik ke dalam satu sirkuit tunggal dalam kerangka sistem ERP cabang tunggal. Sebagai perangkat lunak utama dipilih Microsoft Dynamics 365 - sebelumnya Dynamics AX, atau bahkan lebih mudah - Axapta. Hampir tidak ada klien Rusia yang menggunakan solusi cloud dari sistem ini (lebih tepatnya, kami menjadi yang kedua), tetapi itu paling cocok untuk tujuan kami.
Pengaturan Waktu, Anggaran, dan Keyakinan di Masa Depan yang Cerah
Kami memiliki batas waktu yang ketat: peluncuran sistem seperti itu di tengah tahun fiskal mengharuskan transfer seluruh rangkaian data historis, yang akan menjadi tugas yang mustahil, karena dalam sistem yang lama, akuntansi barang hampir tidak ada dan disimpan dalam lembar kerja. Tetapi pada awal periode pelaporan, cukup untuk mentransfer saldo saja. Karena itu, perlu diluncurkan 1 Januari 2019, atau ditunda untuk satu tahun lagi. Proses yang terkait dengan logistik perdagangan dan gudang tidak terlalu rumit, dan bagi kami tampaknya tidak akan ada masalah dengan tenggat waktu.
Selain tenggat waktu, ada juga masalah anggaran: penggelaran dan pemeliharaan infrastruktur TI Anda sendiri di Jerman dan membeli lisensi perangkat lunak perusahaan terlalu mahal per pengguna.
Karena tidak lebih dari 20 orang berpartisipasi dalam proses bisnis Jerman, kami memutuskan pada solusi cloud Dynamics 365. Untuk cabang-cabang terpencil kecil, skema SaaS optimal, memungkinkan Anda untuk mendapatkan semua perangkat lunak dan lingkungan pengembangan yang diperlukan untuk memulai implementasi segera setelah menandatangani kontrak dengan penyedia.
Kebijakan lisensi Microsoft Dynamics 365 sangat sederhana dan mengasumsikan harga tetap untuk satu lisensi pengguna per bulan, sementara jumlah pengguna dapat ditingkatkan atau dikurangi. Ini adalah argumen lain untuk memilih produk perangkat lunak khusus ini.
Perangkap
Masalah utama terletak di luar bidang teknis: kami tidak tahu semua persyaratan undang-undang Eropa untuk menyimpan catatan dalam sistem tersebut. Microsoft Dynamics 365 mencakup sejumlah besar proses bisnis; paket lokalisasi yang disebut dirilis yang memungkinkan Anda untuk secara fleksibel menyesuaikan solusi dengan spesifikasi undang-undang negara tertentu. Jika tim pengembangan mempelajari versi Rusia untuk waktu yang lama, maka kami tidak pernah menemukan versi untuk Jerman. Menyiapkan solusi semacam itu oleh tim Anda sendiri akan menjadi tugas yang sulit.


Manajemen Jerman memiliki kekhawatiran bahwa pihak Rusia tidak dapat mengatasi tugas tersebut karena kurangnya pengalaman dan pengetahuan dalam pajak dan akuntansi lokal. Sebagai hasilnya, kami memilih jalan tengah dan menarik konsultasi eksternal. Seharusnya menutup celah yang terkait dengan persyaratan hukum Eropa, memberikan audit migrasi dari sistem keuangan sebelumnya, menganalisis deskripsi proses bisnis, mengoptimalkannya dan menyesuaikan solusi masa depan dengan penggunaan maksimum fungsi standar. Jika perlu, mereka direncanakan selesai, secara bertahap menjerumuskan tim Rusia ke dalam pengembangan.
Mulai dari implementasi dan transfer data
Secara default, kami mendapat hak atas tiga lingkungan: BUILD - untuk merakit kode yang dibuat oleh pengembang berbeda ke dalam satu aplikasi, SAT (Standard Acceptance Testing) โuntuk melakukan pengujian penerimaan pengguna, dan PROD - untuk operasi. Selain itu, mesin virtual dev-box dikerahkan untuk setiap pengembang di Azure. Seluruh infrastruktur dikelola dan dimonitor melalui portal tunggal - layanan Siklus Hidup , dan fitur dari proses kustomisasi adalah bahwa setiap perbaikan memasuki lingkungan PROD hanya melalui SAT.
Karena fakta bahwa Microsoft Dynamics 365 dipilih sebagai sistem baru, transfer data relatif mudah diterapkan dengan menggunakan paket Data yang tersedia dari kotak. Dynamics 365 memiliki hubungan dekat dengan produk Microsoft, termasuk Excel: untuk pengguna, itu tampak seperti spreadsheet yang terhubung ke layanan Dynamics 365 melalui
ODATA . Menggunakan ekstensi Excel, pengguna menerbitkan data langsung ke sistem. Sisi Jerman menyiapkan template, mencatat kolom yang diperlukan di dalamnya. Pengguna mengisi templat ini, dan konsultan mengendalikan proses impor.
Antara lain, dari sistem akuntansi lama, para konsultan mentransfer informasi tentang pemasok dan pelanggan, serta saldo pada akun buku besar umum. Transfer langsung semua data barang akan membutuhkan waktu dan upaya yang cukup besar, dan kami mencoba menyelesaikan masalah ini dengan cara yang lebih efisien. Integrasi sistem akuntansi baru dari cabang Jerman dengan sistem Rusia utama, di mana data master barang berada, diimplementasikan. Pada akhir tahun, kami tidak memiliki keseimbangan fisik di Jerman, dan sebagai hasilnya, perlu untuk mentransfer dari sistem lama hanya informasi latar belakang yang diperlukan untuk distribusi barang lebih lanjut. Dengan demikian, dimungkinkan untuk membuang semua data historis tentang barang, yang menghemat waktu.
Setengah outsourcing: menghubungkan tim Rusia
Setelah memulai implementasi pada Juni 2018, kami berharap dapat menyelesaikan semua masalah sebelum liburan Tahun Baru, tetapi selain masalah bahasa alami dalam proyek-proyek tersebut, kesulitan komunikasi muncul. Konsultan Jerman telah lama menanggapi pertanyaan. Seorang karyawan tidak dapat bekerja tanpa istirahat lebih dari 6 jam berturut-turut. Setelah menyelesaikan pekerjaan, ia harus memiliki waktu bebas minimum 11 jam dari pekerjaan. Dan ketika seorang spesialis berurusan dengan klien lain, dia tidak dapat ditanya tentang apa pun. Pendekatan formal semacam itu telah memengaruhi waktu. Pada titik tertentu, kontraktor yang diusulkan oleh tahun baru untuk meluncurkan hanya akuntansi keuangan, yang sudah bekerja dalam sistem yang lama. Ini tidak cocok untuk kita. Sejak 2013, kami telah secara independen menerapkan Axapta di Lamoda, dan pada 2016 kami sepenuhnya mentransfer semua akuntansi dari 1C ke sana. Proses di Rusia jauh lebih kompleks, jadi kami tahu bahwa proyek tersebut dapat diselesaikan tepat waktu.

Kami memutuskan untuk menarik tim Rusia, mengambil semua penyesuaian dan pengembangan fungsi sistem dari rekan-rekan kami dari Jerman. Faktanya, kami menyerahkan kepada kontraktor eksternal hanya konsultasi, penetapan tugas, dan desain fungsional. Mereka memberi tahu kami apa yang perlu dilakukan, kami melakukannya, dan kemudian mereka menguji dan menerima hasilnya. Kecepatan implementasi telah meningkat, tetapi segera organisasi seperti alur kerja memerlukan revisi: konsultan keuangan Jerman pergi berlibur selama tiga minggu. Untuk proyek ini, tenggat waktu ini menjadi sangat penting, tugas utama kami terkait dengan keuangan, pajak, dan sejenisnya. Saya harus mengambil bagian ini juga, sebagai hasilnya, para ahli kami menemukan undang-undang pajak Eropa tidak jauh lebih buruk daripada yang eksternal.
Ditambah terus-menerus ada beberapa tugas yang tidak standar. Berkat pencelupan mendalam tim utama Rusia dalam pengembangan, mereka dapat menyelesaikannya dengan relatif cepat. Selain itu, solusi pada awalnya dikembangkan dengan mempertimbangkan pengetahuan semua sistem dan proses yang digunakan di perusahaan kami.
Salah satu tugas ini adalah integrasi lingkungan cloud baru dengan sistem ERP Rusia yang ada. Itu sudah menerapkan fungsionalitas yang berkaitan dengan pekerjaan pembeli, dan kami tidak ingin menduplikasi kode agar tidak menyulitkan dukungannya. Akibatnya, pesanan untuk pembelian barang dari pemasok asing dibuat dalam ERP Rusia dan kemudian ditransfer ke cloud Jerman.
Dalam proses implementasi, tim Rusia telah menguasai pendekatan yang sepenuhnya baru untuk pengembangan bagi kami dan alat-alat baru. Kami dulu menggunakan IDE kami sendiri untuk Axapta, tetapi di sini kami beralih ke Visual Studio dan Azure DevOps. Selama implementasi proyek, versi perangkat lunak berubah, dan spesialis kami tahu semua kesenangan pengembangan paralel untuk lingkungan cloud - dalam istilah teknis, itu sangat menarik.
SureStep vs Agile: Masalah Peluncuran
Kolega dari Jerman bekerja sesuai dengan metodologi Microsoft SureStep. Ini adalah pendekatan yang tidak fleksibel yang lebih dekat dengan "air terjun" klasik. Ini melibatkan pada setiap tahap dokumentasi segalanya, persiapan desain fungsional dan teknis, pengujian ketat dengan pelepasan protokol, perekaman proses dalam beberapa sistem pemodelan, dll. Dengan permintaan dokumentasi semacam itu, rekan-rekan menghubungi kami sebulan sebelum peluncuran. Sistem ERP baru pada saat itu sudah lebih atau kurang berfungsi. Dengan asumsi untuk meluncurkannya dalam enam bulan, kami telah memilih metode pengembangan yang lebih fleksibel: stand-up harian, diskusi tugas, dan rilis mingguan. Untuk dokumentasi, kami menggunakan item Kerja di Azure DevOps, mereka juga mencerminkan kemajuan proyek dan mengkonfirmasi hasil pengujian.
Karena sistem mendung, keputusan akhir tentang rilis dalam produksi dibuat oleh Microsoft, semua kontak dengan yang dilakukan oleh kontraktor kami. Mereka, pada gilirannya, tidak siap untuk mengirim aplikasi tanpa semua dokumentasi yang diperlukan dari sudut pandang metodologi SureStep. Akibatnya, peluncuran proyek yang tepat waktu berada dalam bahaya.
Kami memutuskan untuk menghubungi vendor sendiri dan menerima persetujuan untuk memasuki produksi, setelah itu kami dengan tenang dan sistematis meningkatkan fungsionalitas sistem kami sendiri. Pakar Jerman membantu kami mentransfer pengaturan dari lingkungan pengujian ke toko kelontong. Setelah itu, mereka mengatur akuntansi dan memperbaiki kekurangannya jika kita punya komentar.
Tes pertempuran
Berkat keterlibatan tepat waktu dari tim kami sendiri, kami berhasil memenuhi tenggat waktu dan meluncurkan sistem pada 1 Januari 2019, seperti yang semula direncanakan.
Sistem akuntansi baru telah menggabungkan bagian keuangan dan logistik, kami telah melewatinya laporan triwulanan di Jerman. Sebelum itu, kami berhasil melakukan apa yang disebut penutupan bulan tanpa kerugian signifikan dalam hal. Ketika meluncurkan kelas sistem ini, penundaan tidak bisa dihindari, tetapi pada bulan Januari kami terlambat tiga hari, dan pada bulan Februari - hanya satu. Sementara kami mengumpulkan data dari sistem secara manual, sekarang tim pengembangan Rusia terlibat dalam otomatisasi pelaporan. Masalahnya terutama terkait dengan faktor manusia: sulit bagi karyawan untuk melakukan prosedur baru untuk mereka, dan beberapa kekasaran pasti akan keluar.
Sekarang kami memiliki gambaran transparan barang di tingkat nomor gudang individu (SKU) dan data saldo di gudang-gudang menengah Eropa. Itu tidak mungkin untuk menutup sejumlah tugas sampai akhir: ada kesulitan dengan integrasi dengan bank Jerman dan sejumlah masalah kecil untuk penyelesaian tepat waktu di mana sumber daya dari tim internal tidak cukup - pada awalnya diasumsikan bahwa kontraktor akan menutup bagian depan ini. Pada dasarnya, itu semua bermuara pada kurangnya tingkat otomatisasi yang tepat dan beberapa peningkatan dalam jumlah pekerjaan manual untuk pengguna akhir. Sekarang kami secara bertahap menutup celah dengan kekuatan tim kami dan dengan bantuan mitra baru dengan cabang di Rusia.

Bonus yang pengembang kami kerjakan dalam proyek juga merupakan fakta bahwa segera pada tahap implementasi, perbaikan dilakukan untuk meningkatkan fungsionalitas sistem.
Tim Rusia telah mengembangkan penentuan pajak otomatis atas pesanan pembelian dan penjualan. Secara default, sistem mengharuskan akuntan untuk secara manual mengatur skema pajak saat memproses faktur dan memposting transaksi. Dalam hal ini, perlu untuk mempertimbangkan negara pengiriman, negara pendaftaran pemasok, yang mengambil barang (penerima atau pemasok), yang mengirim barang ke Federasi Rusia (badan hukum Jerman atau Rusia), apakah barang diambil langsung dari pemasok ke Rusia atau kargo dikonsolidasikan di Eropa. Akuntan tidak memiliki semua kehalusan ini untuk setiap pengiriman. Kami telah sepenuhnya mengotomatiskan proses dalam sistem sehingga penyedia logistik yang bertanggung jawab memperkenalkan parameter awal yang diperlukan. Selanjutnya, sistem berdasarkan pengaturan yang dibuat itu sendiri menentukan skema pajak dan entri akuntansi yang diperlukan. Semua data secara otomatis dikonsolidasikan ke dalam laporan statistik yang diperlukan untuk Jerman dan SPT. Dengan demikian, tanggung jawab didistribusikan dengan lebih baik di antara spesialis, kecepatan dan keandalan pekerjaan meningkat.
Ringkasan
Awalnya, kami berharap bahwa sebagian besar pekerjaan akan jatuh pada kontraktor, dan sebagai hasilnya, semua blok kunci dibuat oleh pengembangan kami sendiri. Biasanya, peluncuran ERP membutuhkan waktu 1 tahun, tetapi kami berhasil memulai 6 bulan setelah proyek dimulai, di mana pengembangan aktif hanya berlangsung selama 3 bulan.
Hasilnya, kami mendapat pengalaman unik, yang kami putuskan untuk dibagikan. Kerja sama dengan kontraktor asing yang mengetahui kondisi setempat masuk akal secara praktis, tetapi Anda seharusnya tidak mengharapkan keajaiban dari mereka. Jika Anda memiliki
tim kuat Anda sendiri , Anda harus mengalihdayakan hanya konsultasi dan pengaturan tugas, serta pengujian.

Ini bukan akhir dari kisah kami. Sebuah tantangan baru dikaitkan dengan pengenalan di Rusia sistem persatuan nasional untuk menandai barang. Legislator menunda tanggal peluncurannya hingga 2020, tetapi mulai Juli kami ingin menandai setiap pasang sepatu dengan kode batang yang unik sebelum melewati pabean. Selain itu, selalu ada tugas yang terkait dengan mengoptimalkan kinerja. Ada banyak ide dan rencana lain. Dalam implementasinya, kita sekarang akan lebih mengandalkan kekuatan kita sendiri, yang pertama-tama kita harus "menjadi gemuk".