DIY Syndrome: Kebutuhan control freak terhadap Biaya dan Risiko Institusi

"Bayangkan 1 kementerian 400 (aplikasi), banyak yang lebih dari itu. Ada yang lebih dari 5.000. Saya enggak nunjuk di kementerian mana. Saking kreatifnya. Jadi sekali lagi Kemenkes (punya) aplikasi sendiri, pelayanan pajak (punya) aplikasi sendiri, untuk pelayanan pendidikan aplikasi sendiri," .

Ungkapan di atas disampaikan Presiden Jokowi dengan penekanan dan nada yang tinggi, saat memberi sambutan di acara Sistem Pemerintahan Berbasis Elektronik (SPBE) Summit 2024 dan Peluncuran GovTech Indonesia di Istana Negara, Jakarta, Senin (27/05/2024).

Selama  kurang lebih 10 tahun terakhir, penulis juga sering terlibat dalam diskusi dan perdebatan di komunitas penggiat IT perguruan tinggi terkait keresahan Presiden Jokowi di atas. Perdebatannya secara spesifik seputar,  apakah aplikasi atau software dibuat sendiri ? dibeli ? disewa ? atau dimodifikasi dari proyek open-source yang tersedia ? Dari diskusi dan interaksi  tersebut kelihatan sekali, sangat banyak institusi kampus yang terjebak dalam fenomena yang dikenal sebagai Syndrome DIY atau Do-It-Yourself Syndrome . Ini adalah kecenderungan untuk mencoba melakukan segala sesuatu sendiri, terutama dalam hal pengembangan aplikasi/ software atau sistem internal, meskipun ada solusi yang lebih efisien dan hemat biaya yang sudah tersedia. Mereka meyakini bahwa dengan membuat semuanya sendiri, institusi akan memiliki kontrol penuh (control freak), kustomisasi yang lebih baik, dan keamanan yang lebih terjamin. Namun, kenyataannya, kecenderungan ini sering kali membawa risiko dan biaya yang tidak sebanding dengan manfaat yang diharapkan.

Karakteristik DIY Syndrome

Kecenderungan untuk Melakukan Segalanya Sendiri : Institusi atau individu yang terjangkit DIY Syndrome cenderung merasa bahwa mereka harus membangun semuanya sendiri, dari awal hingga akhir, tanpa bantuan pihak ketiga. Mereka percaya bahwa melakukan sesuatu secara internal akan memberikan hasil yang lebih baik atau lebih sesuai dengan kebutuhan mereka. Misalnya, alih-alih menggunakan perangkat lunak yang sudah ada, mereka lebih memilih untuk membuat perangkat lunak tersebut dari awal, tanpa memikirkan sumber daya dan waktu yang dibutuhkan.

Overestimasi Kapabilitas Internal: Sering kali, insitusi dengan DIY Syndrome melebih-lebihkan kemampuan tim internal mereka untuk menangani proyek-proyek yang kompleks. Mereka mungkin mengabaikan kebutuhan akan keterampilan khusus, waktu, dan sumber daya yang diperlukan untuk menyelesaikan proyek dengan sukses. Hal ini bisa mengarah pada proyek yang macet di tengah jalan atau menghasilkan produk akhir yang tidak memenuhi harapan.

Minimisasi Risiko dan Biaya: Dalam banyak kasus, organisasi yang terkena DIY Syndrome meremehkan risiko dan biaya yang terkait dengan pengembangan internal. Mereka mungkin tidak mempertimbangkan biaya tersembunyi seperti pemeliharaan jangka panjang, pembaruan, pelatihan, dan dukungan teknis. Misalnya, biaya untuk mempekerjakan staf tambahan atau melatih staf yang ada sering kali diabaikan dalam perencanaan awal.

- Mengabaikan Solusi yang Sudah Ada: Alih-alih memanfaatkan solusi yang sudah ada dan telah terbukti efektif, institusi dengan DIY Syndrome mungkin mengabaikan atau menolak opsi ini karena keinginan untuk memiliki kontrol penuh atau karena keyakinan bahwa mereka dapat membuat sesuatu yang lebih baik. Mereka mungkin tidak menyadari bahwa solusi yang sudah ada bisa memberikan efisiensi dan keandalan yang lebih tinggi dengan biaya yang lebih rendah.

DIY Syndrome di Organisasi menurut Pakar

