Kalau lo kerja di IT RS, pasti pernah denger dua kubu yang saling sindir: tim vendor SIMRS yang katanya "datang pas bayar, ilang pas error" dan tim IT inhouse yang katanya "sok ngerti padahal cuma bisa ganti password". Tapi kalo dipikir-pikir, permusuhan ini sebenernya gak perlu. Artikel ini gue tulis dari pengalaman ada di dua sisi sekaligus, plus gimana caranya biar hubungan ini sehat dan RS-nya yang diuntungin.

Duduk Perkara: Kenapa Sering Ada Gesekan?

Dari sisi vendor, mereka punya produk yang dipake di banyak RS. Codebase-nya umum, fiturnya generik, butuh penyesuaian di tiap klien. Target mereka: deliver secepat mungkin, karena klien lain nunggu. Dari sisi IT inhouse, mereka yang ngadepin langsung user (dokter, perawat, administrasi) yang punya kebutuhan spesifik dan sering berubah. Target mereka: bikin sistem yang cocok sama kebiasaan RS sendiri.

Nah, disitulah gesekan dimulai:

  • Vendor bilang: "Fitur udah sesuai modul, tinggal dipake."
  • IT inhouse bilang: "Ini gak sesuai alur kami, minta ubah."
  • Vendor bilang: "Ubah? Itu custom, bayar tambahan."
  • IT inhouse bilang: "Tapi pas demo, katanya bisa disesuaikan!"

Dan loop itu terus berulang, sampe akhirnya ada yang kesel. Lucunya, yang rugi di akhir adalah RS-nya sendiri — vendor jadi dianggap "pembohong", IT inhouse dianggap "susah".

Perspektif Vendor: Kenapa Mereka Kayak Gitu?

Gue pernah duduk di sisi vendor, jadi gue ngerti kenapa mereka sering kelihatan "kaku". Beberapa alasannya:

1. Satu codebase, banyak klien

Vendor SIMRS yang mature biasanya punya satu basis kode yang dipake di puluhan RS. Kalau satu RS minta custom, vendor harus mikir: "Ini custom-nya bakal ngaruh ke RS lain gak? Gimana pas update next version?" Belum lagi soal testing — makin banyak custom, makin banyak test case yang harus dilewatin.

2. SDM terbatas, jam terbang tinggi

Tim vendor biasanya ramping. Satu programmer nanganin 5-10 RS sekaligus. Jadi kalau lo minta fitur besok jadi, vendor punya antrian panjang yang lebih prioritas. Dan sayangnya, prioritas vendor kadang ditentukan: "siapa yang bayarnya paling besar" atau "siapa yang marahnya paling keras ke direksi."

3. Dokumentasi internal yang gak selalu rapi

Jujur aja, divisi dokumentasi di vendor itu sering jadi anak tiri. Yang ditulis di proposal kadang berbeda dengan yang ada di kode. Jadi pas IT inhouse nanya "kenapa gak sesuai spek?", jawabannya kadang cuma: "oh itu fitur lamanya udah diganti."

Perspektif IT Inhouse: Kenapa Mereka Sering Frustrasi?

Dari sisi inhouse, ceritanya gak kalah rumit:

1. Mereka yang kena mental di lapangan

Kalau SIMRS error pas jam sibuk, yang kena omel bukan vendor — tapi IT inhouse. Dokter marah, perawat marah, pasien marah, semuanya marah ke "Mas IT". Vendor tinggal bilang "lagi diperbaiki, ya" dari balik meja yang jauh dari hiruk pikuk poli.

2. Kebutuhan RS selalu > fitur standar

Ini fakta yang gak bisa dipungkiri: RS di Indonesia, terutama yang swasta, punya banyak kebijakan internal yang gak ada di modul standar. Misal: aturan diskon khusus karyawan, mekanisme rujukan berjenjang, atau laporan yang formatnya udah ditentukan manajemen. Kalau vendor gak bisa ngakomodasi, IT inhouse yang kena getah: "Dok, ini gak bisa, sistemnya gak support." — dan jawaban itu gak pernah diterima enak sama user.

3. Anggaran terbatas buat custom

