E06 — PIC & Akuntabilitas

Posisi E06. Strategi dapat mempunyai sasaran, KPI, target, inisiatif, tonggak, dan kegiatan yang baik, tetapi tetap gagal bila tidak jelas siapa yang harus memastikan hasil dan siapa yang harus menjalankan pekerjaan. DHASTRAM memisahkan Penanggung Jawab dari PIC agar akuntabilitas tidak kabur.

1. Penanggung Jawab dan PIC Menjawab Dua Pertanyaan Berbeda

Penanggung Jawab mempunyai akuntabilitas utama untuk memastikan suatu hasil, objek, atau keputusan dikelola sebagaimana mestinya. PIC bertanggung jawab menjalankan pekerjaan atau mengoordinasikan tindakan tertentu.

Peran	Pertanyaan	Fokus
Penanggung Jawab	Siapa yang harus memastikan hasil ini dikelola dan dapat menjelaskan keadaannya?	Hasil, keputusan, tindak lanjut, eskalasi.
PIC	Siapa yang menjalankan pekerjaan konkret?	Pelaksanaan, koordinasi, jadwal, keluaran.

Contoh WMS. Kepala operasi dapat menjadi Penanggung Jawab manfaat peningkatan akurasi dan produktivitas gudang, sedangkan project manager menjadi PIC implementasi. Project manager menjalankan proyek; kepala operasi memastikan perubahan menghasilkan manfaat operasional.

2. Penanggung Jawab ≠ PIC

Satu orang dapat memegang kedua peran pada kasus sederhana, tetapi sistem tidak boleh menganggap keduanya selalu sama. Pemisahan menjadi penting ketika hasil bergantung pada banyak fungsi atau ketika PIC tidak mempunyai kewenangan atas keseluruhan hasil.

Contoh hotel. IT menjadi PIC implementasi CRM. Direktur komersial menjadi Penanggung Jawab sasaran peningkatan retensi pelanggan. Menjadikan IT bertanggung jawab atas retensi hanya karena mengimplementasikan sistem akan mencampurkan pelaksanaan teknologi dengan akuntabilitas bisnis.

3. Akuntabilitas Bukan Mekanisme Mencari Kesalahan

Akuntabilitas berarti kewajiban untuk memastikan, mengetahui keadaan, menjelaskan, mengambil keputusan, meminta tindakan, dan mengeskalasi bila diperlukan. Tujuannya bukan mencari seseorang untuk disalahkan ketika hasil tidak sesuai rencana.

Contoh. OTIF turun karena kombinasi stock availability, picking, dan transportasi. Penanggung Jawab tidak otomatis “bersalah”. Ia bertanggung jawab memastikan masalah dipahami, fungsi terkait dilibatkan, keputusan diambil, dan tindak lanjut dipantau.

Prinsip penting. Budaya menyalahkan membuat orang menyembunyikan masalah. Akuntabilitas yang sehat justru membuat masalah lebih cepat terlihat dan ditangani.

4. Akuntabilitas Perlu Ditempatkan pada Objek yang Tepat

Dalam DHASTRAM, akuntabilitas dapat diperlukan pada berbagai objek: Sasaran Strategis, KPI, Inisiatif, Temuan, Tindakan Perbaikan, Asumsi Strategis, maupun bukti tertentu. Namun bentuk tanggung jawabnya tidak selalu sama.

Objek	Fokus Penanggung Jawab
Sasaran Strategis	Memastikan kondisi strategis ditinjau dan tindakan lintas fungsi berlangsung.
KPI	Memastikan definisi, data, interpretasi, dan tindak lanjut memadai.
Inisiatif	Memastikan relevansi dan manfaat, bukan hanya proyek selesai.
Temuan	Memastikan temuan dinilai dan ditindaklanjuti.
Tindakan Perbaikan	Memastikan tindakan diselesaikan dan efektivitasnya diuji.
Asumsi	Memastikan asumsi penting diperiksa ketika bukti berubah.

5. Satu Penanggung Jawab Utama Mengurangi Ambiguitas

Sasaran lintas fungsi dapat mempunyai banyak kontributor, tetapi terlalu banyak co-owner sering membuat pertanyaan “siapa yang memastikan?” tidak terjawab. Satu Penanggung Jawab utama membantu menjaga kejelasan, sementara fungsi lain tetap mempunyai kontribusi yang eksplisit.

Contoh distribusi. Sasaran “meningkatkan keandalan pemenuhan pesanan” melibatkan Sales, Purchasing, Warehouse, Transport, dan IT. Tidak semua harus menjadi co-owner. Satu pimpinan dapat menjadi Penanggung Jawab, sementara kontribusi masing-masing fungsi dinyatakan melalui KPI, proses, inisiatif, atau kegiatan terkait.

6. Penanggung Jawab Membutuhkan Wewenang yang Memadai

Akuntabilitas tanpa kewenangan akan menjadi tanggung jawab semu. Penanggung Jawab perlu mempunyai akses terhadap informasi, forum keputusan, sumber daya, atau jalur eskalasi yang cukup untuk menjalankan perannya.

