Software HR Multi Company: Cara Memilih Sistem yang Tepat untuk Banyak Entitas

Sebagian besar percakapan HR di organisasi multi-company biasanya dimulai dari dorongan yang sama: perusahaan membutuhkan satu sistem untuk seluruh entitas. Ketika percakapan ini mulai muncul, biasanya grup bisnis sudah merasakan tekanan di beberapa area. Satu entitas menjalankan payroll dengan cara yang berbeda dari entitas lain. Tim HR mulai mencocokkan laporan antarentitas secara manual. Seorang karyawan berpindah dari satu entitas ke entitas lain, lalu tiba-tiba muncul dua kali dalam laporan. Pada titik tertentu, seseorang mulai bertanya, “Apakah kita membutuhkan satu sistem HR untuk semua entitas?”

Dorongan tersebut tidak selalu salah. Dalam banyak kasus, jawabannya memang iya. Namun, dalam banyak kasus lainnya, jawaban yang lebih tepat bukan sekadar “satu sistem untuk semua”, melainkan keputusan yang lebih sadar tentang apa yang perlu disentralisasi, apa yang sebaiknya tetap lokal, dan apakah satu sistem benar-benar menjadi tujuan arsitektur yang paling tepat.

Multi-company HRIS, atau yang sering juga disebut multi-entity HRIS, adalah sistem HR yang dirancang untuk mengelola beberapa badan hukum di bawah kepemilikan yang sama melalui satu platform, sambil tetap menjaga data spesifik setiap entitas, konfigurasi payroll, pelaporan statutori, dan kontrol akses masing-masing entitas.

Definisi tersebut terdengar sederhana. Bagian yang lebih sulit adalah menentukan versi “mengelola” seperti apa yang sebenarnya dibutuhkan oleh grup perusahaan Anda. Sebab, pilihan arsitektur di balik kata tersebut tidak selalu sama untuk setiap grup.

Artikel ini membahas bagaimana mengambil keputusan tersebut. Kita akan melihat kapan setup HRIS saat ini mulai tidak mampu mengikuti kompleksitas multi-entitas, tiga pola arsitektur yang biasanya menjadi pilihan grup perusahaan, fitur apa yang benar-benar penting, mengapa generic feature checklist bukan titik awal yang tepat, dan kapan penggunaan sistem paralel sebenarnya masih dapat diterima.

Pembahasan ini sangat relevan bagi grup perusahaan yang beroperasi di Indonesia, di mana struktur holding company dan kompleksitas kewajiban statutori di tingkat PT membuat keputusan arsitektur menjadi lebih penting dibandingkan pasar dengan rezim yang lebih sederhana.

Multi-Entity Tidak Sama dengan Multi-Country

Sebelum masuk lebih jauh, ada satu perbedaan yang perlu diperjelas. Multi-entity HR membahas pengelolaan beberapa badan hukum di bawah kepemilikan yang sama, sering kali masih berada dalam satu negara. Sementara itu, multi-country HR membahas pengelolaan HR lintas negara, di mana aturan statutori berubah mengikuti batas negara.

Keduanya memang berkaitan, tetapi keputusan arsitekturnya tidak sama. Kami membahas isu multi-country dalam artikel Global vs Local HR Systems. Artikel ini berfokus pada multi-entity, terutama multi-entity dalam konteks Indonesia, di mana pola yang paling umum adalah beberapa entitas PT berada di bawah satu grup kepemilikan, bukan operasi bisnis yang tersebar di banyak negara.

Kedua isu ini bisa saling beririsan. Sebuah grup regional bisa saja menjadi multi-entity dan multi-country pada saat yang sama. Dalam kondisi seperti itu, kedua lensa arsitektur perlu digunakan. Namun, keduanya tetap cukup berbeda sehingga jika disamakan, keputusan yang diambil bisa tidak benar-benar sesuai untuk salah satu kondisi.

Ketika HRIS Saat Ini Mulai Kewalahan Menghadapi Kompleksitas Multi-Entity

Sebagian besar sistem HR dirancang dengan asumsi satu organisasi. Ketika entitas legal kedua ditambahkan, sistem biasanya masih bisa menyesuaikan melalui konfigurasi. Namun, ketika entitas ketiga dan keempat mulai masuk, gesekan operasional biasanya mulai terlihat.

