Transition Problems

Hingga saat ini saya masih sering mengalami problem dengan fase transisi dalam software development. Saya sudah baca beberapa referensi dan belajar dari teman-teman, tapi sepertinya juga masih kurang berhasil.

Fase transisi pada prinsipnya adalah masa peralihan (transisi) dari masa pengembangan (development) oleh developer ke masa operasional (go live) yang digunakan oleh users. RUP juga memiliki definisi akan fase ini yang mirip. Pada fase ini biasanya secara umum dilakukan pelatihan pada pengguna software dan dilakukan aktivitas user acceptance test, untuk mencapai kesepakatan antara developer dan user.

Inti problemnya, sering sangat sulit untuk melepaskan kebergantungan dari user dalam mengoperasikan software dari developer (hm, tentu saja saya sedang bicara tentang enterprise software/apps, bukan packaged software).

Biasanya problem-problem itu disebabkan :

• Ketidakmapanan proses bisnis. Hm karakter alami dari organisasi itu selalu dinamis dan berkembang. Dengan demikian proses bisnisnya (prosedur, workflow, tatacara, dst) juga biasanya ikutan berubah. Jika developer tidak pintar-pintar dalam menggali hal-hal ini, dan menemukan solusi yang fleksibel, ini bisa jadi problem. Dalam sisi yg berlawanan, jika tidak ada komitmen dari organisasi tsb (terkait e-leadership) juga bisa memperparah situasi. Ini jadi masalah di fase transisi jika terjadi perubahan besar pada masa ini (dan akhirnya tidak kompatibel lagi dengan softwarenya). Solusinya ? secara teknis harus menciptakan customizable/flexible software. Software yang bisa dengan mudah dikustomisasi, dikonfigruasi, diubah-ubah. Sejauh apa ? entah juga, mungkin bisa create report dengan kolom2 yang bisa dipilih2, diedit, pilihan sumber data yang beragam dst. Desain bisa diganti-ganti dst.
• Tidak ada yang melanjutkan tongkat estafet. Dalam konteks ini yang mengoperasikan software, terutama administrator (termasuk DBA). Banyak organisasi yang beranggapan "jika saya beli software tertentu, maka saya tinggal tunggu jadi, dan bisa jalan sendiri". Wow, tentu ini masalah besar. Kalau beli mobil aja, kadang kita perlu tau dikit2 'ilmu montir' hehe (setidaknya tau gimana cara ganti ban). Betul ? nah, pemilik software juga harus seperti itu. Setidaknya ada yang tau database, ada yang tau server/OS, dan ada yang tau project management sehingga kelak bisa menerima tongkat estafet dengan smooth.
  
• Problem dengan data. Validasi data menjadi isu utama dalam proses konversi atau entri data. Kadang, proses ini jika tidak termanage dengan baik, akan muncul problem besar saat validasi data. Apalagi jika proses transisi ini berlarut-larut, sementara itu siklus data sangat cepat berubah.
  
• Strategi transisi yang salah. Segala kegiatan pelatihan dalam masa ini seharusnya bertujuan agar user tidak sekedar hanya bisa menggunakan software, tapi juga bisa mengintegrasikannya dengan proses bisnisnya. Tidak hanya belajar bagaimana cara membuat jurnal dalam modul accounting (misalnya), tapi juga menyiapkan strategi operasional bagaimana itu bisa terintegrasi dengan existing workflows (SOPs). Ini yang kadang dilupakan oleh project manager atau konsultan. Atau mungkin strateginya nggak pas.

Transisi merupakan fase terakhir dalam sikus implementasi software (hampir semua metodologi), namun kadang ini justru menjadi 'ganjalan' yang cukup besar dan bahkan bisa jadi menggagalkan seluruh aktivitas sempurna sebelumnya. Ini pengalaman pahit yang beberapa kali saya rasakan dan mungkin juga para newbie lainnya dalam dunia software.

Mungkin anda punya kisah sejenis atau success story ? silakan disharekan di lembar komentar. ^_^

Implementasi Enterprise System

Apakah itu enterprise system (selanjutnya disingkat ES)? Dalam konteks tulisan saya berikut, istilah ini mengacu pada sistem berbasis software untuk membantu pengelolaan sistem informasi pada suatu organisasi dengan skala besar. Skala besar berarti volume transaksi yang besar, concern terhadap kualitas informasi yang tinggi, mengintegrasikan berbagai proses bisnis, lintas bidang (horisontal) maupun lintas strata (vertikal). Contoh dari ES adalah ERP (Enterprise Resource Planning) atau e-Business secara umum, e-Government, dan ingrated software lainnya.

Implementasi
Mengimplementasikan ES tidak mudah, atau setidaknya memilki strategi yang berbeda dengan sistem lain yang terbatas ruang lingkupnya, penggunanya dan tidak terpadu. Implementasi di sini bermakna bahwa software telah dapat digunakan dan bisa memberikan value bagi penggunanya sesuai tujuan pemanfaatan software tsb. Implementasi ini bisa dilakukan secara internal organisasi (oleh divisi IT/MIS) atau dengan pihak eksternal dalam kerangka proyek dan terikat legalitas berbentuk kontrak.

Catatan : Supaya memudahkan pemahaman dalam membaca artikel ini, saya mengistilahkan implementator sebagai pihak eksternal yang melakukan implementasi dan klien sebagai organisasi yang diimplementasikan softwarenya.