Contoh rumah sakit. Seorang manajer diminta bertanggung jawab atas waktu tunggu lintas unit tetapi tidak dapat memengaruhi jadwal dokter, kapasitas pemeriksaan, atau alokasi petugas. Akuntabilitasnya perlu disertai hak keputusan atau mekanisme eskalasi kepada pihak yang memiliki kewenangan.

7. Hak Keputusan Perlu Dijelaskan

Tidak semua Penanggung Jawab boleh mengambil semua keputusan. Karena itu perlu jelas keputusan mana yang dapat diambil sendiri, mana yang membutuhkan persetujuan, dan mana yang harus dibawa ke forum yang lebih tinggi.

Contoh inisiatif. Project lead dapat mengatur urutan kegiatan, tetapi perubahan ruang lingkup besar atau tambahan investasi mungkin memerlukan sponsor. Sponsor dapat menyetujui perubahan tertentu, sedangkan penghentian program mungkin memerlukan direksi.

8. Eskalasi Adalah Bagian dari Akuntabilitas, Bukan Kegagalan

Eskalasi diperlukan ketika masalah melampaui kewenangan, toleransi, waktu, atau risiko yang dapat ditangani pada level saat ini. Kondisi kritis, pelanggaran terkait Dharma, asumsi yang tidak lagi berlaku, tindakan perbaikan yang terlambat, atau risiko strategis perlu mempunyai jalur eskalasi.

Masalah→Nilai Dampak & Wewenang→TanganiatauEskalasi→Keputusan

Contoh keamanan pangan. PIC menemukan penyimpangan suhu yang berpotensi material. Ia tidak perlu menunggu rapat bulanan. Jalur eskalasi harus memungkinkan keputusan cepat terkait isolasi produk, investigasi, dan tindakan lanjutan.

9. Kriteria Eskalasi Sebaiknya Ditetapkan Sebelum Krisis

Jika aturan eskalasi baru diperdebatkan ketika masalah terjadi, organisasi kehilangan waktu. Kriteria dapat mempertimbangkan tingkat risiko, pelanggaran Rambu Dharma, besarnya deviasi, keterlambatan, dampak lintas fungsi, kebutuhan sumber daya, atau keputusan di luar kewenangan.

Contoh proyek. Keterlambatan dua hari pada kegiatan nonkritis mungkin cukup ditangani PIC. Keterlambatan dua hari pada izin yang menentukan tanggal pembukaan fasilitas dapat langsung memerlukan eskalasi karena dampaknya terhadap Tonggak Pencapaian dan komitmen pelanggan.

10. Akuntabilitas Lintas Fungsi Tidak Berarti Semua Orang Menjadi Pemilik

Strategi sering melintasi struktur organisasi. Satu sasaran dapat membutuhkan kontribusi beberapa unit, tetapi tetap memiliki satu Penanggung Jawab utama yang memastikan hubungan antarkontribusi berjalan.

Contoh hotel. Pengalaman tamu melibatkan Reservation, Front Office, Housekeeping, Engineering, F&B, dan IT. Satu Penanggung Jawab dapat menjaga hasil secara keseluruhan, sedangkan masing-masing fungsi mempunyai kontribusi dan PIC pada pekerjaan yang relevan.

11. Kontributor Perlu Mengetahui Kontribusi yang Diharapkan

Menyebut unit sebagai “supporting department” belum cukup. Kontribusi sebaiknya diterjemahkan menjadi hasil, KPI, Tonggak, atau Kegiatan yang dapat dipahami dan ditelusuri.

Contoh. Untuk sasaran meningkatkan OTIF, Purchasing berkontribusi pada ketersediaan barang, Warehouse pada picking accuracy dan readiness, Transport pada ketepatan pengiriman, dan IT pada keandalan sistem. Hubungan ini lebih berguna daripada sekadar mencantumkan empat unit sebagai co-owner.

12. Bukti Akuntabilitas Terlihat dari Tindakan dan Keputusan

Akuntabilitas bukan sekadar nama yang tercantum pada sebuah record. Catatan keputusan, hasil tinjauan, persetujuan, tindak lanjut, eskalasi, dan tinjauan efektivitas menunjukkan bahwa peran benar-benar dijalankan.

Contoh. Sebuah KPI merah selama tiga bulan dengan nama owner yang jelas tetapi tanpa catatan keputusan atau tindak lanjut menunjukkan bahwa pencantuman owner belum menghasilkan akuntabilitas yang nyata.

13. Pergantian Orang Tidak Boleh Menghilangkan Akuntabilitas

Akuntabilitas perlu terhubung dengan peran organisasi dan riwayat penugasan. Ketika pejabat atau PIC berganti, sistem harus dapat menunjukkan siapa yang bertanggung jawab pada periode tertentu dan bagaimana serah terima dilakukan.

Contoh. Project lead pindah unit di tengah implementasi. Rekaman DHASTRAM perlu menyimpan PIC lama, tanggal pergantian, PIC baru, status pekerjaan, isu terbuka, dan bukti serah terima agar tanggung jawab tidak terputus.

