Saat mencoba menggabungkan dua otomasi, saya kembali memisahkan penjualan dan administrasi karyawan

✨ Ringkasan GPT-5.6 Sol

Catatan tentang merancang struktur otomasi operasional yang dapat memperluas proses penjualan dan SMS yang sudah berjalan ke inbound dan administrasi karyawan tanpa kehilangan fungsi lama.

Sudah ada dua program yang berjalan

Di dalam perusahaan sudah ada dua program otomasi yang berkembang ke arah berbeda.

Yang pertama adalah program pengelolaan cuti berbasis SMS yang lebih dahulu dibuat oleh pendahulu saya. Layanan ini menghitung jatah cuti setiap karyawan, mengirim pesan pengingat penggunaan cuti, lalu menafsirkan permohonan yang masuk lewat SMS hingga proses persetujuan atau penolakan. Web, backend, DB, dan ponsel Android untuk operasional sudah bergerak sebagai satu alur.

Yang lain adalah otomasi pengumpulan data publik dan penjualan yang terus saya kembangkan. Strukturnya mengumpulkan fasilitas dan informasi kontak, lalu menghubungkannya ke outbound Vox untuk diteruskan menjadi aktivitas penjualan yang nyata.

Awalnya saya mengira memindahkan kedua proyek ke satu repository sudah cukup untuk menyatukannya. Namun setelah memikirkan fitur yang ingin ditambahkan ke depan, sekadar menggabungkan folder jelas tidak cukup.

• layanan inbound yang tersambung dengan outbound yang sudah ada
• alur untuk menerima permintaan karyawan dan meneruskannya ke pekerjaan administrasi
• fungsi untuk membuat dan mengirim surat keterangan kerja secara otomatis
• fungsi untuk membagi hak akses berdasarkan data karyawan, kontrak, dan lokasi kerja
• layar operasional untuk melihat kegagalan, persetujuan, pemrosesan ulang, dan audit di satu tempat

Sejak itu pertanyaannya berubah dari “bagaimana cara menggabungkan dua codebase ini?” menjadi “di mana pekerjaan yang terus bertambah ini harus ditempatkan?”

Saya memutuskan untuk tidak membuang program lama

Saat melihat program cuti berbasis SMS itu, saya sangat ingin membuatnya ulang. Saya melihat struktur lama dan konfigurasi sementara, serta banyak bagian yang ingin saya desain kembali dengan standar sekarang. Rasanya akan lebih rapi jika hanya mengambil requirement lalu memindahkannya ke kode baru.

Namun semakin banyak materi yang saya periksa, semakin jelas bahwa program itu menyimpan hal-hal yang lebih penting daripada kodenya.

• hasil perhitungan cuti yang benar-benar ditampilkan kepada karyawan
• cara menghitung cuti berdasarkan tanggal mulai bekerja
• siapa yang menerima pengingat penggunaan cuti dan kapan pesan dikirim
• aturan untuk menafsirkan permohonan SMS menjadi tanggal dan cuti setengah hari
• urutan permohonan, persetujuan, penolakan, dan SMS hasil
• cara ponsel Android untuk operasional mengirim dan menerima SMS
• layar serta penanganan pengecualian yang sudah digunakan operator

Jika semua ini diringkas menjadi beberapa dokumen lalu dibuat ulang dari awal, kode barunya mungkin bersih, tetapi hasil yang diterima pengguna lama bisa berubah. Saya tidak boleh menghapus alur vertikal yang sudah benar-benar diselesaikan pendahulu hanya karena selera desain saya sendiri.

Karena itu saya mengubah arah: pertama-tama mereproduksi layanan lama apa adanya, menyimpan layar dan hasil perhitungannya sebagai baseline regresi, lalu mengganti bagian yang bermasalah satu fungsi demi satu. Sistem baru tidak boleh dimulai dengan menghapus program lama. Ia harus membawa pekerjaan program lama ke dalam struktur yang lebih besar tanpa kehilangan hasil yang sudah diberikan.

Penjualan dan administrasi karyawan bukan aplikasi yang sama

Menggabungkan proyek ke satu tempat lalu menyatukan DB dan Runtime juga menimbulkan masalah lain.

Otomasi penjualan menangani data publik, kontak, target panggilan, dan hasil penjualan. Administrasi karyawan menangani informasi karyawan, penerbitan dokumen, cuti, persetujuan, dan pesan. Keduanya bisa terlihat bersama di layar operasional, tetapi sifat datanya, hak aksesnya, dan jangkauan dampak kegagalannya berbeda.