Fenomena DIY Syndrome tidak hanya terkait dengan keinginan untuk melakukan segala sesuatu sendiri, tetapi juga terkait erat dengan beberapa konsep manajemen dan studi organisasi yang telah lama menjadi perhatian para akademisi. Salah satunya adalah bias overconfidence atau managerial hubris. Pejabat atau pemimpin organisasi sering kali menunjukkan keyakinan berlebihan dalam kemampuan mereka sendiri untuk mengelola proyek internal tanpa bantuan eksternal. Penelitian oleh Roll (1986) tentang bias hubris menunjukkan bagaimana kepercayaan diri yang berlebihan dapat mengarahkan pada keputusan yang tidak rasional, seperti dalam kasus merger dan akuisisi yang gagal. Dalam konteks DIY Syndrome, keyakinan serupa dapat mendorong pejabat untuk memilih "melakukan sendiri" berbagai proyek, meskipun ada opsi pihak ketiga yang lebih efisien. Selain itu, konsep Resource-Based View (RBV) dan core competencies juga memberikan wawasan penting. RBV menekankan pentingnya organisasi untuk memfokuskan sumber daya mereka pada kompetensi inti dan bekerja sama dengan pihak ketiga untuk fungsi di luar kompetensi tersebut. Penelitian oleh Barney (1991) menggarisbawahi bahwa ketika organisasi mencoba melakukan segala sesuatu sendiri, mereka mungkin mengabaikan area di mana mereka tidak memiliki keahlian inti, yang pada akhirnya dapat menyebabkan inefisiensi dan kegagalan.

Pendekatan Transaction Cost Economics (TCE) yang dikembangkan oleh Oliver Williamson (1985) juga menyoroti perlunya organisasi untuk menilai biaya transaksi dari melakukan sesuatu secara internal versus bekerja dengan pihak eksternal. Pejabat dalam organisasi yang memilih untuk mengadopsi pendekatan DIY tanpa pertimbangan yang tepat sering kali mengabaikan biaya-biaya tersembunyi seperti ketidakpastian, risiko kegagalan, dan biaya koordinasi yang lebih tinggi.

Dalam konteks inovasi dan manajemen risiko, literatur yang luas telah membahas tentang bahaya pengembangan internal yang berlebihan. Manajemen inovasi dan risiko sering kali menunjukkan bahwa organisasi yang terlalu fokus pada pendekatan DIY cenderung mengabaikan risiko yang bisa dihindari melalui kolaborasi dengan pihak ketiga yang telah terbukti. Chesbrough (2003) dalam risetnya tentang inovasi terbuka menekankan bahwa kolaborasi dengan pihak ketiga sering kali menawarkan fleksibilitas, efisiensi, dan kualitas yang lebih tinggi daripada mencoba membangun semuanya sendiri.

Mungkinkan Menghindari Pihak Ketiga ?

Organisasi yang terjangkit DIY Syndrome sering kali lupa bahwa mereka tidak bisa menghindari keterlibatan pihak ketiga dalam operasional sehari-hari. Bahkan dalam hal-hal yang tampaknya sederhana dan rutin, pihak ketiga sering kali menjadi bagian tak terpisahkan dari ekosistem teknologi mereka. Berikut adalah beberapa contoh bagaimana institusi sebenarnya sudah sangat bergantung pada solusi pihak ketiga:

Email: Banyak institusi yang menggunakan layanan email dari pihak ketiga seperti Gmail atau Yahoo, alih-alih membangun sistem email internal mereka sendiri. Hal ini disebabkan oleh kenyamanan, fitur yang lengkap, dan dukungan keamanan yang ditawarkan oleh layanan ini, yang sulit untuk ditandingi oleh solusi internal. Mengembangkan dan mengelola sistem email sendiri tidak hanya mahal tetapi juga membutuhkan sumber daya manusia yang terlatih untuk mengatasi tantangan yang kompleks.

Chat dan Komunikasi: Layanan seperti WhatsApp, Slack, atau Microsoft Teams menjadi andalan banyak institusi untuk komunikasi internal dan eksternal. Membangun aplikasi chat internal mungkin tampak menarik, tetapi tantangan dalam hal infrastruktur, keamanan, dan pemeliharaan bisa jauh lebih besar dibandingkan dengan menggunakan layanan yang sudah ada dan terbukti. Layanan pihak ketiga ini menawarkan fitur yang lengkap dan terus diperbarui, sementara pengembangan internal sering kali kesulitan untuk mengikuti laju inovasi ini.

- Web Server: Banyak institusi menjalankan situs web mereka di server Apache atau Nginx , perangkat lunak open-source yang dikembangkan dan didukung oleh komunitas global. Meskipun mereka bisa membangun server web sendiri, biayanya akan jauh lebih tinggi dan kompleksitasnya jauh lebih besar daripada menggunakan solusi yang sudah tersedia ini. Open-source web server seperti Apache dan Nginx menawarkan stabilitas dan keamanan yang telah terbukti selama bertahun-tahun, sehingga sulit untuk membenarkan upaya membangun sesuatu dari awal.

