Seorang direktur pengelola (managing director) sebuah perusahaan consumer goods beromset Rp 1,2 triliun/tahun sempat curhat kepada SWA soal kegagalan perusahaannya membangun aplikasi TI. Perusahaan makanan-minuman yang dipimpinnya dirasakan sudah membutuhkan sistem TI baru yang lebih canggih, terintegrasi, dan berkemampuan lebih besar guna menopang usahanya yang tumbuh fantastis. Namun apa lacur, selama dua tahun proyek pencarian dan pengembangan aplikasi baru itu dijalankan, hasilnya masih nihil.
Di tahun pertama pencariannya, perusahaan ini sempat mencoba membeli paket aplikasi joint development dari software house multinasional. Ternyata, setelah dicoba dipasang selama 9 bulan, hasilnya tak sesuai dengan harapan. Banyak fiturnya yang tak sesuai dengan kebutuhan riil operasional bisnis perusahaan. Sebaliknya, beberapa fitur yang diharapkan kenyataannya sulit dikembangkan meski sudah coba dikustomasi (customized). Seperti patah arang dengan vendor software multinasional itu (berikut konsultan implementornya), tiga bulan kemudian perusahaan consumer goods itu membuat keputusan drastis: tak lagi berhubungan dengan vendor dan memakai aplikasinya, malah kemudian memilih membangun aplikasi sendiri dengan mengandalkan tim TI internal (in-house development).
Kendati begitu, lagi-lagi hasilnya sangat jauh dari harapan. Memang, masing-masing modul aplikasi yang dibangun sendiri itu sesuai dengan kebutuhan bisnis masing-masing departemen. Akan tetapi celakanya, modul-modul itu sulit diintegrasikan. Tak heran, hingga awal November lalu — berarti sudah 9 bulan pengembangan aplikasi oleh tim internal — kondisinya masih carut-marut: tidak terintegrasi dan data-data yang ditransaksikan tidak real time. Padahal, Rp 5 miliar lebih telah dihabiskan untuk mendanai proyek ini. Atas kegagalan ini, sang direktur pengelola merasa sangat tak enak hati dengan preskom. Cuma karena kebetulan masih terhitung bersaudara, dua kali kegagalan pengembangan aplikasi TI tersebut tak sampai berujung pemecatan dirinya.
Sebenarnya, ada pola pengembangan aplikasi dengan risiko minimal, yakni joint development. Dengan pola ini, perusahaan klien bisa duduk bareng dengan konsultan –tepatnya developer – yang dipercaya untuk membangun aplikasi yang dinilai sesuai dengan kebutuhan perusahaan. Praktik seperti ini sudah dilakukan oleh beberapa perusahaan lokal, terutama dari kalangan sektor keuangan dan farmasi.
PT Bank Syariah Mandiri (BSM) adalah salah satu perusahaan lokal yang mengembangkan berbagai aplikasi dengan pola joint development. Dalam hal ini BSM menggandeng PT Sigma Cipta Caraka sebagai konsultan/pengembangnya. Aplikasi syariah banking tepatnya dikembangkan BSM bersama Sigma tahun 2000 dan sampai sekarang masih terus digunakan.
Syafrizal, mantan Kepala Divisi TI BSM yang kini menjabat staf khusus direksi bidang Electronic Banking Channel menjelaskan, BSM merupakan konversi dari Bank Susila Bhakti, beserta aplikasi-aplikasi lamanya yang dinilai tak lagi bisa dipertahankan. Kebetulan Sigma waktu itu menawarkan pembuatan aplikasi syariah banking. “Lalu, kami mengusulkan sebaiknya melakukan joint development supaya antara BSM dan Sigma ada win-win solution,†Syafrizal menjelaskan.
BSM sendiri memilih pola joint development karena beberapa alasan. “Terutama, melihat kesiapan dan kebutuhan fitur-fitur yang diinginkan, kesiapan implementasi dan juga kesiapan internal BSM,†lanjut Syafrizal. Alasan lain, di tahun 2000 itu, BSM relatif baru beroperasi, sehingga merasa berat untuk membeli paket software yang harganya amat mahal. “Kami nggak mau anggaran habis untuk membeli paket aplikasi yang mahal,†ia menegaskan.
Kala itu, sambung Syafrizal, memang ada beberapa vendor yang menawarkan paket aplikasi ke BSM. Namun semuanya dengan kisaran harga di atas US$ 1 juta. Padahal, angka sebesar itu baru untuk harga software, belum biaya implementasinya yang juga cukup mahal. Karena itulah BSM kemudian memilih membangun aplikasi bareng Sigma. Berhasil diselesaikan dalam 6 bulan, modul terpenting aplikasi syariah banking hasil garapan bareng ini punya dua modul utama, yakni: Modul Lending (untuk urusan penyaluran pinjaman) dan Modul Funding (untuk pengelolaan dana masyarakat).
Contoh lainnya, PT Asuransi Wahana Tata (Aswata). Eddy Chandra, Direktur Keuangan yang juga penanggung jawab TI di Aswata menjelaskan, perusahaannya mulai membangun aplikasi dengan pola joint development pada 2002. Manajemen Aswata meyakini, yang tahu persis bisnis Aswata serta proses-proses dan kebiasaan bisnis di dalamnya hanyalah orang Aswata sendiri. “Kami melihat itu sebagai keunggulan yang harus kami pertahankan dalam implementasi TI,†tutur Eddy. Di sisi lain, mereka merasa tak punya kompetensi di bidang TI. Dengan joint development, selain pengembangan aplikasinya bisa dibantu konsultan, keunggulan dan ciri khas proses-proses bisnis yang dimiliki Aswata dapat dipertahankan, bahkan dimodernisasi dengan sistem baru.
Menurut Eddy, dipilihnya joint development itu juga hasil pengalaman sebelumnya. Maklum, sebelumnya Aswata pernah mengembangkan aplikasi sendiri, tanpa bantuan konsultan. Waktu itu Aswata punya tim pengembang aplikasi sendiri dan berusaha membuatnya sendiri. Toh, dalam praktiknya butuh waktu terlalu panjang. Selain itu, setelah diimplementasi ternyata banyak ditemui kekurangan.
Sebelumnya, Aswata juga sempat ditawari beberapa paket aplikasi jadi, baik dari vendor asing (Singapura dan Australia) maupun lokal. “Tapi setelah kami teliti, kami punya pandangan bahwa kebiasaan dalam berbisnis asuransi ini yang lebih tahu ya kami sendiri. Makanya kami memilih memakai joint development,†ujar Eddy. Toh, untuk penentuan mitranya, menurut Eddy, dilakukan lewat tender, yang dimenangi oleh Sigma. Bersama perusahaan pengembang lokal ini, Aswata telah membangun seluruh aplikasi utama yang dibutuhkan dalam bisnis asuransi, mencakup Modul Pemasaran, Underwriting, Keuangan, Akuntansi dan Reasuransi.
Selain Sigma, konsultan/developer yang cukup rajin membantu pengembangan aplikasi dengan pola joint development adalah PT Mitra Integrasi Informatika (MII), anak usaha Metrodata. “Kami kini punya dua paket aplikasi jadi yang dulu dikembangkan dengan joint development,†tutur Aloysius Pratomo, Manajer Bisnis MII. Kedua aplikasi itu ialah Mosaic Monitor yang ditujukan untuk divisi penjualan (terutama di perusahaan farmasi) dan Mosaic Purchasing yang ditujukan untuk divisi pembelian (tak hanya untuk perusahaan farmasi). Kebetulan, dua klien MII yang dulu mengembangkan aplikasi itu dengan pola joint development adalah perusahaan farmasi multinasional. “Karena di pasaran tak menemukan aplikasi yang diinginkan, akhirnya mengajak kami untuk joint development,†papar Pratomo yang enggan menyebut nama dua kliennya itu.
Meski relatif baru dipraktikkan, pola joint development memang bisa menjadi solusi alternatif pengembangan aplikasi. Sejauh ini, alasan mengapa joint development dipilih, cukup beragam. Merujuk pada kasus klien MII tadi, yakni karena tak ada software jadi yang cocok dengan kebutuhan perusahaan. Bisa juga karena paket software jadi yang ada di pasaran butuh kustomasi terlalu banyak.
Pratomo menjelaskan, bagi perusahaan klien, joint development sangat menguntungkan karena klien bisa mengontrol apa yang mereka inginkan. “Mereka juga bisa membangun suatu proses yang berbeda dari perusahaan lain sehigga bisa lebih kompetitif. Kalau aplikasi paket jadi, apalagi dari luar, untuk dibuat penyesuaian yang sedikit nyleneh biasanya sulit,†papar lulusan Teknik Elektro Universitas Gadjah Mada ini. Tak hanya itu, dalam praktik joint development, biasanya source code dari aplikasi itu juga diberikan ke pihak klien. Maka, bila dalam perkembangan ingin mengubah beberapa fitur, bisa dilakukan sendiri oleh klien, karena sudah memegang source code-nya. “Jadi, dengan joint development, klien tak terlalu tergantung pada vendor,†Pratomo menegaskan. Adapun dari sisi waktu, bisa bisa lebih cepat tapi bisa pula lebih lama. Bukankah membeli paket jadi pun biasanya butuh waktu untuk kustomasi yang tidak sebentar.
Alasan lain yang juga penting adalah penghematan biaya. Diakui Eddy, pihaknya butuh dana lumayan besar untuk mengembangkan aplikasi secara menyeluruh dan terintegrasi. Kendati begitu, kalau dibandingkan dengan membeli paket aplikasi jadi dari luar — dan perubahan-perubahan yang diperlukan – masih lebih murah joint development. Sinyalemen Eddy dibenarkan Oktavianus Nicolaus, Manajer Pengembangan Aplikasi MII. “Kami biasanya memberikan harga lebih murah. Kami sacrifice karena menganggapnya sebagai investasi,†ujar Oktavianus. Ia menambahkan, biasanya klien hanya bayar 60%-70% dari harga sesungguhnya. Berdasarkan pemantauan SWA, membeli paket aplikasi jadi untuk korporat, khususnya dari vendor asing, rata-rata dibutuhkan lebih dari US$ 1 juta. Sementara dengan pola menggarap bareng, anggarannya masih di bawah US$ 500 ribu. “Namun segalanya tetap tergantung pada kompleksitas proyek itu sendiri,†tukas Djarot Subiantoro, Presdir PT Sigma Cipta Caraka, meluruskan.
Yang tak kalah menarik, dengan joint development, klien ternyata berpeluang memperoleh bagian kompensasi dari penjualan aplikasi yang dibuat secara bersama-sama. Maklum, dengan pola ini, tak tertutup kemungkinan property rights aplikasi akhirnya dimiliki berdua, oleh pengembang ataupun perusahaan klien. Jadi, kalau sewaktu-waktu aplikasi itu dijual dan dipakai oleh perusahaan lain, klien pertama yang dulu dijadikan pilot project, bisa memperoleh bagian sejumlah uang. Akan tetapi, tergantung pula pada negosiasi kedua pihak. “Joint development adalah hubungan kemitraan dan kesepakatan, sehingga sangat fleksibel untuk dinegosiasikan kedua pihak,†ujar Djarot yang memimpin 600-an orang SDM TI di Sigma.
Manajemen BSM termasuk yang mendapatkan bagian dari proyek joint development. “Kami sebagai pemikir bisnisnya (brainware) dan mereka sebagai programernya. Wajar bila aplikasi ini dijual ke bank lain maka kami diberi lisence fee sebagai bagian dari property rights,†ujar Syafrizal. Di BSM, lanjut Syafrizal, dalam klausul kerja sama terang-terangan disebutkan kalau aplikasi dijual, BSM wajib diberikan fee berdasarkan persentase tertentu. Djarot menyambung, soal fee pengembalian ini terkait dengan harga proyek yang ditetapkan pula. Tak heran di sini variasi kerja sama antara vendor-klien bisa bermacam-macam.
Cara pertama, klien joint development tak mendapatkan fee penjualan aplikasi, tapi harga proyek pengembangannya dipatok jauh lebih murah dari harga pasaran. “Ada klien yang bilang ke kami, you boleh jual aplikasi ini dan kami tak dapat fee nggak apa-apa, asal you jualnya setelah setahun kami pakai karena ini merupakan keunggulan kompetitif perusahaan,†ungkap Djarot menirukan ucapan kliennya. Sejumlah klien juga rela menggunakan pola ini karena kalau aplikasi dijual massal, biaya support aplikasi menjadi lebih murah. Pola lain adalah dengan memberikan royalty fee. Namun karena bank tak boleh menerima royalti, maka Sigma menyebutkannya sebagai pengembalian investasi.
Kendati banyak keuntungan yang bisa dipetik, agar program ini sukses memang butuh kiat tersendiri. Pratomo menjelaskan, berdasarkan pengalamannya setidaknya ada tiga tahap dalam pelaksanaan joint development. Pertama, tahapan studi definisi, di mana tugas utama vendor/pengembang mendefinisikan kebutuhan klien dan membuat blue print kebutuhan proses bisnis yang bakal diotomasi. “Kami harus banyak ngrobrol dua arah,†katanya. Biasanya, dalam tahapan ini timnya terdiri dari analis bisnis, yang didampingi orang teknik dari MII. Sementara dari pihak klien dipilih beberapa orang – sebaiknya key user – yang dipercaya mewakili rekan-rekannya. Output kerja tahapan pertama ini adalah desain spesifikasi fungsional, yang isinya mengenai kesepakatan fungsi-fungsi yang dibutuhkan. Kalau lancar, tahapan ini biasanya selesai dalam sebulan.
Tahap kedua fase implementasi. Fase ini amat penting karena di sinilah programer bekerja. Hasil kerja analis bisnis dalam dokumen spesifikasi fungsional itu kemudian dibaca oleh arsitek software. Mereka inilah yang menerjemahkannya ke dalam bahasa teknik. “Arsitek software ini yang menjembatani ke arah teknis agar mudah dimengerti para programer,†ujar Pratomo seraya menjelaskan kalau lancar tahapan ini selesai kurang dari empat bulan. Tahapan ini biasanya dikerjakan di kantor vendor.
Tahapan ketiga adalah realisasi, di mana tim TI dari vendor melakukan pemasangan (deployment) aplikasi yang sudah dibuat para programer. Juga, sambil mencocokkan apa saja yang dulu dibutuhkan dan mungkin saja dilakukan perubahan karena adanya additional feature. Termasuk melakukan pengetesan terhadap aplikasi yang dibuat, dan ada pula dukungan program stabilisasi dari vendor.
Djarot menambahkan, dalam mengembangkan aplikasi dengan pola joint development biasanya pihaknya melibatkan sebanyak mungkin orang yang tahu bisnis. Jadi, tak hanya vendor dan klien. Contohnya dengan memanggil konsultan bisnis yang paham sektor bisnis yang akan dilayani. “Konsultan bisnis tahu teorinya, klien tahu bisnisnya, dan kami tahu teknologinya,†ucap Djarot. Ia menambahkan, pemilihan konsultan biasanya disepakati bersama klien. Djarot mencontohkan, sewaktu melaksanakan joint development aplikasi syariah banking, pihaknya melibatkan konsultan, Dewan Syariah Nasional, dan Bank Indonesia.
Dalam praktik joint development, ternyata masih sering muncul kendala. Di Aswata, contohnya, disebutkan Eddy, paling sulit mencocokkan antara kebutuhan yang diinginkan kalangan bisnis dengan bahasa teknologi. “Kadang menurut kami yang bagus begini sementara orang teknik bilang lain. Mencocokkan ini yang paling sulit,†ujar Eddy. Di BSM, seperti diakui Syafrizal, dulu juga ditemui berbagai kendala. Antara lain, karena waktu itu BSM masih baru, maka jumlah tim yang dimiliki terlalu sedikit. Akibatnya waktu penyelesaian proyek aplikasi agak mulur. Pasalnya, anggota tim yang membantu proses joint development, selain bertugas memberikan masukan business requirement buat aplikasi, juga bekerja seperti biasa di divisi operasional masing-masing.
Ternyata hambatan seperti terjadi di BSM juga dialami Pratomo. Menurut pengalamannya, setelah aplikasi jadi, kadang muncul komplain dari klien karena tidak sesuai dengan yang mereka harapkan. Padahal, lanjut Pratomo, hal ini sering disebabkan key user yang ditugaskan untuk terlibat dan memberikan masukan seputar kebutuhan bisnis juga masih bekerja seperti biasanya, sehingga mereka sering tak konsentrasi. “Tak jarang, mereka kurang serius. Padahal ini akan digunakan jangka panjang,†ucapnya. Maka, ia menyarankan, ada baiknya tim di unit bisnis yang dilibatkan dalam proses joint development juga diberikan reward and punishment. “Jadi, proyek itu juga merupakan tugasnya. Kalau sukses diberi penghargaan. Ini butuh dukungan pimpinan,†tandasnya.
Pratomo melihat, bagi para vendor aplikasi seperti MII, pola joint development cukup menguntungkan karena merupakan proyek investasi. Alasannya, ini merupakan sumber pengetahuan untuk membangun aplikasi yang kelak bisa dijual ke perusahaan lain. Sementara itu, Djarot yang telah menjalankan joint development sejak 1989, melihat dari sisi industri banyak manfaat yang bisa dipetik. Salah satunya, aplikasi hasil joint development lebih murah daripada paket aplikasi jadi dari luar negeri. Tak heran, sekarang banyak paket aplikasi luar negeri yang kemudian menurunkan harga jualnya setelah pemain lokal banyak melakukan joint development. Ia menggambarkan, ketika membuat aplikasi perbankan secara joint development tahun 1989, paket dari luar harganya sekitar US$ 1 juta, sementara Sigma menjual hanya dengan US$ 200 ribu.
Sigma sendiri sejauh ini memang dikenal sebagai pionir pola joint development di Indonesia, khususnya aplikasi perbankan, multifinance, asuransi, dan syariah banking. Sudah ada 6 aplikasi korporat yang dibangun Sigma dengan pola ini, sedangkan pengguna aplikasinya lebih dari 30 lembaga. Bagi Djarot, selama ini yang paling sulit justru mencari klien yang mau diajak sebagai pilot project untuk melakukan joint development. “Kebanyakan awalnya mereka nggak mau diajak. Tapi begitu sudah ada yang sukses, yang lain lebih mudah, karena sudah ada referensi,†tuturnya.