Minta custom ke vendor itu mahal. Dan manajemen sering gak ngerti kenapa fitur yang "udah ada di sistem" (versi standar) masih perlu biaya tambahan. Akhirnya IT inhouse yang harus ngakalin sendiri — bikin report terpisah, integrasi tempelan, atau bahkan query manual di database. Kreatif, tapi gak scalable.

Gimana Biar Hubungan Ini Sehat?

Dari pengalaman, ada beberapa hal yang bikin hubungan vendor-inhouse lebih adem:

1. Satu pintu komunikasi (Single Point of Contact)

Dari sisi RS, tunjuk satu orang sebagai penghubung utama ke vendor. Bukan berarti IT inhouse gak boleh ngomong langsung, tapi semua permintaan resmi lewat satu pintu. Ini mengurangi "kebisingan" — vendor gak dapet request dari tiga orang berbeda yang kadang isinya kontradiktif.

2. Bikin prioritas bersama

Vendor dan IT inhouse duduk bareng, bikin prioritas fitur/improvement untuk 3 bulan ke depan. Bukan cuma "yang penting buat RS", tapi juga "yang feasible buat vendor". Dengan prioritas bersama, ekspektasi jadi jelas: "Fitur A masuk Q3, fitur B masuk Q4."

3. Lingkup custom vs standar harus jelas dari awal

Pas kontrak, pastikan ada daftar fitur apa yang masuk paket standar dan apa yang dianggap custom. Ini kedengarannya simpel, tapi banyak RS yang baru sadar pas udah jalan setahun. Akibatnya: yang tadinya dikira gratis, ternyata kena charge. Dan yang tadinya dikira custom, ternyata fitur standar yang gak diaktifin.

4. Bikin jadwal maintenance bersama

Vendor biasanya punya jadwal rilis update (bulanan/kuartalan). IT inhouse mesti tau kapan, dan vendor mesti ngasih changelog yang jelas. Jangan sampe ada update dadakan yang bikin fitur inhouse jebol. Yang lebih baik: ada jadwal rutin — misal hari Sabtu minggu pertama — buat maintenance, update, dan testing bareng.

5. Jangan raba-raba, bikin dokumentasi

Setiap diskusi, setiap persetujuan: catet. Bisa di shared doc, ticketing system, atau sekadar email. Saat terjadi selisih paham (dan pasti terjadi), dokumentasi ini penyelamat. Baik vendor maupun inhouse bisa liat: "Oh, ternyata sepakatannya begini."

Siapa yang Menang Kalau Hubungan Ini Sehat?

Jawabannya: RS dan pasien. Vendor bisa deliver fitur lebih cepat karena IT inhouse ngasih spesifikasi yang jelas. IT inhouse gak perlu sok-sok-an bikin sistem sendiri karena vendor responsif. Dokter dan perawat dapat fitur yang sesuai. Dan pasien — yang paling penting — dapet layanan yang lebih baik.

Gue pernah liat RS di mana vendor dan IT inhouse rutin meeting tiap minggu, saling update, dan saling bantu debugging. Di RS itu, fitur baru bisa rilis dalam 2-3 minggu (bukan 3 bulan). Dan yang paling keren: pas error, dua tim langsung kolaborasi, bukan saling lempar tanggung jawab. Itu yang seharusnya.

Penutup: Bukan Lawan, Tapi Mitra

Vendor dan IT inhouse itu bukan rival. Mereka adalah dua sisi dari satu koin yang sama: layanan IT RS yang baik. Vendor punya resource dan pengalaman lintas RS. IT inhouse punya pengetahuan lokal soal kebutuhan RS-nya. Kalau dua sisi ini jalan bareng, hasilnya jauh lebih kuat daripada masing-masing jalan sendiri.

Jadi, daripada saling sindir di grup WhatsApp IT RS Indonesia, mending bikin satu meja. Bahas prioritas, bahas anggaran, dan bahas gimana caranya bikin SIMRS yang beneran dipake (dan disukai) oleh semua orang. Karena di akhir hari, yang diitung bukan siapa yang paling hebat, tapi apakah SIMRS-nya beneran ngebantu pasien pulang lebih cepat.

Salam kolaborasi,
MinTIRS