Implementasi ES berbeda dengan implementasi software berskala kecil atau yang penggunanya tunggal seperti MS Word, Database Rental VCD atau website, meskipun produknya sama-sama software yang berjalan di atas server dan membutuhkan konektivitas.

Ini sama seperti analogi berikut : Seorang insinyur sipil terbiasa membangun rumah tipe 70 selama 3 bulan, dengan jumlah kuli bangunan dan mandornya sekitar 10 orang. Nah, untuk membangun sebuah gedung berlantai 20 yang sizenya sekitar 100 kali dari rumah sederhana tadi, tentu tidak cukup dengan hanya mengalikan waktu dan sumber daya yang dibutuhkan, bukan?

Tentu nanti ada strategi yang berbeda, metode pemilihan bahan yang berbeda, tahapan yang berbeda, standar-standar tertentu, dst. Demikian pula dalam konteks software, bisa dipilah berdasar cakupan penggunaannya, bisa dilihat juga dari jenisnya (generik dan customized), yang masing-masing punya strategi implementasi yang berbeda.

Ini yang saya lihat sering tidak disadari oleh para newbie atau mungkin juga tidak disadari oleh sebagian besar organisasi di Indonesia, terutama pemerintahan atau UKM. Tak heran seperti diungkap pada hasil penelitian Standish Group yang sangat legedaris, bahwa sebagian besar proyek IT (khssusnya software) di US itu gagal. Apalagi di Indonesia, banyak kantor pemerintah memberikan pekerjaan pengembangan sistemnya seperti halnya memesan website atau bahkan MS Office! cenderung memperlakukan software sebagai ”barang”. Saya lihat produk anda sekilas, saya beli, saya minta anda pasangkan dan latihkan cara menggunakannya. Selesai.
SE tidak bisa diperlakukan dengan cara seperti itu, tidak sekedar jual-beli dan pasang-bongkar barang, SE berkaitan dengan pengelolaan sistem informasi, yang tidak hanya bicara teknologi saja, tapi berkaitan dengan proses bisnis, struktur organisasi dan manusianya.

Pola Pikir

Dari pengamatan saya, banyak implementator yang memposisikan diri sebagai ”developer” ataupun ”project manager”. Sebetulnya, IMO ini kurang pas. Mengapa?

Pola pikir ”developer” adalah menganggap suatu problem bisa selesai dengan solusi berbasis software yang baik dan tepat. Tapi apakah cukup seperti itu? Dalam membangun solusi, ya itu cukup, tapi belum tentu menjamin kesuksesan implementasi. Pola pikir developer cenderung berfokus pada analisis dan development tidak pada implementasinya. Padahal sukses tidaknya proyek software, baik buruknya reputasi implementator, seringkali orang luar melihat pada keberhasilan implementasinya dan value yang didapatkan klien.

Jika klien adalah perorangan atau organisasi kecil yang jumlah penggunanya kurang dari 10 orang, mungkin tidak masalah. Tapi kita saat ini sedang bicara ES untuk organisasi dengan puluhan divisi, ribuan orang, puluhan kepentingan, dan mungkin ratusan konflik. Apalagi jika software yang kita implementasikan bukan sekedar supporting tools tapi adalah core dari bisnis itu sendiri (konsep e-business). Cara implementasi dengan pola pikir seperti ini hanya akan menghasilkan solusi dan software yang bagus, tapi tidak optimal dan memberikan value untuk organisasi tsb, atau bahkan malah tidak pernah akan digunakan.

Pola pikir kedua adalah sebagai ”project manager”. Ini menurut saya juga kurang tepat. Implementator tidak bisa memposisikan diri sebagai project manager pada sebuah proyek yang berkaitan langsung dengan proses bisnis internal klien. Seorang project manager harus mampu mengelola semua resource berkaitan dengan proyek. Kadang kita tidak menyadari bahwa sebagaian besar resource dari proyek software justru berada di sisi organisasi klien. Sementara, project manager seharusnya memiliki akses ke seluruh resource tersebut, karena jika tidak, itu bukan project manager namanya. Dalam kasus ini, maka project manager seharusnya justru berada di sisi klien, bukan implementator. Akan sia-sia jika aktivitas project planning, project controlling dsb sepenuhnya dilakukan oleh implementator, sementara klien hanya ”tahu beres” saja. Pada akhirnya aktivitas-aktivitas project management tsb hanya akan menghasilkan berkas-berkas dan dokumen administratif saja, yang pada kenyataannya tidak pernah dilaksanakan.

Menurut saya, peran yang paling pas untuk implementator adalah sebagai konsultan. Tugas utama dari konsultan adalah memberikan informasi, mendampingi, memfasilitasi dan menjadi motor ”behind the screen”. Tentu saja jika kontraknya melibatkan pengadaan software, konsultan juga akan melakukan development atau implementasi secara teknis, namun implementasi keseluruhannya harus dipimpin oleh klien sendiri melalui project manager. Jika klien tidak memiliki pengetahuan yang cukup untuk mengelola proyek software, itulah tugas konsultan untuk mendampinginya, sehingga proses project planning, control, evaluation, dst sepenuhnya akan berasal dari ide-ide, komitmen dan effort dari klien sendiri. Tugas konsultan adalah memfasilitasi dan mengarahkannya. Model seperti ini yang kemudian memunculkan teknik JAD (Joint Application Design), yang intinya adalah melibatkan dan kolaborasi seluruh stakeholder proyek.