Gesekan ini jarang muncul secara dramatis. Sering kali, orang tidak langsung menyadari bahwa masalahnya ada pada arsitektur sistem. Yang terjadi justru tim mulai membuat workaround di sekitarnya.

Sebuah spreadsheet dibuat untuk mencocokkan headcount antarentitas. Tim payroll mulai membuat pengecekan offline sendiri. Laporan harus ditinjau dua kali karena tidak ada yang benar-benar percaya lagi pada angka konsolidasi.

• Laporan headcount mulai tidak sinkron karena karyawan di shared services muncul dengan kode entitas yang berbeda di laporan yang berbeda.
• Proses payroll yang sebelumnya selesai dalam tiga hari kini membutuhkan lima hari karena rekonsiliasi antarentitas masih dilakukan secara manual.
• Pelaporan statutori harus dipantau secara terpisah karena setiap PT memiliki pelaporan BPJS dan PPh 21 masing-masing, sementara sistem tidak dirancang untuk menangani beberapa kalender statutori secara rapi.
• Proses compensation review berubah menjadi aktivitas copy-paste antar spreadsheet yang dibuat berdasarkan entitas.
• Karyawan baru yang bergabung melalui satu entitas, tetapi secara operasional melapor ke entitas lain, berada dalam area abu-abu yang tidak benar-benar dimiliki oleh siapa pun.

Masing-masing masalah tersebut mungkin tidak terlihat terlalu besar jika berdiri sendiri. Namun, jika muncul bersamaan, semuanya menjadi tanda bahwa sistem sudah mulai mencapai batas kemampuannya.

Dalam banyak kasus, pemicunya bukan entitas ke-10, melainkan entitas ketiga atau keempat. Grup dengan dua PT mungkin masih bisa menjalankan HRIS yang tidak terlalu memperhatikan struktur entitas selama beberapa waktu. Biasanya, mereka melakukannya dengan menganggap data dari salah satu entitas sebagai versi utama dan menerima upaya rekonsiliasi manual di entitas lainnya.

Namun, ketika entitas ketiga atau keempat mulai masuk, pendekatan tersebut sering menciptakan lebih banyak gesekan daripada efisiensi. Mengenali pemicu ini sebelum menjadi percakapan anggaran akan jauh lebih murah dibandingkan menyadarinya setelah masalah operasional sudah membesar.

Tiga Pola Arsitektur untuk HR Multi-Entity

Ketika sebuah grup memutuskan untuk menangani HR multi-entity secara arsitektural, bukan hanya secara operasional, pertanyaan berikutnya adalah: pola mana yang paling sesuai?

Sebagian besar grup biasanya akan memilih di antara tiga pola utama.

Satu Platform yang Entity-Aware

Satu instance HRIS digunakan untuk menampung seluruh entitas, dengan data karyawan, struktur organisasi, kebijakan, dan konfigurasi payroll yang ditandai berdasarkan entitas masing-masing.

• Kontrol akses dibatasi berdasarkan entitas. Artinya, admin HR untuk PT A hanya dapat melihat data PT A, dan tidak dapat mengakses data PT B.
• Laporan dapat difilter untuk satu entitas tertentu atau dikonsolidasikan ke level grup.
• Compliance dikelola secara terpusat, tetapi diterapkan per entitas melalui konfigurasi.
• Consolidated reporting sudah menjadi bagian bawaan sistem. Karena seluruh data sudah berada di dalam sistem yang sama, tampilan grup dapat dihasilkan melalui query, bukan perlu dibangun dari awal.

Platform Terpisah dengan Consolidated Reporting

Setiap entitas menjalankan instance HRIS masing-masing. Dalam beberapa kasus, semua entitas menggunakan vendor yang sama. Dalam kasus lain, setiap entitas bisa menggunakan vendor yang berbeda.

• Di atas sistem-sistem tersebut, terdapat reporting layer yang menarik data dari HRIS masing-masing entitas untuk membentuk tampilan di level grup.
• Setiap entitas memiliki otonomi operasional. Tim HR dapat mengonfigurasi platformnya sendiri, menjalankan siklus payroll masing-masing, dan mengelola compliance sesuai kebutuhan entitasnya.
• Grup melihat dashboard konsolidasi melalui reporting layer, bukan langsung dari HRIS itu sendiri.
• Secara default, compliance dikelola per entitas.
• Konsolidasi menjadi infrastruktur terpisah, dengan biaya implementasi dan kebutuhan maintenance yang juga berjalan secara terpisah.

