Deploy ke Production Tanpa Change Ticket… Cepat Sekarang, Panik Saat Audit!

Ketika Kecepatan Deployment Mengalahkan Tata Kelola IT

Semua Terlihat Lancar… Sampai Auditor Datang

Di sebuah perusahaan, tim IT baru saja menyelesaikan pengembangan aplikasi.

Fitur selesai.☑️

Testing berhasil.☑️

User meminta agar perubahan segera diterapkan.

Lalu muncul kalimat yang mungkin sering kita dengar:

“Langsung deploy saja. Perubahannya kecil, tidak perlu bikin tiket.”

Code di-push.☑️

Deployment berhasil.☑️

Aplikasi berjalan normal.☑️

Tidak ada masalah. Tidak ada komplain. Semua merasa pekerjaan selesai.

Ternyata…

Beberapa waktu setelahnya bisa jadi ada masalah.

User menemukan bahwa sejumlah transaksi tidak masuk ke laporan.

Tim IT mulai melakukan investigasi.

• Tim aplikasi menyatakan tidak ada masalah pada aplikasi.
• Tim database menemukan beberapa transaksi tidak tersimpan secara lengkap.
• User memastikan bahwa transaksi sebelumnya berjalan normal.

Setelah investigasi cukup panjang, ditemukan bahwa validasi yang ditambahkan sebelumnya ternyata menolak transaksi dengan kondisi tertentu.

Dampaknya User harus melakukan rekonsiliasi transaksi secara manual, memperbaiki data yang bermasalah, dan mengalokasikan waktu tambahan untuk investigasi serta perbaikan aplikasi.

Padahal, jika perubahan tersebut dicatat melalui proses Change Management, tim IT dapat lebih cepat mengetahui perubahan terakhir, menganalisis dampaknya, dan menentukan langkah pemulihan.

Lebih dari dampak tersebut, muncul masalah tambahan saat tiba waktunya Auditor datang untuk melakukan evaluasi terhadap proses Change Management yang berjalan.

---

Beberapa Minggu Kemudian… Auditor Mulai Bertanya

Saat audit berlangsung, auditor meminta bukti perubahan sistem.

“Boleh ditunjukkan change ticket untuk deployment ini?”

Tim mulai mencari.

Di sistem ITSM… tidak ada.

Dokumentasi… tidak ditemukan.

Approval formal… tidak tercatat.

Yang tersisa hanya percakapan WhatsApp.

Lalu auditor bertanya:

“Siapa yang menyetujui perubahan ini?”

“Apakah risikonya sudah dinilai?”

“Bagaimana jika deployment gagal?”

Ruangan yang sebelumnya terasa kondusif…

mendadak penuh ketegangan.

“Perubahan yang berhasil secara teknis belum tentu berhasil dari sisi tata kelola.”

---

Masalahnya Bukan pada Kemampuan Teknis

Tim IT mungkin sangat kompeten.

Mereka bisa melakukan deployment cepat, memperbaiki bug, dan menjaga sistem tetap berjalan.

Namun masalah muncul ketika kecepatan lebih diutamakan daripada kontrol.

Change Management sering dianggap:

• Administrasi tambahan
• Proses yang memperlambat pekerjaan
• Formalitas untuk kebutuhan audit

Padahal…

Change Management bukan untuk memperlambat perubahan, tetapi memastikan perubahan tetap terkendali.

Tanpa pencatatan yang memadai, organisasi bisa kehilangan:

• Approval: siapa yang menyetujui perubahan?
• Risk Assessment: apa risiko terhadap layanan?
• Traceability: apa yang berubah dan siapa pelaksananya?
• Rollback Plan: bagaimana memulihkan sistem jika gagal?

Dalam praktik ISO/IEC 20000 dan IT Service Management, pengendalian perubahan merupakan bagian penting dalam menjaga kualitas layanan.

“Change ticket bukan sekadar administrasi. Ia adalah jejak keputusan dan pengendalian risiko.”

---

---

