Struktur Organisasi adalah Skema Sistem

Ringkasan Eksekutif

Desain perangkat lunak paling berdampak yang pernah dilakukan oleh sebagian besar eksekutif adalah struktur organisasi, dan hampir tidak ada dari mereka yang menyadarinya sebagai desain perangkat lunak.

Sebuah model operasi sering kali disepakati di ruangan yang tidak dihadiri oleh orang-orang sistem (TI), digambar sebagai kotak-kotak dengan garis penghubung, lalu diserahkan sebagai konteks belaka untuk pekerjaan konfigurasi yang sebenarnya. Itu bukanlah konteks. Itu adalah spesifikasi. Dan bagian-bagian yang sebenarnya tidak pernah diputuskan secara matang tidak akan muncul dengan sendirinya di awal. Hal itu akan muncul kemudian, sebagai cacat (defect).

Signal: Burnout sebagai Routing Error

Pertimbangkan apa yang dilakukan load balancer (penyeimbang beban) ketika dua dari tiga node (simpul) tidak sehat. Ia tidak akan menjalankan layanan pada sepertiga kapasitas dan menolak sisa beban dengan sopan. Ia merutekan semuanya ke simpul yang merespons — dan simpul tersebut, yang kini memikul tiga kali lipat beban desain aslinya, gagal dengan cara yang terlihat seolah-olah itu adalah kelemahannya sendiri, bukan kelemahan sistem.

Sistem manusia melakukan perutean dengan cara yang sama, dengan satu perbedaan kejam: server tidak merasa sungkan. Manusia menyerap limpahan beban karena menolaknya berarti secara nyata mengecewakan bisnis, sehingga perutean beban ini tidak terlihat sampai ada yang mengundurkan diri.

Data Gartner menunjukkan bahwa ini hampir menjadi kondisi normal. Dalam survei Februari 2023, hanya 9% fungsi SDM (HR) yang sangat efisien dan sangat selaras dengan kebutuhan bisnis. Sementara itu, 71% melaporkan bahwa burnout lebih menantang daripada sebelum pandemi, dan 55% mengatakan mereka menerima lebih banyak permintaan di berbagai topik yang lebih luas. [Source: Gartner, survei Februari 2023 terhadap 217 pemimpin SDM]

Peningkatan volume permintaan yang bertemu dengan struktur yang belum selesai hanya menghasilkan satu outcome. Burnout dalam fungsi yang dirancang dengan baik jarang merupakan sinyal tentang kelemahan individu tersebut. Ini adalah sinyal ke arah mana beban kerja itu bermuara.

Akar Masalah: Implementasi Tidak Tuntas (partial implementation)

Kasus kegagalan semacam ini cukup banyak didokumentasikan pada kasus adopsi “Model Ulrich” di SDM—yang membagi fungsi menjadi mitra bisnis (business partners), pusat keunggulan (centers of excellence/CoE), dan layanan umum/bersama (shared services).

Desain ini mengasumsikan ketiga kaki tersebut benar-benar mampu melakukan bagiannya. Yang justru sering didapatkan organisasi adalah kematangan yang tidak merata: HRBP yang handal namun duduk di atas fungsi shared services yang belum mampu akan mengambil alih pekerjaan operasional dan mengambil alih fungsi CoE yang belum menghasilkan standar yang seharusnya diterapkan oleh para mitra.

Pekerjaan tidak berhenti begitu saja menunggu kaki yang belum matang menjadi matang. Pekerjaan cover-up itu mengalir kepada siapa saja yang bisa mengisi. Pola ini konsisten dilaporkan para praktisi: mitra bisnis menyerap beban transaksional karena shared services belum sanggup memikulnya, mengimprovisasi kebijakan yang tidak pernah ditulis, dan menyelipkan pekerjaan strategis di sisa waktu yang ada. Sebagian kalangan menyebutnya “mitra bisnis sebagai tukang pos”—“business partner as a postman”.

Ketika organisasi secara langsung mengadopsi “struktur” tanpa membangun outcome-nya, mereka kehilangan control plane (tata kelola perusahaan) dan runtime (eksekusi garis depan). Pekerjaan yang tidak memiliki pemilik tidak akan masuk antrian yang seharusnya. Pekerjaan itu akan mencari komponen/agen terdekat yang bisa menyelesaikannya.

Membaca Struktur Organisasi sebagai Skema

Setiap operating model adalah spesifikasi yang pada akhirnya harus diimplementasikan oleh seseorang ke dalam perangkat lunak perusahaan. Struktur organisasi (orgz chart) adalah versi informalnya. Sistem (perangkat lunak) adalah tempat di mana perilaku koboi itu membawa potensi biaya yang nyata.

1. Decision Right adalah Model Otorisasi

Kerangka tata kelola sering kali hanya dianggap sebagai pemanis presentasi (slideware) bagi siapa pun yang berlatar belakang teknik. Seharusnya tidak demikian. Ketika sebuah model menentukan siapa yang menetapkan kebijakan perusahaan, siapa yang mengadaptasinya secara lokal, dan siapa yang akan melakukan eksekusi, model tersebut sedang menentukan peran, cakupan izin, dan rantai persetujuan (approval chains). Itu adalah model otorisasi yang ditulis dalam bentuk narasi.