Cloud Storage dan Infrastruktur: Layanan penyimpanan cloud seperti Google Drive, Dropbox, atau AWS S3 telah menjadi standar dalam pengelolaan data. Meskipun beberapa institusi mungkin tergoda untuk membangun infrastruktur penyimpanan mereka sendiri, biaya yang terkait dengan perangkat keras, keamanan, dan skalabilitas bisa menjadi penghalang besar. Selain itu, layanan cloud dari pihak ketiga menawarkan skalabilitas yang hampir tak terbatas, sementara solusi internal mungkin terbatas oleh infrastruktur fisik dan anggaran yang ada.

- Platform Pembelajaran Online : Dalam pendidikan, banyak institusi menggunakan platform pembelajaran online, seperti Edlink, Moodle, Blackboard , atau Google Classroom . Membangun platform pembelajaran internal dari awal mungkin terlihat menarik, tetapi waktu dan sumber daya yang diperlukan untuk mencapai tingkat fungsi dan dukungan yang sama dengan platform-platform ini sering kali tidak sebanding. Platform pembelajaran yang sudah ada ini menawarkan berbagai fitur yang dikembangkan berdasarkan feedback dari ribuan pengguna di seluruh dunia, sesuatu yang sulit ditiru oleh tim pengembangan internal yang terbatas.

Ada satu hal yang sering dilupakan adalah bahwa, meskipun mereka pada akhirnya mungkin berhasil membangun aplikasi internal, universitas ini tetap bergantung pada pihak ketiga untuk banyak fungsi dasar lainnya, seperti layanan email untuk komunikasi, layanan chat untuk interaksi internal, dan web server untuk hosting situs web mereka. Kebutuhan untuk keterlibatan pihak ketiga ini tidak bisa dihindari, dan upaya untuk mengurangi ketergantungan tersebut sering kali justru membawa lebih banyak masalah daripada solusi.

Mengapa DIY Syndrome Bisa Merugikan

Biaya yang Membengkak: Membuat aplikasi internal dari awal membutuhkan investasi besar. Tidak hanya biaya pengembangan awal yang tinggi, tetapi juga biaya pemeliharaan, peningkatan, dan dukungan teknis yang berkelanjutan. Ini bisa jauh lebih mahal daripada menggunakan solusi pihak ketiga yang sudah ada dan matang.

Waktu Pengembangan yang Lama: Proses pengembangan internal sering kali memakan waktu lebih lama daripada yang direncanakan. Keterlambatan ini bisa mempengaruhi operasional institusi dan menghambat tujuan strategis lainnya.

Kualitas dan Keamanan yang Diragukan: Layanan pihak ketiga seperti Gmail, WhatsApp, atau Apache sudah terbukti dan memiliki dukungan keamanan yang kuat. Mencoba meniru tingkat kualitas dan keamanan ini dalam pengembangan internal adalah tugas yang sangat sulit dan berisiko. Banyak insitusi yang akhirnya harus menanggung biaya tambahan untuk memperbaiki atau meningkatkan sistem internal yang tidak memenuhi standar kualitas yang diharapkan.

Mengalihkan Fokus dari Tugas Utama: Fokus pada pengembangan aplikasi internal dapat mengalihkan sumber daya dari tugas utama institusi, seperti peningkatan kualitas pendidikan, penelitian, atau layanan kepada mahasiswa. Ini dapat mengakibatkan hilangnya daya saing atau penurunan kualitas layanan. Sebuah universitas yang menghabiskan terlalu banyak waktu dan sumber daya untuk mengembangkan aplikasi internal mungkin kehilangan kesempatan untuk berinvestasi dalam inisiatif lain yang lebih langsung mendukung misi akademiknya.

Menakar Kembali Kebutuhan DIY

DIY Syndrome sering kali dilandasi oleh keinginan untuk memiliki kontrol penuh dan independensi. Namun, institusi perlu menilai dengan bijak apakah pengembangan internal benar-benar memberikan nilai tambah yang signifikan dibandingkan solusi pihak ketiga yang sudah ada. Menggunakan layanan pihak ketiga tidak berarti kehilangan kendali; sebaliknya, ini memungkinkan institusi kampus untuk fokus pada core business tridarma,  sambil memanfaatkan teknologi dan layanan terbaik yang tersedia di pasar.

Dalam banyak kasus, kolaborasi dengan pihak ketiga justru memberikan fleksibilitas, efisiensi, dan kualitas yang lebih tinggi daripada mencoba membangun segalanya sendiri. Sebelum memutuskan untuk mengembangkan aplikasi internal, penting untuk melakukan analisis cost-benefit yang mendalam dan mempertimbangkan apakah keputusan tersebut benar-benar menguntungkan dalam jangka panjang. Memahami bahwa tidak semua hal harus dilakukan sendiri, dan bahwa terkadang solusi yang paling bijaksana adalah menggunakan apa yang sudah ada, dapat membantu institusi menghindari jebakan DIY Syndrome dan fokus pada apa yang benar-benar penting dan mendesak.