Cepat Boleh… Tapi Jangan Kehilangan Kontrol

Di era DevOps dan CI/CD, deployment cepat memang menjadi kebutuhan.

Tetapi cepat bukan berarti boleh melewati kontrol.

Organisasi perlu memastikan:

• Standard Change: perubahan rutin mengikuti prosedur yang telah disetujui.
• Normal Change: perubahan dinilai risikonya dan memperoleh otorisasi yang sesuai.
• Emergency Change: perubahan mendesak tetap memiliki kontrol yang proporsional.
• Automation: pencatatan perubahan terintegrasi dengan proses deployment.

Dengan begitu…

Tim tetap bisa bergerak cepat, tanpa mengorbankan tata kelola.

---

Jangan Tunggu Auditor untuk Menemukan Masalah

Banyak organisasi baru memperbaiki Change Management setelah muncul temuan audit.

Padahal risiko sebenarnya bukan sekadar audit finding.

Tetapi ketika perubahan menyebabkan gangguan besar…

dan tidak ada yang tahu:

Apa yang berubah?

Siapa yang menyetujui?

Bagaimana cara memulihkannya?

“Audit mungkin menemukan tiket yang hilang. Tetapi incident bisa menunjukkan mahalnya kontrol yang diabaikan.”

Pada akhirnya…

Deployment sukses bukan hanya ketika aplikasi berhasil berjalan.

Tetapi ketika perubahan dilakukan dengan aman, terkendali, dan dapat dipertanggungjawabkan.

Karena bisnis tidak hanya membutuhkan:

IT yang bisa deploy cepat.

Tetapi…

IT yang bisa berubah cepat tanpa kehilangan kendali.

---

Bagaimana dengan perusahaan Anda?

Apakah deployment ke production sudah melalui Change Management yang jelas?

Atau masih sering mengandalkan approval lewat chat dan dokumentasi belakangan?

#DigitalTransformation #Mitratex #MitratexConsulting #IndonesiaTechDigest #ITServiceManagement #ITSM #ITIL #ITGovernance #ITTransformation #ChangeManagement #ITServiceManagement #ITSM #ISO20000 #ITAudit #ITCompliance #DevOps #ChangeEnablement #ITOperations #RiskManagement #DigitalTransformation

Penulis : Asri Ratnianingsih

Data Warehouse Sudah Dibangun… Tapi Kenapa Angkanya Masih Berbeda?

Ketika Teknologi Sudah Siap, tetapi Sumber Data Belum Bisa Dipercaya.

Semua Ingin Jadi Data-Driven

Di ruang meeting, manajemen mulai membicarakan transformasi digital.

“Kita butuh Data Warehouse!”

Tujuannya jelas:

• Semua data terintegrasi
• Dashboard lebih mudah dibuat
• Laporan lebih cepat tersedia
• Keputusan bisnis berbasis data

Project pun dimulai.

Budget disetujui. Tim dibentuk. Teknologi dipilih.

Beberapa bulan kemudian…

Data Warehouse berhasil dibangun.

Semua terlihat berjalan sesuai rencana.

Tapi ternyata, masalah sebenarnya baru dimulai.

---

---

Dashboard Sudah Ada… Tapi Angkanya Tidak Sama

Suatu hari, manajemen meminta laporan penjualan.

Tim Finance menunjukkan angka Rp12 miliar.

Tim Sales melaporkan Rp11,5 miliar.

Sementara dashboard Data Warehouse menampilkan Rp11,8 miliar.

Satu perusahaan. Satu periode. Tiga angka berbeda.

Lalu muncul pertanyaan:

“Sebenarnya data mana yang benar?”

Tim IT mulai melakukan pengecekan.

Ternyata…

Definisi transaksi berbeda.

Format data tidak konsisten.

Ada data duplikat.

Beberapa sistem belum tersinkronisasi.

Dan setiap departemen punya cara sendiri dalam menghitung laporan.

“Menggabungkan data dari banyak sistem tidak otomatis membuat data tersebut menjadi benar.”

