IT Outsourcing Bandung: 7 Pertanyaan yang Harus Ditanyakan Sebelum Teken Kontrak

Kalau bisnis Anda sedang proses seleksi vendor IT outsourcing, kemungkinan besar salesman dari pihak vendor sudah sangat fasih menjawab semua pertanyaan Anda. Mereka punya pitch deck, punya case study, dan punya jawaban manis untuk semua kekhawatiran Anda.

Masalahnya, pertanyaan yang paling penting sering kali tidak pernah ditanyakan. Bukan karena Anda lupa, tapi karena Anda tidak tahu bahwa pertanyaan itu seharusnya diajukan.

Artikel ini dirancang sebagai checklist. Tujuh pertanyaan yang langsung menguak apakah vendor yang sedang Anda evaluasi benar-benar paham apa yang bisnis Anda butuhkan, atau hanya bisa deliver yang ada di proposal saja.

1. Bagaimana Alur Komunikasi Resmi Kalau Ada Masalah Urgent?

Pertanyaan ini terdengar sederhana, tapi jawaban atas pertanyaan ini membedakan vendor yang professional dari vendor yang akan membuat Anda frustrasi dalam tiga bulan ke depan.

Vendor yang baik akan punya escalation matrix yang jelas: siapa yang Anda hubungi kalau server down di tengah malam, siapa decision maker yang bisa approve hotfix tanpa harus tunggu email balasan selama dua hari, dan berapa response time yang bisa Anda harapkan untuk setiap level severity.

Yang perlu Anda catat adalah detail spesifik, bukan jawaban general seperti "kami punya tim support 24/7." Minta mereka jelaskan secara konkret: siapa nama orangnya, jam berapa mereka tersedia, dan apa langkah yang akan mereka ambil dalam satu jam pertama setelah laporan masalah masuk.

Vendor yang tidak bisa menjawab pertanyaan ini dengan spesifik kemungkinan besar tidak punya operational process yang mature. Mereka improvise saat masalah terjadi, dan Anda adalah orang yang akan merasakan consequences dari improvisation tersebut.

2. Siapa yang Akan Benar-Benar Kerja di Proyek Saya?

Ini pertanyaan yang sangat sering diabaikan. Dalam proposal, vendor akan menampilkan foto-foto senior developer dan senior consultant. Dalam kenyataan, orang yang bekerja di proyek Anda bisa jadi berbeda.

Tanyakan langsung: apakah developer yang assign ke proyek ini sudah fix atau masih bisa berubah? Siapa project manager yang akan jadi kontak utama? Bagaimana mekanisme jika salah satu anggota tim perlu diganti?

Jawaban yang bisa dipercaya biasanya datang dengan detail kontrak yang jelas: mereka tidak akan mengunci Anda dengan satu nama orang tertentu, tapi mereka punya proses onboarding untuk pengganti yang memastikan knowledge transfer terjadi dengan baik.

Vendor yang defensif atau evasive saat ditanyakan pertanyaan ini adalah red flag yang harus dicatat.

3. Bagaimana Definisi "Selesai" dalam Proyek Ini?

Scope yang tidak jelas adalah sumber konflik paling umum dalam hubungan client-vendor. Tanpa definisi "done" yang disepakati di awal, vendor bisa klaim proyek selesai sementara Anda merasa masih banyak yang kurang.

Tanyakan: apa saja deliverables yang termasuk dalam scope? Apakah dokumentasi teknis termasuk dalam criteria completion? Apakah ada fase testing yang formal? Siapa yang punya authority untuk menyatakan suatu deliverable acceptable atau perlu revisi?

Vendor yang baik akan langsung menjelaskan hal ini dan bahkan menyarankan kerangka acceptance criteria sebelum kontrak ditandatangani. Mereka tidak takut pada detail karena mereka sudah terbiasa bekerja dengan scope yang jelas.

4. Bagaimana Penagihan Jika Scope Berubah di Tengah Jalan?

Setiap proyek IT pasti ada perubahan scope. Pertanyaan bukan apakah perubahan akan terjadi, tapi bagaimana perubahan tersebut dikelola dan ditagihkan.

Tanyakan prosedur formal untuk perubahan scope: apakah ada change request process? Apakah ada baseline budget yang bisa dilacak? Berapa rate per jam atau per hari yang berlaku untuk pekerjaan di luar scope original?

Yang perlu Anda waspadai adalah vendor yang terlalu cepat bilang "flexible" atau "bisa negotiation" tanpa kerangka yang jelas. Flexibility tanpa process adalah jalan pintas menuju tagihan yang tidak terduga.