Tim yang tidak dapat mengartikulasikan hak keputusannya tidak akan dapat mengkonfigurasi sistem apa pun. Apa yang dihasilkannya adalah konfigurasi default, yang kemudian menjadi tata kelola de facto—diputuskan oleh siapa pun yang kebetulan mengisi formulir aplikasi, dan tidak pernah disahkan oleh siapa pun.

2. Katalog Layanan adalah Kontrak Antarmuka/Interface

Hilangkan jargon HR/bisnis dari fungsi shared services dan yang tersisa adalah manajemen layanan TI standar: katalog layanan, resolusi bertingkat, komitmen respons, dan aturan eskalasi.

Katalog menyatakan apa yang menjadi kewajiban setiap kaki kepada yang lain dan apa yang berhak diharapkan dari sebuah permintaan layanan. Tanpa hal itu, batasan akan dinegosiasikan kasus demi kasus. Tidak ada kontrak yang bisa dijadikan alasan kuat saat menolak pekerjaan, yang justru menjadi alasan mengapa kaki yang kuat pada akhirnya menyerap segalanya.

3. Siklus Hidup Karyawan adalah State Machine

Kehadiran, onboarding, promosi, dan keluar (exit) sering kali diperlakukan sekadar sebagai dokumen-dokumen dalam folder. Alih-alih demikian, modelkan hal-hal tersebut sebagai transisi atas suatu entitas karyawan, di mana masing-masing memiliki aktor, timestamp, persetujuan, dan status yang dihasilkan.

Bila Anda melakukannya, jejak audit (audit trail) menjadi log transisi. Dokumen prosedur menjadi konfigurasi dengan kontrol versi (versioned). Offboarding menjadi transisi terminal dengan prasyarat yang wajib dipenuhi, bukan sekadar daftar periksa (checklist) yang mengandalkan ingatan seseorang.

Buku Panduan Eksekutif (The Executive Playbook)

Jika kaki Anda yang kuat diam-diam membayar beban untuk dua kaki lainnya yang belum siap, cara untuk menghentikan beban routing failure dan memperbaiki sistem Anda:

Tulis katalog layanan sebelum membeli perangkat lunak. Sistem yang tidak matang adalah gejala yang paling terlihat, sehingga seringkali perangkat lunak menjadi hal pertama yang dibeli. Berhenti. Katalog dan penetapan hak keputusan adalah prasyarat dari pengadaan. Buat daftar setiap layanan yang diberikan oleh fungsi tersebut, sebutkan kaki yang seharusnya memilikinya, dan tandai di mana layanan itu sebenarnya diberikan saat ini. Dokumen tunggal itu akan mengungkap perutean yang salah dan mengukur kesenjangan yang ada.
Urutkan kesiapan fungsi dengan perencanaan yang matang. Sebuah struktur yang diumumkan begitu saja pada hari Senin bukanlah struktur yang langsung terwujud nyata. Jangan mengumumkan tiga pilar lalu membiarkan pilar yang kuat secara organik menutupi kelemahan pilar lainnya. Deklarasikan secara gamblang apa yang menjadi tanggung jawab setiap pilar, jujurlah tentang fungsi mana yang belum dapat memenuhinya, dan secara eksplisit tahan pekerjaan itu secara terpusat atau eksternal untuk sementara waktu—dengan batas waktu (end date) yang jelas.
Ukur ke mana waktu sebenarnya dihabiskan. Jika Anda ingin tahu apakah kaki yang kuat menyerap pekerjaan kaki yang lain, ukur pembagian waktunya antara pekerjaan strategis dan transaksional. Periksa kesesuaian jawaban tersebut dengan data jumlah tiket kerja menurut Job Description. Kesenjangan antara peran yang dirancang dan peran yang senyatanya dijalani adalah inti dari diagnosis masalah ini.
Akui teknologi sebagai kompetensi inti, bukan hanya sebagai infrastruktur pendukung. Sistem adalah produk dari fungsi bisnis itu sendiri, di mana TI bertindak sebagai penyedia platform. Jika Anda membaliknya, TI pada akhirnya akan membuat keputusan desain layanan secara default, melalui pilihan-pilihan konfigurasi di sistem yang tidak pernah disadari oleh siapa pun sebagai sebuah keputusan bisnis strategis.

Gagasan dasar untuk memisahkan kemitraan strategis dari desain spesialis dan eksekusi transaksional adalah hal yang masuk akal. Namun, struktur organisasi hanyalah sebuah skema—sebuah janji tentang apa yang akan diminta dari sistem kelak. Jika Anda sekadar menggambar kotak-kotaknya tanpa mematangkan apa yang ada di dalamnya, Anda belum mengimplementasikan sebuah model operasi. Anda hanya menulis sebuah spesifikasi dan membebankan seluruh tagihannya kepada kaki yang paling kuat.