Model Entitas Federated

Setiap entitas memiliki kebebasan untuk menentukan pilihan teknologi dan prosesnya sendiri, tetapi tetap berada dalam standar bersama yang ditetapkan di level grup.

• Holding company biasanya menstandarkan ekspektasi terkait governance dan reporting, sementara anak perusahaan tetap menjalankan operasional harian dengan cara yang berbeda.
• Konsolidasi terjadi di level governance, melalui standar bersama dan siklus review.
• Pola ini sering ditemukan pada konglomerasi dengan anak usaha yang memiliki model operasional sangat berbeda. Misalnya, satu holding yang memiliki lini manufaktur, layanan keuangan, dan properti, di mana memaksakan penyelarasan teknis ke dalam satu sistem belum tentu menjadi pilihan yang tepat.

Tidak ada satu pola yang secara mutlak lebih baik daripada yang lain. Setiap pola cocok untuk realitas operasional yang berbeda. Kesalahan yang sering terjadi adalah memilih pola pertama secara otomatis karena terdengar paling sederhana, lalu baru menyadari 18 bulan kemudian bahwa pola tersebut tidak sesuai dengan cara entitas-entitas di dalam grup benar-benar beroperasi.

Mengapa Struktur PT di Indonesia Mengubah Keputusan Arsitektur

Grup perusahaan di Indonesia menghadapi tekanan arsitektural yang sering tidak dibahas dalam artikel global tentang HR multi-entity. Alasannya bersifat struktural.

Struktur holding company di bawah hukum Indonesia biasanya melibatkan beberapa entitas PT yang beroperasi dengan independensi legal masing-masing. Setiap PT memiliki pelaporan BPJS Kesehatan dan BPJS Ketenagakerjaan sendiri. Setiap PT memiliki pelaporan PPh 21 sendiri. Setiap PT membayar THR dengan siklusnya sendiri, berdasarkan kalendernya sendiri, dan diatur oleh kontrak kerja masing-masing.

Jika satu PT beroperasi di Jakarta dan PT lainnya berada di Jawa Timur, aturan upah minimum regionalnya juga berbeda. Jika struktur kepemilikan melibatkan beberapa pemegang saham atau anggota keluarga, governance dapat melintasi entitas dengan cara yang tidak selalu terlihat jelas di struktur organisasi.

Platform HRIS yang berjalan rapi untuk satu PT bisa menjadi kurang praktis ketika digunakan untuk beberapa PT sekaligus. Sistem harus mampu menangani beberapa kalender statutori, identitas pelaporan yang terpisah, dan dalam beberapa kasus, hubungan perbankan yang berbeda. Semua ini bukan berarti mustahil dikonfigurasi. Namun, banyak platform HRIS yang dirancang di luar Asia Tenggara sering meremehkan kedalaman konfigurasi yang dibutuhkan.

Ada tekanan kedua yang sering lebih sulit terlihat. Banyak grup di Indonesia menjalankan shared services lintas entitas, termasuk finance, HR, IT, dan terkadang legal. Secara organisasi, satu tim dapat mendukung beberapa entitas. Namun secara legal, setiap karyawan tetap menjadi bagian dari satu PT tertentu.

Di sinilah banyak grup multi-entity mulai menyadari bahwa struktur organisasi dan struktur legal tidak selalu sama. Platform HRIS harus mampu memuat dua kenyataan sekaligus: legal employer seorang karyawan dan garis pelaporan operasionalnya, yang belum tentu berada di entitas yang sama.

Sistem yang dirancang untuk setup multi-entity sederhana biasanya memperlakukan kondisi ini sebagai edge case. Sistem yang memang dirancang untuk grup perusahaan akan memperlakukannya sebagai kebutuhan default.

Keputusan arsitektur yang dibuat tanpa mempertimbangkan tekanan ini mungkin terlihat masuk akal di atas kertas, tetapi dapat bermasalah saat dijalankan. Versi yang lebih luas dari argumen ini kami bahas dalam artikel tentang Global vs Local HR Systems, yang membahas tekanan arsitektur di tingkat negara. Versi multi-entity dalam konteks Indonesia adalah bagian yang sangat terkait dengan pembahasan tersebut.

 Pertanyaan tentang Master Employee Record