Mengapa pola pikir ini cenderung tepat, karena salah satu fase dalam implementasi sistem adalah fase transisi, yang pasti akan menuntut perubahan baik kecil maupun besar. Adanya sistem baru, mau tidak mau akan merubah proses bisnis. Perubahan proses bisnis berarti perubahan cara kerja, alur kerja dan bahkan budaya kerja. Perubahan ini menyangkut aspek people dan proses bisnis, sehingga dikenal konsep change management. Dalam eksekusinya, change ini harus dipimpin dan dimanage oleh leader di internal organisasi.

Analoginya adalah sbb. Seorang pasien berobat ke dokter. Di sini ”proyek”-nya adalah penyembuhan. Dokter berperan sebagai konsultan proyek, sementara yang menjadi project manager adalah pasien itu sendiri. Dokter hanya memberikan obat, saran tentang pantangan dst, namun eksekusi dari penyembuhan tetap berada di tangan pasien, karena pasien sendirilah yang bisa mengontrol pola makannya, mengikuti anjuran dokter, dsb. Obat di sini berlaku seperti halnya solusi software. Apa yang terjadi jika dokter hanya memberikan obatnya begitu saja, sementara pasien tidak mau peduli dengan anjuran bedrest ?

Konsekuensi
Konsekuensi dari pemilihan peran konsultan ini juga banyak, namun tidak dibicarakan dalam tulisan ini. Tentu saja yang paling jelas adalah terkait SDM. Kualifikasi seorang konsultan tentu berbeda dengan developer atau project manager. Yang jelas seorang konsultan tidak hanya dituntut memiliki pengetahuan tentang software engineering dan hal-hal teknis, dan juga tidak cukup ditambah dengan pengalaman dan keterampilan project management, namun konsep dan bestpractice tentang change management, communication skill yang excellent sangat diperlukan. Selain SDM, di sisi legal seharusnya juga berbeda. Apakah kontrak dengan model fix-cost masih pas diterapkan di sini? Jika tidak, yang seperti apa.

Dalam konteks apapun, strategi dibuat berdasarkan analisis, sehingga kejelian implementator dalam melihat karakter software menjadi sangat penting. Karena jika salah, pasti strategi yang dibuat juga tidak akurat. Strategi yang tidak akurat, akan menjadi bencana dalam pelaksanaannya. Efek domino!

Berubah

Merubah karakter itu sulit juga ya ? kebetulan saat ini saya berhadapan dengan masalah ini.

Saya termasuk orang yang sangat suka dengan perencanaan, segala aktivitas selalu saya rencanakan lebih dulu. Setiap pagi mungkin sudah tergambar apa saja yang akan saya lakukan sampai malamnya. Ini mungkin turunan dari orang tua juga. Papa saya karakternya juga demikian, tiap akan pergi dia pasti membuat checklist, menulis apa saja yang perlu di bawa, apa yang akan dilakukan dsb. Sejak kecil beliau selalu mengajarkan hal seperti itu pada anak-anaknya.

Terlepas dari sisi positifnya, ternyata akhirnya saya mengalami sisi negatifnya. Dipadukan dengan karakter yang keras, akhirnya saya jadi kurang fleksibel! Susah juga. Saat ini pekerjaan dan kehidupan saya menuntut untuk lebih fleksibel, siap dengan agenda-agenda mendadak dan harus cepat bisa menyesuaikan diri. Biasanya saya sudah menyusun rencana selama 1 minggu, misalnya ada kuliah di akhir minggu, dan saya sudah atur hari Kamis dan Jumat untuk mengerjakan tugas-tugas, sehingga hari sebelumnya saya bisa fokus ke pekerjaan di kantor. Nah, tapi bagaimana jika tiba-tiba hari Kamis ada keperluan pekerjaan sehingga harus ke luar kota selama 2 hari ? Wah, dengan model perencanaan yang terlalu strict, tentu akan membuat kacau-balau segala-galanya. :D

Sepertinya memang saya perlu segera berubah, tapi ternyata tidak mudah. Pekerjaan di kantor semakin banyak menuntut saya harus mobile (kalau tidak salah sudah 3 minggu ini selalu ada pekerjaan di luar kota), selain itu banyak kebutuhan lain yang memang kadang serba mendadak. Mungkin juga saya perlu mengadopsi prinsip-prinsip agile method dalam software engineering. Fleksibel, agile dan tidak perlu heavy-weight plan. Responding to change over following a plan.

By the way apa ini ada hubungannya sama temperamen saya yang termasuk melancholic-choleric ya ?

Fakta tentang estimasi proyek software

Coba baca ini, tulisan tentang Facts of Software Engineering Management. Menarik sekali, di situ ada 22 fakta tentang manajemen proyek software, mulai dari terkait people sampai estimasi. Yang cukup menarik di situ, salah satunya adalah fakta ke-10 yang berkaitan dengan estimasi.

Fact 10 : Most software estimates are made either by upper management or by marketing, not by the people who will build the software or their managers. Estimation is, therefore, done by the wrong people.

Ini sering terjadi karena memang ada kepentingan yang berbeda. Upper management atau marketing punya kepentingan kuantitas ($) penjualan, sementara engineer (dan manajernya) punya kepentingan kesuksesan proyek. Jika ini tidak selaras pasti sangat berbahaya. Ketidakselarasan ini juga ditunjukkan pada fakta 13, sbb :