14. PIC Perlu Mempunyai Ruang untuk Melaporkan Hambatan

PIC tidak seharusnya hanya diminta melaporkan “selesai atau belum”. Ia perlu dapat menyampaikan dependency, kebutuhan keputusan, risiko, atau keterbatasan yang membuat pekerjaan tidak dapat dilanjutkan.

Contoh. PIC integrasi belum dapat menyelesaikan UAT karena API vendor belum stabil. Status yang berguna bukan sekadar “terlambat”, tetapi juga hambatan, pihak yang perlu bertindak, dampak terhadap Tonggak, dan apakah eskalasi diperlukan.

15. Akuntabilitas dalam Perangkat Lunak DHASTRAM

Perangkat lunak perlu memisahkan peran Penanggung Jawab, PIC, kontributor, pemberi persetujuan, dan pihak eskalasi agar sistem tidak menganggap semua orang memiliki tanggung jawab yang sama.

Penanggung JawabSiapa yang akuntabel terhadap hasil/objek.

PICSiapa yang menjalankan pekerjaan.

KontributorUnit/orang yang memberi kontribusi.

WewenangKeputusan yang dapat diambil pada level tersebut.

EskalasiKepada siapa dan kapan masalah dinaikkan.

BuktiKeputusan, approval, catatan tindak lanjut.

PeriodeMasa berlaku penugasan.

Serah TerimaRiwayat pergantian orang/peran.

NotifikasiPengingat untuk kondisi yang membutuhkan tindakan.

16. AI Membantu, tetapi Tidak Memegang Akuntabilitas

AI dapat menganalisis data, menemukan keterlambatan, menyarankan tindakan, merangkum risiko, atau menunjukkan siapa yang biasanya menangani jenis masalah tertentu. Namun AI tidak menjadi Penanggung Jawab dan tidak menggantikan pengambil keputusan manusia.

Contoh. AI menyarankan menghentikan sebuah inisiatif karena manfaat diperkirakan rendah. Rekomendasi tersebut dapat menjadi bahan tinjauan, tetapi keputusan penghentian harus dibuat oleh manusia yang mempunyai wewenang dan mempertimbangkan konteks yang lebih luas.

Prinsip AI. Rekomendasi AI ≠ keputusan. AI ≠ Penanggung Jawab. Akuntabilitas atas keputusan strategis tetap berada pada manusia.

17. Contoh Utuh dan Kesalahan yang Perlu Dihindari

Konteks	Penanggung Jawab	PIC / Kontributor	Fokus
Distribusi — WMS	Pimpinan operasi	Project lead, IT, key user, vendor	Manfaat operasional vs pelaksanaan implementasi.
Hotel — MICE	Pimpinan komersial/operasional terkait	Sales, banquet, engineering, IT	Keandalan dan nilai MICE vs pekerjaan tiap fungsi.
Rumah sakit — akses layanan	Pimpinan layanan terkait	Front office, klinik, IT, penjadwalan	Hasil lintas fungsi vs pelaksanaan tindakan.

Kesalahan yang perlu dihindari adalah menyamakan Penanggung Jawab dan PIC; memberi terlalu banyak co-owner; memakai akuntabilitas untuk menyalahkan; menunjuk Penanggung Jawab tanpa kewenangan; tidak mempunyai jalur eskalasi; dan memperlakukan rekomendasi AI sebagai keputusan final.

18. Kesimpulan dan Pertanyaan untuk Pimpinan

Akuntabilitas membuat strategi mempunyai manusia yang benar-benar memastikan hasil, sementara PIC memastikan pekerjaan konkret dilakukan. Keduanya harus didukung oleh wewenang, informasi, jalur eskalasi, dan bukti keputusan yang memadai.

Siapa yang benar-benar akuntabel terhadap hasil ini?
Siapa PIC yang menjalankan pekerjaan?
Apakah Penanggung Jawab mempunyai informasi dan wewenang yang cukup?
Kontributor lintas fungsi apa yang diperlukan?
Apakah kontribusi masing-masing jelas?
Keputusan apa yang dapat dibuat sendiri dan apa yang membutuhkan persetujuan?
Kapan masalah harus dieskalasikan dan kepada siapa?
Apakah keputusan dan tindak lanjut terdokumentasi?
Jika orang berganti, apakah riwayat dan serah terima tetap terjaga?
Apakah AI hanya membantu analisis, sementara keputusan dan akuntabilitas tetap pada manusia?

Inti pembelajaran. Penanggung Jawab ≠ PIC. Akuntabilitas ≠ menyalahkan. Rekomendasi AI ≠ keputusan manusia. Akuntabilitas yang baik membuat organisasi mengetahui siapa yang memastikan, siapa yang mengerjakan, siapa yang memutuskan, dan kapan persoalan harus dinaikkan.

← E05 Kegiatan Kembali ke Pengetahuan Kerangka DHASTRAM E07 Pemantauan →