---

Masalahnya Bukan Selalu di Data Warehouse

Banyak organisasi terlalu fokus pada pembangunan teknologi.

Server disiapkan.

Database dirancang.

Pipeline dibuat.

Dashboard dikembangkan.

Tapi satu hal sering terlupakan:

Apakah sumber datanya sudah benar-benar siap?

Karena kalau data dari awal sudah tidak konsisten…

Data Warehouse hanya akan mengumpulkan ketidakkonsistenan itu ke dalam satu tempat.

Garbage In, Garbage Out.

Teknologi secanggih apa pun tidak bisa otomatis memperbaiki data yang definisi, kualitas, dan kepemilikannya belum jelas.

---

Data Governance Bukan Sekadar Dokumentasi

Di sinilah pentingnya Data Governance.

Bukan hanya membuat kebijakan atau dokumen.

Tetapi memastikan organisasi memiliki kejelasan tentang:

• Data Ownership: siapa yang bertanggung jawab terhadap data?
• Data Quality: bagaimana kualitas data diperiksa dan dijaga?
• Data Definition: apakah setiap departemen menggunakan definisi yang sama?
• Data Integration: bagaimana data dari berbagai sistem diselaraskan?
• Data Accountability: siapa yang harus bertindak ketika ditemukan masalah?

Tanpa pengelolaan yang jelas, setiap departemen bisa merasa datanya paling benar.

Padahal perusahaan membutuhkan satu pemahaman yang konsisten terhadap data, bukan sekadar satu tempat penyimpanan.

“Single Source of Truth bukan hanya soal menyatukan database, tetapi menyatukan definisi dan kepercayaan terhadap data.”

---

---

Jangan Bangun Dashboard Sebelum Membereskan Fondasinya

Sebelum membangun Data Warehouse yang lebih besar, organisasi perlu memastikan:

1. Definisi data sudah disepakati.

Jangan sampai istilah customer aktif atau total penjualan memiliki arti berbeda di setiap departemen.

2. Kualitas sumber data sudah diperiksa.

Data duplikat, tidak lengkap, dan tidak konsisten harus diidentifikasi.

3. Kepemilikan data sudah jelas.

Harus ada pihak yang bertanggung jawab ketika kualitas data bermasalah.

4. Perbaikan data menjadi proses berkelanjutan.

Karena kualitas data tidak cukup diperbaiki sekali saat implementasi.

Data Warehouse adalah bagian dari solusi, bukan pengganti tata kelola data.

---

Pada Akhirnya, Bisnis Tidak Membutuhkan Sekadar Dashboard yang Indah

Manajemen tidak membutuhkan grafik yang hanya terlihat menarik.

Mereka membutuhkan informasi yang bisa dipercaya untuk mengambil keputusan.

Karena keputusan yang salah tidak selalu disebabkan oleh kurangnya data.

Kadang justru karena…

terlalu banyak data, tetapi tidak ada yang benar-benar yakin mana yang benar.

Data Warehouse yang hebat bukan yang mampu menyimpan data paling banyak, tetapi yang mampu menyediakan data yang konsisten dan dapat dipercaya.

Jadi sebelum perusahaan berinvestasi lebih jauh pada Data Warehouse, Analytics, bahkan AI…

pastikan fondasi datanya sudah benar.

Karena:

Data Warehouse bukan solusi kalau sumber datanya masih kacau.

---

Bagaimana dengan perusahaan Anda?

Apakah Data Warehouse sudah menjadi sumber informasi yang dipercaya, atau setiap departemen masih memiliki angka versinya masing-masing?

#DataWarehouse #DataGovernance #DataQuality #DataManagement #DataEngineering #BusinessIntelligence #DataAnalytics #DigitalTransformation #DataDriven #ITGovernance #EnterpriseData #Mitratex

Ditulis oleh: Rama Ambara

Kenapa 80% Implementasi ITIL Gagal (Dan Tidak Ada yang Mau Mengakuinya)