Fact 13 : There is a disconnect between management and their programmers. In one research study of a project that failed to meet its estimates and was seen by its management as a failure, the technical participants saw it as the most successful project they had ever worked on.

Multitasking ?

Barusan saya menemukan artikel tentang efektifitas multitasking (dalam konteks pekerjaan), yang membantah konsep manajerial konvensional tentang produktivitas. Produktivitas dalam konteks pekerjaan berarti banyaknya hasil kerja berbanding dengan effort yang dilakukan (time, cost, etc.). Konsep ini memunculkan strategi multitasking, yaitu melakukan beberapa pekerjaan dalam waktu yang bersamaan, dengan tujuan untuk meningkatkan produktivitas.

Namun riset dalam artikel itu justru menyimpulkan sebaliknya, bahwa multitasking bisa jadi malah menurunkan produktivitas!

But newly released results of scientific studies in multitasking indicate that carrying on several duties at once may, in fact, reduce productivity, not increase it.

Sebetulnya masuk akal juga, karena dengan multitasking biasanya seseorang tidak akan mencapai level konsentrasi yang tinggi, karena harus switching dari satu task ke task yang lain. Apalagi jika pekerjaan yang dilakukan membutuhkan konsentrasi (intelegensi) cukup tinggi, tidak sekedar aktivitas fisik.

Lalu gimana dengan software engineer yang notabene termasuk pekerjaan kompleks yang membutuhkan konsentrasi dan olah-otak yang cukup tinggi ? Mana yang lebih produktif, memberikan mereka satu pekerjaan yang terfokus atau beberapa pekerjaan sekaligus ?

Karakter klien yang perlu dihindari

Mengerjakan proyek implementasi sistem informasi itu tidak mudah, karena sangat terkait dengan klien dan juga faktor eksternal lainnya. Mungkin ini yang menyebabkan tidak terlalu banyak bisnis yang bergerak di bidang ini. Sebagian mengarah ke zona yang (relatif) lebih aman, seperti pasar software retail (accounting software, dkk) atau malah mengarah ke infrastruktur maupun content. Kalaupun ke jasa implementasi, biasanya juga fokus dan based-on produk-produk tertentu yang sudah cukup mature, apakah itu dari Oracle, SAP, atau pemain besar lainnya.

Namun mencari pemain yang bergerak dari "hulu sampai hilir" sepertinya jarang. Mulai dari jasa consulting penyiapan/perencanaan sistem, pembuatan software customizednya, sampai implementasinya. Jika kliennya lingkupnya cukup kecil (misal hanya 2-3 departemen) masih cukup aman, tapi jika cukup banyak departemennya, jumlah penggunanya bisa ratusan dan secara fisik juga cukup besar, tentu sangat risky jika dilakukan konsultan pemula. Konsultan yang sangat jauh-jauh-jauh-dan jauh dari pemula saja masih banyak yang ambil zona aman.

Beberapa karakter klien yang cukup risky, dari pengamatan saya misalnya sbb :

• klien yang tidak mau tahu dan malas terlibat. Banyak klien yang punya prinsip "lakukan saja, jangan ganggu kami, toh kami sudah membayar anda!". Ini terjadi karena memang teknologi informasi memang masih baru dan tentu sulit mengharapkan e-leadership ada di setiap organisasi. Karakter klien seperti ini sangat menyulitkan proses implementasi, khususnya proses transisi dari bisnis lama ke bisnis baru berbasis TI. Mau tidak mau, seharusnya klien sebagai pengguna sistem harus terlibat dan dilibatkan sejak awal. Adanya departemen TI atau mungkin KPDE (Kantor Pengolahan Data Elektronik) bisa membantu, tapi ya harus benar-benar bisa memahami (atau setidaknya bisa menjiwai dan memfasilitasi) TI.
• klien yang tidak paham konsep sistem informasi dan implementasinya. Ini berbahaya, apalagi jika mereka "sok tau" dan berusaha menentukan ini-itu sejak awal. Misalnya ada yang berprinsip dan bersikeras tidak mau melakukan entry data ulang, padahal teknologi database sistem lama mereka sangat tidak convertable (misal masih belum DBMS). Atau klien yang bersikeras bahwa infrastruktur jaringannya sudah cukup baik, padahal belum dipelajari bagaimana lalu-lintas data yang dipakai di sistem baru.
  