Ada satu pertanyaan yang jarang dibahas secara langsung dalam artikel tentang multi-entity HR, tetapi hampir selalu muncul dalam percakapan HR di tingkat grup: apa yang harus dilakukan sistem ketika seorang karyawan berpindah antarentitas, ketika seseorang duduk di board beberapa PT, atau ketika tim shared services bekerja untuk beberapa entitas sekaligus?

Jawabannya bergantung pada pola arsitektur yang digunakan. Itulah mengapa pertanyaan ini menjadi membingungkan ketika pola arsitekturnya tidak dibuat eksplisit sejak awal.

• Dalam setup satu platform yang entity-aware, master record adalah karyawan.
  Sistem menyimpan satu record untuk setiap orang, dengan riwayat pekerjaan yang menunjukkan entitas mana yang mempekerjakannya pada periode tertentu. Transfer antarentitas memperbarui status employment aktif tanpa membuat record baru. Seorang board member yang duduk di beberapa PT memiliki satu record dengan beberapa appointment.

  Secara operasional, ini adalah model yang paling rapi. Ini juga model yang sering diasumsikan sudah dimiliki oleh banyak grup, sampai mereka menemukan dalam proses transfer, promosi, atau payroll bahwa sistem ternyata memperlakukan satu karyawan sebagai dua orang yang berbeda.

• Dalam model platform terpisah, master record adalah record milik masing-masing entitas.
  Setiap platform menyimpan versinya sendiri tentang karyawan tersebut. Ketika karyawan berpindah, ia keluar dari satu sistem dan masuk ke sistem lain. Riwayatnya menjadi terpecah, kecuali reporting layer dapat menyatukannya kembali. Dalam praktiknya, banyak reporting layer tidak dapat melakukan ini dengan baik. Board member muncul di beberapa sistem dengan record terpisah. Karyawan shared services sering kali harus diduplikasi atau ditetapkan ke satu entitas utama berdasarkan kesepakatan internal.
• Dalam model federated, pertanyaan tentang master record bergantung pada standar grup.
  Sebagian grup menjadikan record di holding company sebagai pusat, lalu record entitas mengalir dari sana. Grup lain menjadikan record masing-masing entitas sebagai data utama, lalu laporan grup dibangun dengan menggabungkan data tersebut. Ini adalah keputusan governance, bukan hanya keputusan arsitektur.

Implikasinya jelas: jika grup Anda memiliki perpindahan karyawan antarentitas yang cukup aktif, struktur shared services, atau eksekutif yang duduk di beberapa board, pertanyaan tentang master record pasti akan muncul. Menentukannya sejak awal jauh lebih murah dibandingkan menemukannya di tengah siklus payroll.

Apa yang Sebenarnya Perlu Dievaluasi?

Sebagian besar artikel tentang software HR multi-company memberikan checklist fitur dengan 30 atau 40 item, lalu meminta Anda membandingkan vendor berdasarkan daftar tersebut. Di sini, kita akan mengambil pendekatan yang berbeda.

Checklist fitur yang disusun berdasarkan modul HR, seperti payroll, time and attendance, leave, performance, dan recruitment, justru sering membuat evaluasi vendor multi-entity terasa melelahkan. Lebih dari itu, checklist seperti ini juga dapat menghasilkan keputusan yang tidak bertahan dalam operasi sehari-hari.

Fitur yang benar-benar penting dalam multi-entity HRIS sebenarnya dapat dikelompokkan ke dalam tiga kategori yang berkaitan langsung dengan keputusan arsitektur, bukan modul HR. Tiga kategori tersebut adalah: arsitektur data, compliance dan reporting, serta proses dan governance.

Saat mengevaluasi vendor, gunakan pertanyaan di bawah ini dalam setiap kategori, bukan sekadar mencentang daftar fitur.

Arsitektur Data. Ajukan pertanyaan berikut:

• Di mana master employee record berada?
• Bagaimana data spesifik setiap entitas dipisahkan?
• Bagaimana kontrol akses dibatasi berdasarkan entitas?
• Apa yang terjadi ketika karyawan berpindah antarentitas?
• Apakah sistem mendukung satu record per karyawan dengan beberapa riwayat employment, atau sistem menduplikasi karyawan di berbagai entitas?
• Apakah role-based access dapat diatur agar administrator HR dari satu entitas hanya melihat data entitas tersebut dan tidak melihat data lainnya?
• Ketika karyawan berpindah, apakah riwayatnya ikut berpindah atau justru terpecah?

Kategori ini menentukan apakah sistem benar-benar mampu menampung kompleksitas operasional grup, atau apakah HR pada akhirnya harus mengelolanya secara manual. Ketika lapisan ini lemah, HR biasanya akan mengompensasinya secara operasional. Tim mulai membuat naming convention, proses rekonsiliasi manual, dan logika spreadsheet tidak resmi untuk menutup celah yang tidak bisa ditangani sistem secara rapi.

Compliance dan Reporting. Ajukan pertanyaan berikut:

• Apakah konfigurasi statutori per entitas merupakan konsep bawaan sistem atau hanya workaround?
• Apakah consolidated reporting memungkinkan drill-down berdasarkan entitas, lokasi, fungsi, dan peran?
• Apakah audit trail dapat dipisahkan berdasarkan legal entity untuk kebutuhan compliance review?
• Apakah penyimpanan dokumen mengikuti governance di tingkat entitas?
• Apakah sistem dapat menangani beberapa kalender statutori secara rapi, misalnya ketika satu PT menjalankan THR pada siklus yang berbeda dari PT lain, atau ketika satu entitas sedang ditutup untuk audit sementara entitas lain sedang berada di tengah proses payroll?

Kategori ini biasanya menjadi area di mana organisasi mengetahui apakah sistem benar-benar memahami operasi multi-entity, atau apakah HR akan menghabiskan tiga tahun berikutnya membangun workaround di sekitarnya.

Proses dan Governance.  Ajukan pertanyaan berikut:

• Apakah workflow routing mengikuti hierarki entitas, sehingga approval yang seharusnya tetap berada di dalam satu entitas tidak secara tidak sengaja dikirim ke approver tingkat grup?
• Apakah policy management memungkinkan adanya kebijakan bersama di tingkat grup sekaligus pengecualian spesifik per entitas, tanpa harus memecahnya menjadi dokumen yang sepenuhnya terpisah?
• Apakah approval chain dapat dikonfigurasi per entitas?
• Apakah sistem membuat model governance menjadi mudah dipahami, misalnya keputusan mana yang berada di tingkat grup, mana yang berada di tingkat entitas, dan mana yang bersifat shared?

Kategori ini menentukan apakah sistem mendukung cara grup mengambil keputusan, atau justru menghambatnya.

Pertanyaan yang menguji apakah sistem vendor benar-benar sesuai untuk grup multi-entity biasanya berada lebih dalam daripada demo standar. Worksheet Trade-Off Questions kami berisi versi evaluasi yang lebih operasional dan mendetail.

Kapan Sistem Paralel Sebenarnya Masih Baik-Baik Saja

Bagi sebagian besar grup multi-entity, konsolidasi adalah keputusan yang tepat. Namun, ada tiga pengecualian ketika sistem paralel justru bisa lebih sesuai.

Pertama, entitas yang baru diakuisisi dan belum terintegrasi secara operasional biasanya lebih baik tetap menggunakan sistem yang sudah ada selama satu atau dua tahun, sambil rencana integrasi dibentuk. Memaksakan konsolidasi platform pada akuisisi yang belum sepenuhnya dipahami dapat mengganggu operasi entitas tersebut sekaligus logika bisnis dari akuisisi itu sendiri.

Dalam praktiknya, di sinilah banyak integrasi pascaakuisisi menjadi jauh lebih menyakitkan daripada yang seharusnya. Organisasi masih berusaha memahami cara entitas baru beroperasi, sambil pada saat yang sama mencoba menstandarkan sistem yang belum sepenuhnya dipahami oleh siapa pun.

Kedua, entitas dengan operating model yang sangat berbeda, misalnya sebuah PT manufaktur dan sebuah PT fintech dalam grup yang sama, kadang lebih cocok menggunakan platform HR yang berbeda karena kebutuhan sistemnya juga berbeda. Dalam kondisi seperti ini, model federated dengan standar bersama tetapi platform terpisah bisa lebih efektif dibandingkan memaksakan penyatuan.