Semua Bilang Berhasil. Tapi Operasional Tetap Berantakan.

---

Semua Proyek Dimulai dengan Optimisme

Awal proyek selalu terlihat menjanjikan:

• Workshop berjalan lancar
• Consultant presentasi meyakinkan
• Framework jelas
• Timeline disusun
• Budget disetujui

Semua orang percaya:

“Kali ini kita akan implementasi ITIL dengan benar.”

---

Beberapa Bulan Kemudian… Realita Mulai Muncul

Yang terjadi di lapangan:

• SOP selesai… tapi tidak dipakai
• Tools sudah live… tapi tidak optimal
• Proses ada… tapi dilanggar
• Tim mulai kembali ke cara lama

Dan yang paling menarik:

Secara resmi… proyek dianggap “berhasil”.

---

Kenapa Bisa Begini?

Karena kita sering mendefinisikan “berhasil” sebagai:

• go-live selesai
• dokumentasi lengkap
• audit lolos

Bukan:

operasional benar-benar berubah

---

Mari Jujur… Ini Penyebab Sebenarnya

---

1. Fokus ke Project, Bukan Transformation

Banyak organisasi memperlakukan ITIL sebagai:

👉 project dengan deadline

Padahal seharusnya:

👉 perubahan cara kerja jangka panjang

Hasilnya:

• selesai di atas kertas
• gagal di operasional

---

2. Over-Design, Under-Execution

Yang sering terjadi:

• workshop berhari-hari
• proses didesain detail
• dokumen sangat lengkap

Tapi:

• tidak pernah benar-benar dijalankan
• tidak pernah diuji dalam kondisi nyata

---

3. Tools Dikirim Lebih Cepat dari Mindset

Organisasi berpikir:

“Kalau sudah pakai tools, berarti sudah ITIL.”

Padahal:

• tools hanya enabler
• bukan solusi utama

Tanpa perubahan cara kerja:

tools hanya mempercepat chaos

---

4. Tidak Ada Ownership yang Jelas

Semua orang:

• ikut meeting
• ikut diskusi

Tapi saat implementasi:

tidak jelas siapa yang benar-benar bertanggung jawab

---

5. Tidak Siap Menghadapi Resistance

Realita:

• orang tidak suka berubah
• tim nyaman dengan cara lama
• proses baru dianggap ribet

Tanpa change management yang kuat:

semua akan kembali ke kebiasaan lama

---

Masalah Terbesarnya?

Tidak ada yang mau bilang:

“Ini gagal.”

Karena:

• sudah keluar budget besar
• sudah melibatkan banyak pihak
• sudah dilaporkan ke manajemen

Akhirnya:

semua sepakat pura-pura berhasil

---

Ciri-Ciri Implementasi ITIL yang Gagal (Tapi Dianggap Sukses)

• SOP lengkap, tapi tidak dipakai
• Tools ada, tapi digunakan setengah hati
• KPI bagus, tapi user tetap komplain
• Incident berulang
• Tim kembali ke cara manual
• Maturity level tinggi sesuai atau melebihi target

---

Solusi (Yang Jarang Dilakukan dengan Serius)

---

1. Treat ITIL as Journey, Not Project

Bukan:

• selesai dalam 6 bulan

Tapi:

• evolve terus menerus

---

2. Fokus ke Behaviour Change

Bukan:

• “proses apa yang kita punya”

Tapi:

• “bagaimana tim benar-benar bekerja”

---

3. Start Small, But Real

Lebih baik:

• 1 proses berjalan nyata

Daripada:

• 10 proses hanya di dokumen

---

4. Measure What Matters

Bukan:

• compliance

Tapi:

• outcome
• user experience
• stability

---

Implementasi ITIL jarang gagal di dokumen. Tapi sering gagal di kebiasaan.

---

ITIL bukan masalah.

Framework sudah jelas. Best practice sudah ada.

Yang sering gagal adalah:

kita ingin terlihat berubah… tanpa benar-benar berubah.

---