• proyek-proyek "politis". Proyek politis ini maksudnya adalah proyek yang dilakukan semata-mata dengan alasan yang dibuat-buat, misalnya untuk "menghabiskan anggaran" dan praktek-praktek korupsi sejenisnya. Tentu saja jika dilihat dari kepentingan sesaat tentu sangat menguntungkan karena nilainya biasanya cukup besar, apalagi jika berhubungan dengan pemerintahan. Makanya, proyek jenis ini juga banyak yang mengejar, tapi sepengamatan saya biasanya perusahaan yang masih startup dan masih kembang-kempis finansialnya. Tentu kita masih ingat dengan banyak kasus website pemda bernilai milyaran rupiah, kan ? Lalu kenapa ini risky ? selain peluang terjerumus ke masalah legal (apalagi jika memang ada praktek ilegal), tentu dalam jangka panjang ini juga tidak memberi keuntungan apa-apa bagi bisnis. Produk biasanya juga tidak digunakan dan malah jika kita tidak pandai berpolitis, malah reputasi menjadi taruhan.
• klien dengan ekspektasi berlebihan dan irasional. Misalnya proyek implementasi berbagai aplikasi e-gov selama 2 bulan saja. Bagaimanapun, tim proyek/konsultan tetap harus melakukan assessment terhadap kelayakan proyek. Jika memang tidak memungkinkan, kenapa harus dilakukan ? memaksakan diri pada sesuatu yang di luar kemampuan, tentu bukan sesuatu yang wise untuk menjaga citra bisnis.
• klien latah teknologi (latek ? :D). Mentang-mentang pernah mendengar tentang teknologi mobile, lalu apa-apa serba ingin dibuatkan layanan SMS-nya. Padahal sebetulnya tidak perlu. Atau pemerintahan yang latah serba e-government, padahal jangankan berbasis "e", yang manual saja masih semrawut birokrasinya dan jangan-jangan dengan TI yang mendukung transparansi malah membuat masalah baru. Hal lain dalam konteks kampus, ingin apa-apa serba online! padahal infrastruktur tidak memadahi dan operasional/perawatan sistem yang bisa diakses publik tentu perlu menjadi perhatian. Ini menguntungkan sesaat buat konsultan terutama di sisi finansial, hanya saja sebetulnya apa yang kita cari ? untuk perkembangan bisnis dibutuhkan citra baik dan dalam konteks ini sebetulnya bisa diperoleh dengan terimplementasikannya dengan baik produk yang kita jual dan benar-benar operasional dan memberikan value untuk klien kita. Finansial ? tentu saja ini investasi yang lebih jauh bernilai ketimbang dolar sesaat.

Sekali lagi, profit memang tujuan utama dari bisnis. Hanya saja tentu tidak sebatas itu. Menurut saya hal terpenting yang perlu menjadi fokus justru perkembangan bisnis di masa depan. Ini bisa dilakukan dengan tetap fokus pada pekerjaan dengan fokus, strategis, etis, dan penuh pertimbangan, apalagi di konteks bisnis TI yang kompleks. Jika memang tidak sesuai, apakah salah jika menghindarinya ?

How to measure productivity (in software engineering) ?

Line of Code (LOC) ? Functional Points (FP) seperti di buku SE-nya Pressman ? bagaimana dengan konsep berorientasi objek yang tentu saja metric seperti ini kurang pas. Dan tentu saja, produktivitas ini perlu diukur dari 3 objek :

• Product
  
• Process
• People

Saya lagi baca-baca lagi, merefresh kuliah software engineering waktu kuliah dulu (yang cukup membosankan karena dosennya!). Tentu saja ini hal penting yang sebetulnya perlu diketahui oleh setiap software engineer.

Nantikan tulisan saya tentang ini, tentu saja setelah sekian pe-er kuliah saya terselesaikan, dan kerjaan di kantor mulai agak mereda ... mungkin 1 atau 2 tahun setelah hari ini ... :D j/k.

Joel on Software berbahasa Indonesia

Saya lumayan sering berkunjung dan membaca blognya Joel Spolsky, seorang software engineer yang pernah bekerja di Microsoft dan sekarang berada di New York membangun bisnisnya sendiri. Profil lengkapnya bisa dilihat di sini.

Yang menarik adalah blog tersebut sekarang sudah ada yang menerjemahkannya dalam bahasa Indonesia. Saya tidak tahu siapa, tapi sepertinya ini formal, karena menggunakan domain yang sama dengan edisi aslinya.

Hm, kira2 ada yang mau nerjemahin blog saya ke bahasa Inggris atau yg lainnya ? hehe j/k.

Apakah system analyst haruslah seorang programmer ?

Pengalaman saya dalam dunia software engineering yang baru sekitar 4 tahun membuat saya banyak bertanya-tanya tentang banyak hal. Mungkin saya akan menuliskan rangkaian pertanyaan-pertanyaan saya di sini mulai sekarang.

Pertanyaan saya ini tentang anggapan umum bahwa seorang system analyst sebaiknya pernah menjadi programmer. Apakah benar seperti ini ?

Pengalaman saya dulu sewaktu bekerja di kampus dan usaha kecil-kecilan dengan teman memang demikian, karena (1) memang ada keterbatasan SDM sehingga peran system analyst merangkap programmer, dan mungkin sekaligus project manager! (2) tentu saja pekerjaan yang dilakukan cakupannya kecil dan sederhana. Misalnya membuat website (saya tidak meremehkan desainer web, hanya saja website memang lebih terfokus pada desain ketimbang kompleksitas proses).

Namun dalam konteks pengembangan software enterprise, yang melibatkan lingkup yang besar dan bisnis proses yang kompleks dan multi departemen (dan biasanya multi role, user bahkan requirement) menurut saya tidaklah harus seorang system analyst pernah menjadi programmer. Mengapa ? karena tugas utama dari seorang system analyst adalah melakukan analisa dan mempelajari bisnis proses dari organisasi (sering disebut sebagai "systems") yang akan dikelola dengan teknologi informasi.

Misalnya dalam pengembangan software sistem informasi akuntansi, tentu saja tugas system analyst mempelajari seluruh hal terkait akuntansi, sehingga programmer tidak perlu lagi berkutat dengan kebingungan "transaksi ini masuk jurnal mana ya ?", "laporan ini seharusnya mengambil data darimana" dsb. Untuk memahami dengan baik seluruh siklus, aturan, prosedur akuntansi bahkan (mungkin) anda harus seorang sarjana akuntansi. Apalagi dalam konteks proyek yang memiliki batasan waktu. Suatu blunder, jika pengembangan software akuntansi dilakukan oleh seorang system analyst yang tidak tahu apa-apa tentang akuntansi, apalagi dengan waktu yang tidak memungkinkan untuk belajar.