Saya tidak menginginkan struktur di mana migration DB penjualan menghambat deployment administrasi karyawan, atau gangguan layanan cuti ikut menghentikan pengumpulan data penjualan. Akun dan credential, queue, backup, serta rollback juga harus dipisahkan berdasarkan pekerjaan.

Pada akhirnya saya memutuskan repository tetap satu, tetapi penjualan dan administrasi karyawan dipisahkan menjadi aplikasi independen. Layar operasional memungkinkan kedua aplikasi dijelajahi dari satu tempat, tetapi tidak membaca DB secara langsung. Setiap backend bertanggung jawab atas data dan hak aksesnya sendiri.

Walaupun dari luar tampak seperti satu layar operasional terpadu, bagian dalamnya tidak harus menjadi satu layanan raksasa.

Dari outbound menuju inbound dan pekerjaan administrasi

Otomasi penjualan yang ada lebih dekat dengan alur outbound yang melakukan panggilan ke luar. Pada tanggal 15, saya juga lama memikirkan cara menambahkan inbound ke dalamnya.

Tidak semua permintaan harus ditangani di dalam sistem telepon hanya karena permintaan itu datang melalui panggilan. Panggilan dapat menjadi pintu masuk yang menerima permintaan lalu meneruskannya ke pekerjaan yang tepat. Ketika ada permintaan surat keterangan kerja, permintaan itu harus diteruskan ke verifikasi identitas dan proses penerbitan, lalu dokumen yang selesai harus melalui prosedur pengiriman terpisah. Permintaan yang sama dari Web atau mobile pada akhirnya juga harus bertemu di pekerjaan administrasi yang sama.

Itulah alasan saya memilih surat keterangan kerja sebagai titik awal. Fitur pertama ini dapat sekaligus menguji alur yang diperlukan otomasi operasional: menerima permintaan, memeriksa data dasar karyawan, membuat dokumen, menyetujui, mengirim, menangani kegagalan, dan melakukan audit.

Tujuannya bukan hanya membuat satu fitur dengan baik. Batas yang sama harus tetap dapat digunakan ketika pekerjaan administrasi karyawan lain ditambahkan kemudian.

Data induk tidak boleh dibuat ulang

Perusahaan sudah mengelola data karyawan, kontrak, dan penempatan lokasi kerja melalui sistem lain. Otomasi membutuhkan informasi itu, tetapi jika kami membuat satu lagi buku induk karyawan di pihak kami, nilai kedua sistem akan segera berbeda.

Sistem eksternal harus tetap memiliki data induk, sedangkan pihak kami cukup membacanya dan menyimpan snapshot yang telah diverifikasi. Fungsi untuk mengubah data induk harus dipisahkan dari fungsi yang menggunakan informasi tersebut untuk memproses kejadian administrasi.

Masalahnya, format file yang benar-benar dapat diunduh dan identifier karyawan yang stabil belum diketahui. Jika nomor yang terlihat di layar disebut sebagai nomor pegawai, atau fungsi unduh ditulis sebagai Excel tanpa pernah diperiksa, seluruh desain setelahnya akan berdiri di atas asumsi palsu.

Karena itu hal-hal yang belum saya ketahui tetap saya biarkan belum diputuskan. Hari itu saya memang menemukan banyak jawaban, tetapi saya juga terus memperbaiki kalimat agar tidak berpura-pura mengetahui hal yang belum diketahui.

Integrasi bukan sekadar menggabungkan folder

Pada tanggal 15, saya hampir tidak menulis kode. Saya terus merapikan nama proyek, batas aplikasi, kepemilikan data, urutan migrasi layanan lama, dan peran layar operasional.

Saya ingin menghormati program yang dibuat pendahulu tanpa membekukannya selamanya, sekaligus tidak mengurung otomasi penjualan yang saya buat di dalam strukturnya sekarang. Ia harus bisa berkembang dari outbound Vox yang ada menuju inbound, lalu menuju administrasi karyawan dan otomasi dokumen.

Memasukkan dua proyek ke folder yang sama itu mudah. Yang sulit adalah menentukan apa yang harus dipertahankan, apa yang harus dipisahkan, dan dari mana perluasan harus dimulai. Tanggal 15 adalah hari ketika saya mulai melihat dua otomasi yang berbeda itu kembali sebagai satu struktur operasional.