Banyak implementasi ITIL terlihat sukses.

Go-live selesai. SOP lengkap. Tools jalan.

Tapi operasional tetap chaos.

Karena yang berubah hanya dokumentasi… bukan cara kerja.

Dan itu yang paling mahal.

#DigitalTransformation #Mitratex #MitratexConsulting #IndonesiaTechDigest #ITServiceManagement #ITSM #ITIL #ITGovernance #ITTransformation #ChangeManagement #ProcessImprovement #ContinualImprovement #ITOperations #ITLeadership #OperationalExcellence #ServiceManagement #ITManager

Ditulis oleh: Dr. Dede Mulyana

Kalau Perusahaan Hanya Boleh Mempertahankan Satu Profesi IT… Siapa yang Paling Penting?

Semua Profesi IT Merasa Paling Penting

Coba tanyakan ke satu perusahaan:

“Kalau hanya boleh mempertahankan SATU profesi IT, siapa yang harus tetap ada?”

Developer mungkin bilang:

“Tanpa kami, siapa yang membuat aplikasinya?”

Network Engineer bisa menjawab:

“Kalau jaringan mati, aplikasinya mau jalan di mana?”

Cyber Security punya alasan lain:

“Sistem berjalan tapi tidak aman, sama saja menunggu masalah.”

DevOps memastikan perubahan bisa berjalan cepat dan stabil.

Data Engineer memastikan data bisa digunakan untuk mengambil keputusan.

Lalu siapa yang paling penting?

Jawabannya ternyata tidak sesederhana memilih satu profesi.

---

---

Masing-Masing Hebat… Tapi Tidak Bisa Berdiri Sendiri

Developer bisa membuat aplikasi yang luar biasa.

Tapi aplikasi tetap membutuhkan network agar dapat diakses.

Network yang stabil tetap membutuhkan security.

Development yang cepat membutuhkan operation dan automation.

Dan semua aktivitas tersebut menghasilkan data yang harus dikelola agar bisa digunakan bisnis.

Artinya…

keberhasilan layanan IT bukan hasil satu profesi.

Tetapi hasil dari banyak fungsi yang saling terhubung.

“Aplikasi yang berhasil dibuat belum tentu menjadi layanan yang berhasil dijalankan.”

---

Masalah Dimulai Ketika Semua Bekerja Sendiri-Sendiri

Developer hanya memikirkan development.

Operation hanya memikirkan availability.

Security hanya memikirkan keamanan.

Data hanya memikirkan data.

Secara individual…

semuanya mungkin bekerja dengan baik.

Tapi ketika tidak ada kolaborasi, masalah kecil bisa berubah menjadi masalah besar.

Dan biasanya hal itu baru terlihat…

ketika incident terjadi.

---

---

Ketika Incident Terjadi, Tidak Ada Lagi “Itu Bukan Bagian Saya”

Ketika aplikasi tidak bisa digunakan…

customer tidak bertanya:

“Ini salah Developer atau Network?”

Ketika transaksi gagal…

Direksi juga tidak ingin mendengar:

“Itu bukan scope tim kami.”

Bagi bisnis, semuanya hanya satu:

layanan sedang bermasalah.

“Di dalam IT kita mengenal banyak fungsi. Di mata bisnis, semuanya tetap satu layanan.”

---

Jadi… Siapa yang Paling Penting?

Developer?

Network Engineer?

Cyber Security?

DevOps?

Data Engineer?

Mungkin pertanyaan yang lebih tepat bukan:

“Siapa yang paling penting?”

Tetapi:

“Apakah mereka mampu bekerja sebagai satu tim?”

Karena perusahaan tidak membutuhkan sekumpulan orang hebat yang bekerja sendiri-sendiri.

Perusahaan membutuhkan orang-orang hebat…

yang bisa bekerja bersama.

“Tidak ada profesi IT yang memenangkan perang sendirian. Yang menang adalah tim yang mampu bekerja sebagai satu kesatuan.”

Tapi kalau tetap dipaksa memilih…