Berdasarkan alasan itulah, saya berpendapat bahwa seorang system analyst yang baik tidaklah harus "jago" di bidang pemrograman java ataupun PHP. Memang ini juga tidak berarti harus dari lulusan akuntansi ataupun apapun yang berkaitan dengan software yang akan dikembangkan, karena salah satu tugas dari sysem analyst selain requirement gathering juga melakukan permodelan. Pada fase ini dituntut setidaknya pemahaman akan manajemen informasi, model data, relasi, dan berbagai dasar dari disiplin ilmu informasi (sistem informasi).

Lalu, bagimana programmer bisa menerjemahkan apa yang sudah diketahui oleh system analyst menjadi kelas-kelas dan kode-kode ? Inilah tanggungjawab yang seharusnya dipegang oleh system designer. Buku "System Analysis and Design using UML" (Bennet, McRobb & Farmer) dalam chapternya yang berjudul "Moving into Design" menyatakan jelas perbedaan antara aktivitas analisis dan desain. Singkatnya kegiatan analisis mencoba menggali what dari suatu sistem, sedangkan desain berbicara tentang how. System analyst mencari tahu what happens in the current system and what is required in the new system, dan menghasilkan yang namanya requirment specification. Seorang system designer menerjemahkan how the system will meet the requirement.

Intinya menurut saya adalah fokus pada peran. Jika memang ada kondisi keterbatasan jumlah SDM, mungkin model gabungan peran yang lebih baik adalah (1) system analyst sekaligus project manager dan (2) system designer sekaligus programmer.

Memahami JAD

Dalam kuliah SIT (Systems and Information Technology) di kampus hari Minggu yang lalu, saya dikenalkan lebih jauh oleh Pak Surahyo tentang JAD (Joint Application Development/Design) sebagai salah satu teknik manajemen dalam mengimplementasikan sebuah sistem informasi (SI) dalam konteks proyek. Ini sangat menarik, karena banyak project manager pemula, seperti saya, yang mengalami banyak hambatan dan kesulitan dalam proses implementasi SI. Saya pernah dengar pernyataan dari Pak Lukito, direksi perusahaan saya yang juga pakar di bidang TI, mengatakan bahwa porsi terbesar dan terumit dari proses implementasi SI adalah justru pada proses transisinya, karena terkait banyak aspek tidak hanya di sisi teknologi tapi harus memahami sisi sosial, manajerial dan SDM.

Implementasi SI
Masalah terbesar dari implementasi SI adalah untuk mengetahui kebutuhan dari user, apalagi dengan karakter proyek :

• Sistem yang melibatkan multi-organisasi/divisi (penggunanya dari beberapa role dan divisi)
• Bisnis proses yang kompleks
• Kebutuhan yang sangat spesifik dan customized.

Dengan karakter proyek yang semacam ini, tidak cukup bagi seorang system analyst (SA) menentukan kebutuhan hanya dengan teknik wawancara, observasi ataupun kuesioner. Banyak kasus ditemui, bahwa pada akhirnya apa yang kita dapatkan dari proses analisa kebutuhan di awal proyek, tidak match dengan kebutuhan sesungguhnya dari pengguna sistem, sehingga sistem akhirnya tidak dapat digunakan dengan baik.

Masalah lain adalah di sisi waktu. Teknik-teknik seperti itu seringkali sangat time consuming, sangat membutuhkan waktu yang lama. Sering juga tim developer dihadapkan situasi bahwa tidak semua stakeholder proyek memiliki kepedulian yang sama dengan yang lain. Seorang manajer tidak mengetahui kebutuhan detail dari staf-staf operasional, sementara itu staf operasional mungkin juga tidak memahami sepenuhnya spirit, goal dari SI.

How do you design a system that clients really want? You can't. You have to help clients design the system they want. If you are telling business users how to solve their problems, you are missing the boat. You have to establish a relationship with the client to get behind what they are saying the problem is in order to discover the true underlying problem. (dikutip dari sini)

Apa itu JAD ?
Dari salah satu referensi, dikatakan bahwa :

Joint Application Design is a management process - a people process - which allows IS to work more effectively with users in a shorter time frame. Since the late seventies, JAD has proven to be an effective technique for building user commitment to the success of application systems through their active participation in the analysis of requirements and the specification of the system design.

Dari pernyataan itu bisa kita sarikan bahwa JAD merupakan sebuah teknik yang berfokus pada keterlibatan dan komitmen pengguna dalam menentukan kebutuhan dan merancang (desain) aplikasi. JAD biasanya dilakukan dalam bentuk tim yang merupakan gabungan dari seluruh stakeholder proyek, yang bekerja dalam bentuk workshop-workshop atau forum diskusi. Kenapa workshop ? karena teknik JAD ini bukanlah sekedar rapat-rapat, yang biasa dilakukan dalam sebuah proyek dan melibatkan seluruh stakeholder proyek. JAD adalah tim yang nantinya akan membuat rancangan dan mengawasi, memonitor bersama jalannya proyek.

Siapa yang perlu terlibat ?
Secara garis besar yang perlu terlibat adalah :