Ketiga, grup kecil dengan kompleksitas rendah mungkin belum membutuhkan biaya dan konfigurasi untuk tooling multi-entity. Dua PT dengan masing-masing 30 karyawan, yang beroperasi di industri serupa dengan struktur kompensasi yang mirip, sering kali masih dapat menggunakan dua instance HRIS sederhana secara paralel dengan rekonsiliasi manual yang lebih murah dibandingkan membeli dan mengonfigurasi platform multi-entity.

Ujian paling jujur adalah pertanyaan ini: apakah konsolidasi benar-benar mengurangi gesekan dalam grup ini, atau justru menambah lapisan kompleksitas arsitektur baru yang belum siap dikelola oleh grup?

Jika jawabannya yang kedua, sistem paralel dengan governance yang disiplin bisa menjadi arsitektur yang tepat.

Cara Mengambil Keputusan

Keputusan ini jarang benar-benar ditentukan oleh fitur atau reputasi vendor. Biasanya, keputusan ini ditentukan oleh tiga pertanyaan operasional tentang grup perusahaan.

Berapa banyak entitas yang dijalankan oleh grup, dan seberapa terintegrasi operasinya? Dua PT yang benar-benar terpisah akan beroperasi berbeda dari lima entitas yang berbagi tim finance dan tim HR.

Seperti apa perpindahan lintas entitas di dalam grup? Apakah karyawan sering berpindah antarentitas? Apakah eksekutif duduk di beberapa board? Apakah shared services umum digunakan? Atau apakah setiap entitas beroperasi seperti bisnis yang relatif independen?

Seperti apa pendekatan governance grup? Apakah holding company mendorong standar yang sama lintas entitas? Atau setiap entitas beroperasi dengan otonomi yang cukup besar, sementara holding hanya melakukan agregasi di level tinggi?

Pertanyaan-pertanyaan ini biasanya memperlihatkan apakah grup sebenarnya sudah terintegrasi secara operasional, meskipun sistemnya belum. Jawabannya akan menunjukkan pola arsitektur mana yang paling sesuai. Dari situ, barulah organisasi dapat menentukan fitur apa yang perlu dievaluasi.

Sistem satu platform yang entity-aware kemungkinan besar akan gagal dalam uji operasional jika dievaluasi oleh grup yang sebenarnya membutuhkan model federated. Sebaliknya, model federated yang dipaksakan pada grup dengan perpindahan lintas entitas yang tinggi justru akan mengulang pekerjaan rekonsiliasi manual yang sebenarnya ingin dihindari.

Artikel anchor kami tentang cara memilih HRIS yang tepat di Indonesia membahas framework kesesuaian yang lebih luas. Artikel kami tentang HRIS vs Payroll Software membahas keputusan arsitektur paralel di tingkat sistem. Pertanyaan multi-company berada di dalam kedua pembahasan tersebut, dan jawabannya akan lebih jelas ketika keduanya dipertimbangkan bersama.

Penutup

Sebagian besar grup yang mengoperasikan beberapa unit bisnis berasumsi bahwa mereka membutuhkan satu platform untuk seluruh entitas. Secara umum, asumsi itu benar. Mereka memang membutuhkan arsitektur HR yang dirancang untuk kompleksitas multi-entity.

Namun, keputusan yang perlu dibuat dengan hati-hati bukan hanya apakah perusahaan perlu berinvestasi. Keputusan yang lebih penting adalah investasi seperti apa yang perlu dipilih.

Ketika sebuah grup sudah mencapai tingkat kompleksitas operasional tertentu, pertanyaannya bukan lagi apakah arsitektur HR penting. Pertanyaannya adalah pola arsitektur mana yang akan dipilih, apa yang perlu disentralisasi, apa yang perlu dilokalkan, dan bagaimana menjaga agar sistem tetap selaras dengan cara grup benar-benar beroperasi saat organisasi berubah.

Hanya ketika hal ini sudah jelas, arsitektur dapat membantu grup beroperasi dengan lebih rapi, bukan diam-diam menciptakan gesekan di bawah permukaan.