5. Bagaimana Pendekatan Mereka Terhadap Dokumentasi dan Knowledge Transfer?

Dokumentasi adalah hal yang paling sering dikorbankan saat timeline mepet atau budget menipis. Vendor yang tidak punya kebiasaan mendokumentasikan pekerjaannya akan meninggalkan Anda dalam situasi yang sangat sulit di akhir kontrak.

Tanyakan: apa saja dokumentasi yang akan Anda terima di akhir proyek? Apakah ada inline comments di kode? Apakah ada architecture diagram? Siapa yang menulis user manual dan technical documentation?

Pertanyaan lanjutan yang sangat penting: bagaimana kalau di tengah kontrak Anda perlu melakukan transition ke vendor lain? Apakah mereka mau membantu knowledge transfer? Berapa lama transition period yang mereka rekomendasikan?

Vendor yang benar-benar percaya diri dengan kualitas pekerjaan mereka biasanya tidak takut pada pertanyaan ini. Mereka bahkan akan mendorong untuk ada knowledge transfer yang proper karena itu menunjukkan profesionalisme mereka.

6. Apa Saja Risiko Utama Proyek Ini Menurut Analisis Vendor?

Pertanyaan ini membunuh dua burung dengan satu batu. Pertama, Anda mendapatkan visibility terhadap risiko yang mungkin tidak Anda sadari. Kedua, Anda mengetes apakah vendor benar-benar mengerti domain bisnis Anda atau hanya menjalankan template yang sama untuk semua client.

Jawaban yang lemah biasanya berupa daftar risiko generik: "risiko dari perubahan requirement," "risiko dari timeline yang tidak realistis." Jawaban yang kuat akan menyebutkan risiko spesifik yang relevan dengan konteks bisnis Anda: misalnya risiko integrasi dengan sistem legacy tertentu, atau risiko jika pengguna utama tidak terlibat di fase testing.

Vendor yang melakukan risk analysis yang proper biasanya juga punya mitigation plan yang konkret. Mereka tidak hanya menyebut risiko tapi juga sudah memikirkan langkah contingency.

7. Berapa Nilai Kontrak Ini Dibandingkan dengan Industri, dan Mengapa?

Pertanyaan ini memaksa vendor untuk memposisikan harga mereka dalam konteks pasar. Apakah harga yang mereka minta di bawah rata-rata, sesuai, atau di atas? Dan yang lebih penting, kenapa?

Kalau harga jauh di bawah rata-rata industri, tanyakan apa yang mereka korbangi untuk sampai bisa menawarkan harga sekecil itu. Biasanya yang dikorbankan adalah kualitas developer, waktu yang dialokasikan, atau tingkat testing yang dilakukan.

Kalau harga di atas rata-rata, tanyakan apa yang membuat mereka berani minta premium tersebut. Jawaban yang bisa dipercaya biasanya disertai dengan proof point: tim dengan certified engineers, track record dengan perusahaan sejenis, atau metodologi proprietary yang sudah teruji.

Harga yang terlalu murah sama berbahayanya dengan harga yang terlalu mahal tanpa alasan yang jelas. Tujuan Anda adalah memahami value, bukan mencari yang termurah atau termahal.

Kesimpulan

Tujuh pertanyaan di atas bukan pertanyaan yang sulit. Tidak ada yang memerlukan jawaban teknis yang kompleks. Semua bisa dijawab dengan detail proses yang straightforward.

Yang membuat tujuh pertanyaan ini powerful adalah mereka menggali detail yang biasanya tidak muncul di tahap proposal. Detail yang menentukan apakah pengalaman bekerja dengan vendor akan smooth atau penuh konflik.

Kalau Anda merasa tidak punya waktu untuk tujuh pertanyaan ini karena terburu-buru mulai proyek, pertimbangkan ini: waktu yang Anda gunakan untuk due diligence sekarang akan menghemat waktu berminggu-minggu untuk remediation nanti.

Next IT menyediakan konsultasi gratis untuk bisnis yang sedang dalam proses evaluasi vendor IT outsourcing. Kami bisa bantu simulate proses due diligence ini bersama tim Anda, mengidentifikasi celah di proposal yang sudah Anda terima, dan memberikan perspective dari sisi vendor tentang apa yang perlu diperhatikan.

Tidak ada komitmen sebelum diskusi selesai. Hubungi kami via WhatsApp untuk scheduling.