1. Sponsor. Sponsor ini berarti project owner, memiliki kedudukan yang cukup tinggi dalam organisasi dan sebagai pengambil keputusan tertinggi dalam pengelolaan sistem informasi. Satu hal yang penting dilakukan oleh seorang project owner adalah komitmen yang kuat akan implementasi SI yang dilakukan. Without the executive sponsor's commitment, people do not show up for workshops on time or sometimes at all. Schedules change and projects are delayed. In short, without an executive sponsor, there is no project!
2. Business Users. Business User ini terdiri dari 2 jenis, yaitu real end user dan representative end user. Real end user adalah person yang melakukan pekerjaan real di lapangan. Dalam kasus, ini adalah operator-operator. Sedangkan representative end user adalah person yang mengetahui seharusnya bisnis proses itu dilakukan, memahami spirit dan goal dari sistem yang dikelolanya. Biasanya ini adalah kepala bagian, manajer, atau operator senior.
3. System Analyst (Tim Developer). Person/tim ini yang akan in-charge dari sisi teknologi dan proses engineeringnya.
4. System Experts. Tidak semua referensi mencantumkan peran ini. Perannya lebih seperti konsultan yang memahami seluk beluk bisnis proses dari sisi konseptual dan berbasis pengalaman.
5. Facilitator. Seorang fasilitator berfungsi sebagai moderator dan mengarahkan setiap aktivitas JAD yang melibatkan banyak pihak, untuk menjadi efektif. Seorang fasilitator harus memiliki kecakapan yang baik dalam berkomunikasi, memberikan stimulus-stimulus dan trik-trik agar diskusi bisa berjalan dengan baik.
   

Tentu saja, setelah penyusunan tim JAD, diperlukan strategi yang tepat dalam melakukan workshop-workshop, sehingga proses dilakukan lebih efektif. Yang jelas, teknik ini sudah terbuktif efektif dalam menyelesaikan masalah-masalah implementasi SI. Satu paragraf terakhir dari salah satu referensi adalah sebagai berikut :

To develop effective information systems today we must take the time to integrate the technical aspects of information technology and the social aspects of the organization. That's what facilitated workshop requirements analysis is all about!

Referensi :

1. Development Methodology - Joint Application Development (JAD)
2. Joint Application Development
3. Joint Application Design - Business Requirements Analysis for Successful Re-engineering
   
4. Joint Application Development (JAD) - What do you really want?
   

Merencanakan Proyek

Saya mau share dikit nih soal proyek, kebetulan kantor saya saat ini bisnisnya konsultan, developer dan implementator sistem informasi, sistem produksinya juga project based, jadinya memang mau ngga mau saya harus jungkir balik ngurusin kerjaan proyek ginian. Wah sempat puyeng juga sih ngurusinnya, apalagi saya waktu itu masih "fresh from the oven" alias baru lulus. Di kuliah ada sih 3 SKS tentang project management, tapi waktu itu dosennya banyak bolos sih hehehe.

Saya ngga tau kenapa lulusan-lulusan sekolah IT di Indonesia agak kurang peka dan banyak belajar soal project management, khususnya IT Project Management. Padahal kalau mau bicara tentang "kebutuhan di dunia kerja" (seperti yang banyak jadi spirit arah pendidikan kampus), orang-orang IT sebagian besar akan bekerja dalam konteks proyek dan segala environmentnya. Kita bekerja di perusahaan masuk divisi IT/MIS juga sebagian besar aktivitasnya mungkin dalam konteks proyek, apalagi yang di bidang software. Apalagi kalau di perusahaan-perusahaan konsultan pengembangan software, jelas sekali. Ada sih memang yang lebih ke rutin operasional (tanpa constraint waktu) seperti jadi DBE atau Net Admin, hmm ... tapi juga nggak banyak.

Ya jadinya seperti saya ini, sudah lulus masih banyak bolak balik halaman-halaman buku, googling, tanya sana sini dari yang sudah experienced. Tapi gpp, kabarnya memang IT itu ilmu yang paling dinamis. Sekali kita lepas dari google atau buku, ya sudah habis kita.

Well, tentang perencanaan proyek ini juga saya banyak belajar dari teman-teman di kantor. Ada yang bilang "gagal merencanakan sama dengan merencanakan kegagalan", ya ini juga berlaku untuk implementasi IT, sering kita lupa membuat perencanaan yang baik. Perencanaan terkait dengan objektif (goal), batasan-batasan dan ruang lingkup pekerjaan. Merencanakan suatu studi misalnya, terkait dengan objektif : apa yang kita tuju setelah belajar 5 tahun di kampus, terkait juga dengan batasan (waktu, kemampuan, biaya, dsb), juga tentang ruang lingkupnya, apa saja yang perlu kita lakukan selama studi. Secara garis besar seperti itu.

Saya banyak mengalami dispute dengan beberapa stakeholder proyek, terutama klien karena memang belum ada kesepahaman tentan rencana proyek ini. Dalam merencanakan proyek, saya liat ada beberapa hal penting yang perlu disepahamkan, misalnya :