kalau perusahaan Anda hanya boleh mempertahankan SATU profesi IT, siapa yang Anda pilih?

#DigitalTransformation #Mitratex #MitratexConsulting #IndonesiaTechDigest #IT #ITIndonesia #ITProfessionals #ITCareer #Developer #NetworkEngineer #CyberSecurity #DevOps #DataEngineer #ITOperations #ITServiceManagement #ITLeadership #DigitalTransformation #Teamwork #Mitratex

Ditulis oleh: Febby Febrianti

Kenapa Kematangan Digital Bank Anda Perlu Diukur?🏦📊

System Sudah Ada… Tapi Kenapa User Masih Lebih Suka WhatsApp?

Ketika Investasi ITSM Tidak Diikuti Perubahan Cara Kerja

Tools Sudah Dibeli… Tapi Cara Kerjanya Masih Sama

Saya sering sekali menemukan kondisi perusahaan yang seperti ini.

Perusahaan sudah memiliki aplikasi Helpdesk untuk ticketing system yang di dalamnya sudah ada fitur service portal sehingga user dapat melaporkan dan membuat tiketnya sendiri.

Aplikasi itupun sudah dibangun dengan workflow, SLA, Formulir yang sudah di pertimbangkan dengan matang.

Kalau dilihat dari sisi teknologi…

seharusnya semuanya sudah siap.

Tapi begitu user mengalami masalah, hal yang selalu dilakukan adalah

📱 Chat WhatsApp ke orang IT yang dikenal.

📞 Telepon langsung.

🚶 Datang ke meja IT.

“Bro, aplikasi saya error. Tolong cek ya.”

Selesai?

Masalah user yang dilaporkan mungkin selesai dengan cepat.

Tapi ada satu masalah lain yang justru baru dimulai.

Tidak ada tiket!! Tidak ada data!! Tidak ada jejak pekerjaan!!

---

Pekerjaan Nyata… Tapi di History-nya Tidak Ada

Bayangkan dalam satu bulan tim IT sebenarnya menangani 500 permintaan.

Tapi yang masuk ke system hanya 200.

Apa yang dilihat management?

ya hanya 200 tiket.

Padahal realitas operasionalnya sangat jauh lebih besar.

Akibatnya:

• volume pekerjaan terlihat lebih rendah
• SLA tidak menggambarkan kondisi sebenarnya
• recurring incident sulit dianalisis
• beban tim support terlihat ringan
• kebutuhan resource menjadi salah untuk dihitung dan direncanakan

Dashboard memang tidak berbohong atau salah.

Dashboard hanya menampilkan…

Tapi data yang ada di dashboard yang tidak sesuai dengan kenyataan.

“Kalau pekerjaan terjadi di luar system, bagi data pekerjaan itu seolah tidak pernah terjadi.”

Dan inilah yang sering membuat management mendapatkan gambaran yang berbeda dengan kondisi di lapangan.

---

Masalahnya Bukan Selalu di System

Ketika adopsi rendah, reaksi pertama biasanya:

“Tools-nya kurang bagus.”

“Fiturnya kurang lengkap.”

“User interface-nya kurang nyaman.”

Mungkin saja.

Tapi tidak selalu.

Kadang masalah sebenarnya jauh lebih sederhana:

cara kerja lama masih dibiarkan hidup.

User masih boleh WhatsApp.

Masih boleh telepon personal.

Masih bisa meminta bantuan langsung tanpa tiket.

Sementara tim IT tetap melayani semuanya.

Lama-lama terbentuk kebiasaan:

“Ngapain bikin tiket? Chat saja lebih cepat.”

Dan ketika kebiasaan itu dibiarkan…

system yang seharusnya menjadi jalur utama akhirnya hanya menjadi tempat administrasi.

“Implementasi system tidak otomatis mengubah cara kerja. Teknologi bisa dipasang dalam hitungan bulan, kebiasaan manusialah yang harus dibangun.”

---

Helpdesk Bukan Sekadar Tempat Mencatat Tiket

