Saat Tepat Go Live Sebuah Proyek Implementasi ERP
Kadang kala dalam sebuah pre-sales meeting dengan klien atau bahkan dalam rapat proyek implementasi muncul pertanyaan kapan waktu yang tepat untuk Go Live. Pertanyaan semacam ini biasanya bukan sekedar pertanyaan teknikal, justru sering kali terkait dengan bisnis atau fungsional. Apalagi jika pertanyaan tersebut diajukan bukan oleh seorang manajer IT, atau VP engineering tetapi oleh pihak manajemen baik itu CEO atau manajer keuangan. Untuk memastikannya tentunya perlu mengkonfirmasi maksud dari pertanyaan tersebut. Misalnya “Maksudnya terbaik dari sisi apa pak? Dari sisi bisnis? Atau dari tehnis/development effort?”
Sebagai seorang engineer, kita sedikit banyak perlu tahu masalah bisnis. Karena belakangan, setelah banyak start-up selesai dengan produk digital, mereka akan fokus kepada sistem back-office. Kecil atau besar, kita tentu perlu berkecimpung dan membantu implementasi ERP(Enterprise Resource Planning) walau mulai dari skala yang kecil, misalnya modul atau aplikasi akuntasi.
Sebuah start-up yang baru saja mulai, biasanya masih menggunakan sistem akuntansi sederhana, baik itu manual atau sistem akuntansi stand-alone yang ada di desktop. Tetapi, saat kebutuhan integrasi semakin tinggi, sebuah ERP mulai diperlukan. Bagusnya saat ini ERP open-source banyak tersedia di market. Tinggal kita pilih sesuai dengan kebutuhan dan anggaran yang tersedia. Salah satunya tentu adalah Odoo dimana Hyperjump merupakan Odoo partner di Indonesia. :-)
Terbaik adalah di Awal Tahun Fiskal
Kembali ke pertanyaan awal, jika yang diinginkan adalah saat terbaik dari sisi bisnis maka saat terbaik tentunya di awal tahun fiskal. Mengapa demikian? Ya karena cut off di sisi akuntansi akan cukup rapi, dimana sistem baru akan memulai mencatat transaksi baru di tahun fiskal yang baru. Semua transaksi tahun sebelumnya berakhir di sistem lama kecuali open item, yaitu transaksi yang belum selesai(settled) seperti customer invoice yang belum dibayar, tagihan supplier yang belum dilunasi, ataupun employee expense yang masih belum dibayar di tahun sebelumnya.
Dari sisi pelaporan keuangan, akan sangat mudah cut off nya. Segala yang terjadi pada tahun sebelumnya akan perlu dilihat di sistem sebelumnya(legacy). Hanya pelaporan tahun ini (baru) dan ke depan yang akan dilihat di sistem baru. Hal ini dikarenakan umumnya pelaporan keuangan dan operasional memerlukan data year-to-date. Jika ada pelaporan inception-to-date, untuk account balance sheet, maka nilai closing di sistem lama akan dibawa ke sistem baru sebagai opening balance.
Awal Kuartal
Walau idealnya di awal tahun fiskal, sering kali timing tersebut tidak sesuai dengan lini masa proyek. Bisa jadi proyek dimulai lebih awal atau lebih akhir yang menyebabkan ujung ekor proyek tidak tepat di akhir tahun. Atau juga tekanan pada saat year-end closing sudah sedemikian tinggi, sehingga perusahaan memilih untuk tidak menambah kerepotan untuk persiapan Go-Live. Dengan demikian sehabis year-end closing, para key user boleh beristirahat sejenak dan mengambil cuti tahunan justru sehabis tahun baru.
Jika hal itu terjadi, maka pilihan berikutnya adalah menyesuaikan di awal sebuah kwartal. Terutama hal ini jika perusahaan terkait adalah perusahaan terbuka atau perusahaan tertutup yang perlu memberikan laporan keuangan ke investor secara kwartalan. Maka untuk mengurangi tekanan pada project team pada saat-saat kritis pelaporan kwartalan, maka closing kwartal bisa dilakukan di sistem lama, kemudian kwartal baru di sistem baru.
Sebagai contoh, jika tahun fiskal dimulai dari januari sampai desember, maka Go live bisa direncanakan pada tanggal 1 April untuk memberi kesempatan closing kwartal (Q1) di sistem lama. Angka closing Q1 itulah yang kemudian akan dibawa sebagai opening balance atau melalui journal entry di Q2 di sistem baru. Transaksi operasional akan mulai diposting di system baru mulai 1 April ke depan.
Dari sisi pelaporan keuangan maka sistem baru akan dapat memberikan pelaporan mulai kuartal 2 (Q2) ke depan. Sementara laporan kuartal 1 (Q1) harus dilakukan di sistem lama. Hal ini adalah konsekuensi logis dari pilihan ini.
Awal Bulan
Pada sebuah perusahaan yang masih belum begitu besar, tuntutan laporan tahunan maupun kwartalan bisa jadi tidak terlalu rumit dan besar. Sehingga memiliki fleksibilitas untuk Go Live di sebuah awal bulan manapun. Hal ini terutama jika memang lini masa proyek tidak tepat berujung di sebuah awal tahun atau awal kwartal.
Pada prinsipnya sama saja dengan awal kwartal di atas, closing bulan terakhir perlu diselesaikan di sistem lama. Kemudian closing di bulan itu dibawa melalui journal entry ke sistem baru sebagai opening balance. Misal Go Live di bulan November, maka closing Oktober perlu diselesaikan di sistem lama.
Secara pelaporan pun mirip, hanya saja sistem baru hanya akan bisa memberikan laporan keuangan mulai dari bulan Go Live. Pada contoh di atas berarti adalah November.
Bagaimana Jika Pertengahan Bulan?
Pada kasus-kasus tertentu, mungkin kita akan menjumpai kondisi dimana perusahaan hanya bisa Go Live pada pertengahan bulan. Misalnya karena karena ada penundaan pelaksanaan proyect implementasi sehingga waktu untuk sistem Go Live meleset beberapa hari sampai satu atau dua minggu. Atau karena libur nasioal seperti tahun baru atau lebaran, membuat tim harus mengundurkan Go Live karena memang operasional pada saat itu sangat sedikit atau bahkan memang libur.
Pada keadaan tersebut tentu terpaksa kita melakukan modifikasi terhadap lini masa Go Live awal bulan dengan aktivitas tambahan berupa backlog posting. Jadi misalnya kita live pada 9 November, maka antara tanggal 1 sampai tanggal 8 November akan masih dicatatkan di sistem lama. Saat sudah live maka perlu dilakukan backlog posting di sistem baru untuk tanggal 1 sampai 8 tadi. Untuk closing dan opening balance journal entry, akan sama dengan aturan pada opsi awal bulan di atas.
Demikian sekilas pengetahuan tentang timing untuk Go Live yang akan menjadi penting saat perencanaan proyek ERP atau merencanakan sebuah detail cut-over plan(cut-over plan: rencana langkah demi langkah perpindahan sistem menjelang Go Live). Tentunya hal yang di atas masih perlu didiskusikan dengan bisnis secara mendalam untuk memastikan semua skenario bisnis tercakup dalam cut over plan.
Hyperjump is an open-source-first company providing engineering excellence service. We aim to build and commercialize open-source tools to help companies streamline, simplify, and secure the most important aspects of its modern DevOps practices.