• Visi proyek. Jelas sekali ini adalah hal yang paling penting, supaya segala perencanaan, estimasi dan perubahan-perubahannya tetap mengacu pada visi ini.
• Definisi. Definisi terkait dengan ruang lingkup, aspek legalitasnya maupun deliverables proyek.
• Organisasi proyek. Seluruh stakeholder proyek, deskripsi peran dan tanggungjawabnya, sampai struktur organisasinya. Metodologi, workflow juga perlu didefinisikan di sini.
• Asumsi, dependensi dan batasan. Ini yang cukup sering membuat dispute, karena tidak sepahamnya tentang asumsi, dependensi dan batasan yang jadi dasar pengerjaan proyek
• Risiko. Risiko dan mitigasinya perlu dianalisis dan dirinci dengan baik.
• Komunikasi dan kontrol.
• Jadual dan anggaran (estimasi). Ini sifatnya estimasi, tapi perlu disusun WBS (Work Breakdown Structure) dan segala estimasi tentang waktu dan biayanya.
  

Itu hal-hal mendasar yang perlu dipikirkan, masih ada beberapa hal-hal lain yang lebih detail. Saya juga sedang belajar tentang ini. Yang jelas, dalam perencanaan proyek yang dilakukan tidak terbatas pada mendefinisikan, mengkonsep atau bahkan mendokumentasikannya, tapi yang lebih penting adalah membuat kesepahaman/kesepakatan dengan seluruh stakeholder proyek.

Satu hal lagi, perencanaan itu tidak harga mati. Perencanaan itu pasti tidak 100 % akurat (kecuali dukun hehehe). Tapi meski demikian, perencanan perlu dilakukan dengan baik dan dengan detail dan mendalam.

Catatan : pasti tulisan saya di atas banyak sekali kesalahannya. Tapi nanti saya akan revisi seiring saya baca-baca lagi di buku dan dari pengalaman-pengalaman. Apalagi saya belum professional certified. Hehehe. j/k.

Konsumen adalah Raja

Jargon itu nggak asing lagi kan. "Konsumen adalah raja". Ada juga yang mengatakan "Pembeli adalah raja", dsb. Intinya adalah pola pikir berorientasi kepuasan konsumen/pelanggan pada sebuah bisnis. Sejauh mana sih implementasi dari jargon itu.
Sepintas, jargon itu memang cocok, untuk bisnis dengan komoditas utamanya adalah produk. Lebih spesifik lagi berjenis consumer products, macam sabun, makanan, komputer, dsb. Pembeli adalah raja, konsumen adalah raja, kepuasan mereka adalah goal dari bisnis. Ini bisa berarti :

• Produk yang diproduksi harus bisa menjawab kepuasan konsumen (kalo di istilah pemasaran, bukan lagi pake prinsip mass product, tapi customization, menyesuaikan karakter konsumen).
• Kualitas pelayanan yang baik (dalam memperoleh informasi, layanan purna jual, dsb)
• Membina hubungan baik dengan pelanggan. Pelanggan adalah salah satu stakeholder bisnis.

Selain produk, beberapa karakter bisnis jasa juga bisa seperti ini, misalnya transportasi. Kepuasan pelanggan nomer satu. Dimana-mana, hampir semua maskapai penerbangan memberikan layanan pada konsumen dengan sebaik-baiknya. Ada online reservation, ada model membership ala GFF (Garuda), selain itu mereka juga memberikan pelayanan yang sangat-sangat ramah pada penumpang. Bisnis hotel juga seperti ini.

Tapi yang masih jadi pertanyaan apakah semua bisnis jasa bisa seperti ini. Jargon 'konsumen adalah raja' memang masih berlaku, tapi apa implementasinya bisa serta merta seperti yang contoh di atas tadi ? Ada beberapa bisnis yang aku kadang masih berpikir di mana titik temunya. Misalnya kesehata, atau bisnis pendidikan. Dalam bisnis jasa pelayanan kesehatan, dalam hal ini misalnya rumah sakit, pasien adalah konsumen. Kepuasan konsumen adalah kesembuhan sang pasien dari penyakit. Dalam proses pelayanannya (service delivery), apakah seorang pasien benar2 adalah 'raja' ? Raja dalam arti 'we do anything you want' kayaknya kurang pas. Proses penyembuhan, proses terapi, membutuhkan keterlibatan dari si pasien itu sendiri. Sejauh mana pasien bisa berkompromi, menuruti apa yang dianjurkan oleh rumah sakit (dokter). Kadang, terapi yang dilakukan mungkin malah tidak menyenangkan. Tapi jika itu dituruti, pasien bisa bekerjasama dengan baik, niscaya kesembuhan bisa didapat. Ini juga untuk pendidikan, siswa adalah konsumen dengan goal kepuasan adalah mendapat ilmu, keterampilan yang baik. Ini juga membutuhkan keterlibatan dari si siswa, bagaimana dia bisa mengembangkan dirinya dengan didampingi oleh guru/instruktur. Sekolah sebaik apapun, universitas setenar apapun, tidak ada yang bisa membuat seseorang jadi sempurna tanpa kemauan, keterlibatan dari dirinya sendiri.

Pertanyaan terakhir, gimana dengan bisnis konsultan IT (information technology), spesifik misalnya implementasi sistem informasi. Di sini jelas, kepuasan dari konsumen adalah jika sistem yang dideploy bisa mengakomodasi kebutuhan operasional organisasinya, bisa mempercepat proses yang ada, bahkan bisa membantu dalam pengambilan keputusan (jika sudah sampai level DSS). Tapi, gimana caranya ? sejauh mana jargon 'konsumen adalah raja' diimplementasikan ? sama seperti jualan sabun ? atau seperti kasus rumah sakit ?