Ini yang menurut saya sering terlewat.

Ticketing system bukan dibuat hanya supaya:

“Semua request punya nomor tiket.”

Data di dalamnya seharusnya membantu organisasi melihat:

• Berapa banyak pekerjaan yang sebenarnya ditangani
• Masalah apa yang terus berulang
• Layanan mana yang paling sering terganggu
• Berapa besar beban masing-masing tim
• Masalah mana yang perbaikannya harus diprioritaskan

Dari sekadar tiket…

sebenarnya perusahaan sedang membangun sumber data untuk pengambilan keputusan.

Kalau sebagian besar pekerjaan dilakukan di luar system…

nilai itu ikut hilang.

---

Bukan Berarti WhatsApp Harus Dilarang

WhatsApp, telepon, atau komunikasi langsung tetap bisa berguna.

Terutama dalam kondisi urgent.

Masalahnya bukan pada channel komunikasinya.

Masalah muncul ketika:

percakapan berhenti di channel tersebut dan tidak pernah menjadi record resmi.

User boleh menghubungi IT.

Tetapi pekerjaan tetap harus tercatat.

Karena organisasi membutuhkan single source of truth untuk memahami kondisi layanan IT yang sebenarnya.

“Yang perlu disatukan bukan cara orang berkomunikasi, tetapi jejak pekerjaannya.”

---

Good System Saja Tidak Cukup

Pada akhirnya keberhasilan implementasi ITSM tidak hanya ditentukan oleh seberapa banyak fitur yang tersedia.

Ada tiga hal yang harus berjalan bersama:

1. Good System

System mudah digunakan dan mendukung kebutuhan operasional.

1. Good Process

Ada jalur yang jelas bagaimana request dan incident harus ditangani.

1. Good Adoption

User dan tim IT disiplin menjalankan proses tersebut.

Karena system yang bagus tanpa adoption…

akhirnya hanya menjadi aplikasi mahal yang jarang digunakan.

---

Jadi, Coba Lihat Kondisi di Perusahaan Anda

Ketika user mengalami masalah hari ini…

ke mana mereka pergi?

Service Portal?

Helpdesk?

WhatsApp?

Telepon?

Atau langsung mencari “orang IT yang biasa membantu”?

Kalau jawabannya masih didominasi jalur informal…

mungkin tantangan berikutnya bukan membeli tools baru.

Tetapi memastikan tools yang sudah ada benar-benar menjadi bagian dari cara kerja sehari-hari.

“Transformasi digital bukan terjadi ketika system mulai digunakan. Transformasi terjadi ketika cara kerja lama mulai ditinggalkan.”

Good System + Good Process + Good Adoption = Better Service.

#DigitalTransformation #Mitratex #MitratexConsulting #IndonesiaTechDigest #ITServiceManagement #Helpdesk #ServiceDesk #ITOperations #ITSupport #ServiceManagement #DigitalTransformation #ProcessImprovement #UserAdoption #IncidentManagement #ITGovernance #OperationalExcellence #ESTIMSoftware #Mitratex

Ditulis oleh: Kresna Dwi Prasetya

Sudahkah Anda Ukur Tingkat Kematangan Digital Bank Anda?🏦📊

🔐Seberapa siap keamanan siber perusahaan Anda?

🚨SOC perusahaan Anda sudah siap menghadapi serangan siber?

ITIL di Slide vs ITIL di Dunia Nyata

Satu Terlihat Sempurna. Satu Lagi Penuh Drama.

Di Slide Presentasi… Semua Terlihat Indah

Di ruang meeting atau training:

• Diagram rapi
• Proses jelas
• Flow terstruktur
• Role & responsibility terdefinisi

Semua terlihat:

logis, sistematis, dan terkendali

Kalau dilihat di slide…

ITIL terlihat seperti “mesin” yang sempurna.

---

Tapi Begitu Masuk ke Dunia Nyata… Ceritanya Berubah

Di lapangan:

• Incident datang bersamaan
• Tidak jelas siapa yang memimpin
• Eskalasi lompat jalur
• Chat penuh, tapi tidak ada keputusan
• Semua sibuk… tapi tidak sinkron

Dan yang paling sering terjadi:

Proses yang di slide… tidak benar-benar dijalankan.

---

Kenapa Gap Ini Selalu Terjadi?

Karena banyak organisasi berhenti di:

memahami ITIL… tanpa benar-benar mengoperasikannya

---

Perbedaan Nyata yang Jarang Dibahas

1. Slide = Ideal Condition

Reality = Pressure & Chaos

Di slide:

• semua berjalan sesuai alur

Di dunia nyata:

• semua berjalan bersamaan
• penuh tekanan
• penuh ketidakpastian

---

2. Slide = Sequential

Reality = Parallel Chaos

Di slide:

• Incident → Problem → Change

Di lapangan:

• semuanya terjadi bersamaan
• saling tumpang tindih
• sering tanpa koordinasi

---

3. Slide = Defined Role

Reality = Everyone Jump In

Di slide:

• jelas siapa melakukan apa

Di lapangan:

• semua ikut campur
• tidak ada komando
• tidak ada ownership yang jelas

---

4. Slide = Controlled Communication

Reality = Noise Everywhere

Di slide:

• komunikasi terstruktur

Di lapangan:

• WhatsApp
• Telepon
• Email
• Meeting dadakan

Semua jalan… tanpa satu sumber kebenaran.

---

Masalah Sebenarnya

Bukan karena:

• ITIL terlalu kompleks
• tim tidak kompeten

Tapi karena:

organisasi hanya mengadopsi “bentuknya”… bukan “cara kerjanya”

---

Kenapa Ini Berbahaya?

Karena:

• Direksi merasa semua sudah “by process”
• Tim IT merasa sudah “sesuai framework”
• Tapi operasional sebenarnya tidak terkendali

---

Ciri-Ciri ITIL yang Hanya Hidup di Slide

• Proses hanya muncul saat audit
• Dokumentasi lengkap, tapi tidak dipakai
• Eskalasi sering lewat jalur informal
• Tidak ada real-time visibility
• Tim lebih mengandalkan “insting” daripada proses

---

Solusi (Yang Jarang Dilakukan)

1. Ubah dari “Design” ke “Execution”

Bukan hanya:

• mendesain proses

Tapi:

• memastikan proses benar-benar dijalankan

---

2. Simulasikan Chaos

Jangan hanya:

• training
• workshop

Tapi:

Latih tim dalam kondisi tekanan yang nyata

---

3. Bangun Single Source of Truth

Semua harus:

• terlihat
• tercatat
• terintegrasi

---

4. Fokus ke Behaviour, Bukan Dokumentasi

ITIL bukan:

“apa yang ditulis”

Tapi:

apa yang dilakukan saat situasi kritis

---

ITIL di slide itu sempurna. ITIL di dunia nyata… tergantung seberapa serius Anda menjalankannya.

---

Framework tidak pernah salah.

Yang sering terjadi:

kita terlalu sibuk membuatnya terlihat benar… tapi tidak pernah benar-benar menggunakannya.

---

ITIL di slide itu rapi.

Semua jelas. Semua terstruktur.

Tapi begitu masuk ke dunia nyata… semuanya berubah jadi chaos.

Bukan karena framework-nya salah.

Tapi karena kita hanya mengadopsi bentuknya— bukan cara kerjanya.

#DigitalTransformation #Mitratex #MitratexConsulting #IndonesiaTechDigest  #ESTIMSoftware #YourCompliancePartner #ITServiceManagement #IncidentManagement #ITOperations #ITLeadership #ITGovernance #DigitalTransformation #OperationalExcellence #ServiceDesk #ITManager #CIO #ContinualImprovement #BusinessContinuity

Ditulis oleh: Dr. Dede Mulyana

Komentar

Tambah komentar…

Belum ada komentar

Jadilah pemberi komentar pertama.