Mengenal Seputar SDM IT

29 Nov 2011 Mengenal Seputar SDM IT

Era IT dimulai pada dekade 1960an, berarti belum seabad. Dalam usia yang relatif masih muda ini, sangatlah lazim jika di sana-sini masih banyak perubahan, termasuk pembakuan profesi SDM-nya. Tempo doeloe, profesi SDM IT yang populer hanya operator, programmer, analyst dan systems programmer.

Operator adalah SDM yang tugasnya mengoperasikan IT, antara lain menghidupkan hardware (komputer dan network), menjalankan software sesuai jadwal maupun kondisi, berinteraksi dengan hardware dan software yang sedang beroperasi, dan menyudahi operasi, termasuk menghentikan software dan mematikan hardware. Operator tidak perlu memiliki latarbelakang pendidikan IT selain pelatihan sesuai tugasnya. Dalam melaksanakan tugasnya, tentu memerlukan otoritas yang cukup tinggi karena harus bisa menghidupkan dan mematikan sistem. Mereka memiliki akses penuh atas console sistem dan aplikasi untuk sistem produksi. Oleh karena itu operator harus bekerja di ruang khusus yang tidak boleh dimasuki oleh siapa saja selain yang diijinkan oleh pimpinan operasi. Sebaliknya, console sistem dan aplikasi untuk sistem produksi di-setup sedemikian rupa supaya tidak bisa dibuka di luar ruang operator.

Programmer adalah SDM yang tugasnya menyusun program aplikasi dan dokumen teknisnyai. Kebalikannya operator, programmer tidak boleh nyentuh sistem produksi selain ketika memasang programnya di sistem produksi setelah dinyatakan lulus semua evaluasi.

Untuk melakukan tugasnya, programmer selain harus menguasai ketrampilan menggunakan bahasa komputer yang diperlukan, juga harus memiliki latarbelakang logika matematis yang kuat di samping pengetahuan IT cukup memadahi . Kenapa demikian? Karena serendah-rendahnya program, di dalamnya mengandung bagian dari proses bisnis yang mencakup sejumlah pengambilan keputusan. Aslinya ketika masih manual, pengambilan keputusan tersebut memerlukan tingkatan birokrasi tertentu. Setelah dikonversi ke digital, pengambilan keputusan tersebut diambilalih oleh program. Dengan kata lain, programmer telah mengambilalih kewenangan sejumlah birokrasi dikonversi ke dalam software bikinannya cukup dengan tulisan

if (kondisi) {
    keputusan 1;
    keputusan 2;
}
else {
    keputusan 3;
}    

Kelihatannya sepele ya? Gitu-gitu kalo manual kadang perlu sederet birokrasi. Contohnya, dalam iklim neolib ini, marak pasar swalayan masuk ke pelosok-pelosok mendesak pasar basah. Aturan tentu ada, seperti syarat kelas jalan, jarak mart satu dengan lainnya dsb. Dengan cara manual, aturan tersebut dikawal oleh sejumlah birokrasi. Tentu ada yang longgar dan ada juga yang luwes, tergantung akhlak sang birokrat dan seberapa menarik pelicinnya. Namun setelah di-IT-kan, sederet birokrasi tersebut diringkus oleh programmer menjadi if .. else .. yang sangat tegas, kaku dan cepat. Seberapapun pelicinnya, program tak akan bergeming. Satu-satunya cara untuk merobohkan kekakuan program hanyalah merubahnya. Tapi ini hanya bisa dilakukan jika program tersebut berada di IT lokal pemerintah setempat, bukan e-Gov. Itulah makanya banyak pihak yang ngotot menghendaki e-Gov dibangun bebas sendiri-sendiri tiap kabupaten/kota.

Gara-gara di-digital-kan, kewenangan sekian banyak birokrasi sebuah organisasi cuman diringkus dalam beberapa perintah program oleh tangan programmer. Betapa berwenangnya programmer ya? Maka dari itu, keputusan digital sama sekali tidak boleh salah. Bisa bangkrut bisnisnya jika salah. Oleh karena itu diperlukan kualitas kemampuan logika matematis yang sangat handal.

Analyst adalah SDM yang tugasnya menghimpun kasus-kasus proses bisnis yang akan dikonversi ke IT dan menyajikannya dalam bahasa atau spesifikasi teknis yang mudah dimengerti oleh programmer. Sehingga idealnya mereka memahami betul proses bisnis di lingkungannya dan memiliki pengetahuan IT. Namun pada kenyataannya, profesi ini jarang yang efektif. Karena tugasnya hanya musiman dan programmer pada umumnya mampu melakukannya sendiri. Oleh karena itu fungsi analyst umumnya ilakukan oleh salah satu programmer.

Systems programmer (sysprog) awalnya adalah SDM yang tugasnya mewujudkan IT siap pakai bagi operator, programmer maupun user. Untuk itu, sysprog harus merencanakan dan merancang infrastruktur dan konfigurasi sistem, melakukan instalasi dan setup hardware dan software, mengadministrasikannya, mengoptimasi kapasitas dan kinerja sistem, menganalisa dan meresolusi masalah yang muncul dan bila perlu melakukan sejumlah modifikasi demi mencapai kesiapan IT yang ditanganinya melalui systems programming. Oleh karena itu, sysprog harus benar-benar memahami arsitektur dan teknologi hardware dan software serta memiliki keterampilan assembly dan jeroan OS yang memadahi di samping ketrampilan operasi dan programming. Kenapa demikian? Karena dalam menganalisis dan meresolusi masalah, sysprog harus mampu membaca data memori yang hanya data dan instruksi mesin yang penempatannya mengikuti aturan OS. Untuk memodifikasi OS (bila diperlukan) juga tidak semuanya bisa dilakukan dengan C, sehingga ketrampilan assembly sangat diperlukan. Sehingga sysprog sepertinya profesi yang paling sibuk dan benar-benar menguasai pendalaman IT yang sempurna. Untuk memasuki pelatihan sysprog biasanya dipilih dari programmer yang terbaik.

SDM IT generasi kedua (1980 – pra 2000)

Mencari SDM IT yang sempurna untuk menjadi sysprog sangat sulit. Apalagi melihat kesibukannya sehari-hari yang tidak mungkin dipikul hanya oleh satu dua orang untuk lingkungan sistem berskala besar. Kalo harus banyak orang, tentu biayanya mahal, karena bayaran sysprog umumnya melebihi manajer IT. Lagipula orang yang memiliki kepakaran sedalam sysprog bisa menjadi bumerang bila dibebaskan mengakses sistem produksi sehari-hari. Bayangkan… manakala dia ngambek atau pikirannya korslet, lantas menyandera sistem, siapa yang bisa mengatasi?

Maka dari itu akhirnya beban sysprog dibagi-bagi dalam beberapa profesi baru, antara lain systems support, systems administrator (sysadmin) dan systems engineer (SE). Istilah sysprog kadang masih ada yang pakai, namun hanya untuk SE yang sangat senior.

Systems support adalah SDM yang tugasnya melakukan instalasi dan setup hardware dan software serta menganalisis dan meresolusi masalah yang muncul, baik semasa instalasi maupun operasi sehari-hari sesuai dengan SOP yang diterbitkan oleh tim SE. Oleh karena itu system support harus menguasai arsitektur dan teknologi hardware dan software serta ketrampilan menginstalasi dan mengoperasikannya dan keterampilan assembly dan jeroan OS yang memadahi, minimal untuk melandasi ketrampilan membaca isi memori katika menganalisis masalah. Untuk memasuki pelatihan systems support biasanya dipilih dari programmer yang terbaik.

Systems administrator (sysadmin) adalah SDM yang tugasnya melakukan administrasi dan optimasi semua komponen sistem termasuk distribusi aksesnya sesuai dengan SOP yang diterbitkan oleh tim SE. Di lingkunan sistem skala menengah ke bawah, sysadmin umumnya merangkap tugas systems support. Oleh karena itu sysadmin harus menguasai arsitektur dan teknologi hardware dan software serta ketrampilan mengoperasikannya dan mengadministrasikannya. Untuk memasuki pelatihan sysadmin biasanya dipilih yang memiliki pengalaman menjadi programmer di lingkungan IT yang mirip.

Systems engineer (SE) adalah SDM yang tugasnya merencanakan dan merancang infrastruktur dan konfigurasi sistem, menerbitkan SOP bagi systems support, sysadmin dan SDM lain yang pekerjaannya berkaitan dengan wilayah sistem, serta merekayasa teknologi lokal yang diperlukan, baik melalui modifikasi komponen yang ada maupun menciptakan komponen baru melalui systems programming. Rekayasa lokal biasanya untuk mengotomasikan sejumlah rutinitas tertentu, terutama yang menyentuh komponen-komponen sensitif. Oleh karena itu SE harus benar-benar memahami arsitektur dan teknologi hardware dan software serta keterampilan assembly dan jeroan OS yang memadahi di samping ketrampilan operasi dan programming. Jadi, SE sebenarnya sysprog, cuman aktivitasnya lebih banyak di development system, karena tugas rutinnya di produksi sudah diambilalih oleh systems support dan sysadmin. Meskipun SE merupakan arsitek yang mencetak terwujudnya sistem di wilayahnya, SE dalam keseharian sebaiknya tidak memiliki akses ke sistem produksi. Ini demi keamanan sistem, karena SE merupakan SDM yang paling menguasai detil teknis keseluruhan sistem. SE baru diberi akses ke sistem produksi manakala hendak membawa perubahan atau membantu systems support dan/atau sysadmin manakala mengalami kesulitan. Untuk memasuki pelatihan SE biasanya dipilih dari systems support yang terbaik.

Selain 3 bidang profesi di atas, juga ada tambahan 3 profesi lain, yaitu quality assurance, database administrator dan security administrator.

Quality assurance (QA) adalah SDM yang tugasnya mengevaluasi kualitas semua entitas dan komponen hardware dan software yang akan dipromosikan masuk ke sistem produksi sesuai dengan SOP yang mereka terbitkan sendiri. Karena jangkauannya meliputi sistam dan aplikasi, biasanya QA dibagi menjadi QA sistem dan QA aplikasi. QA sistem mengevaluasi semua komponen dan entitas hardware dan software sebatas OS dan produk-produk pendukungnya yang telah dipersiapkan oleh systems support untuk memasuki wilayah produksi. Mereka harus dipilih dari SE yang berpengalaman. .Sedangkan QA aplikasi mengevaluasi semua komponen dan entitas aplikasi yang telah dipersiapkan programmer (dan systems support) untuk memasuki wilayah produksi.. Mereka harus dipilih dari programmer yang berpengalaman. Yang dihasilkan oleh tim QA hanya persetujuan apakah obyek layak memasuki wilayah produksi atau tidak.

QA yang hebat, dalam menguji kualitas obyek tidak sekedar fungsinya, tapi benar-benar menyentuh kualitas. Misalnya, dalam mengevaluasi program lokal, setelah fungsinya terbukti benar, QA lantas melihat sourcecode untuk mengevaluasi kualitas kinerja dan matematisnya. Kualitas kinerja misalnya pengulangan membaca record yang sama harus dipertanyakan. Karena membaca record melibatkan I/O. Jika diulang hanya karena ada proses lain yang perlu input yang sama, padahal tidak ada perubahan isi record, berarti ada overhead yang tidak perlu. Sebaiknya hasil pembacaan pertama ditahan dalam array.

Kualitas matematis tidak kalah penting. Terutama dalam pengujian-pengujian kondisi untuk membuat keputusan. Kelihatannya sepele, hanya if (…) {…} atau if (…) {…} else {…}. Namun kadang ada kondisi yang komplex melibatkan AND, OR dan NOT yang sangat memungkinkan mengecoh kalo hanya diuji dengan satu dua kasus. Programmer maupun QA harus betul menguasai aljabar logik untuk menyusun tabel kebenaran logisnya. Hal ini harus dipahami betul oleh para bos IT agar dalam memilih programmer dan QA tidak terjebak hanya ketrampilan menggunakan bahasa komputer saja. Bakat dan latarbelakang matematis tidak bisa disepelekan.

Database administrator (DBA) adalah SDM yang tugasnya mengoptimasi dan mengadministrasikan semua database sesuai dengan SOP yang diterbitkan oleh tim SE. Oleh karena itu DBA harus menguasai pengetahuan dan ketrampilan programming dan arsitektur database yang memadahi. Untuk memasuki pelatihan DBA biasanya dipilih dari programmer yang terbaik atau system support yang berpengalaman.

Dalam praktek, banyak DBA yang menentukan SOP sendiri, bahkan seperti tim exlusif terpisah dari kelompok IT lainnya. DBA yang demikian sebenarnya database system engineer (DBSE atau DBE). Exlusivitas semacam ini biasanya diharapkan lebih fokus sehingga kinerjanya dalam menangani berbagai persoalan database lebih baik. Namun kerugiannya adalah manakala memerlukan sumberdaya sistem di luar wilayah database system, DBA harus berkordinasi dengan tim SE yang kadang memerlukan waktu yang cukup panjang manakala ada kepentingan yang berbenturan.

Security administrator (secadmin) adalah SDM yang tugasnya mengadministrasikan sekuriti di wilayah produksi sesuai dengan SOP yang diterbitkan oleh tim SE. Di luar wilayah produksi ditangani oleh sysadmin. Secadmin sebaiknya bukan orang IT yang dilatih menjalankan SOP sekuriti oleh tim SE. Dengan demikian diharapkan secadmin tidak memiliki gagasan maupun inisiatif apapun soal sekuriti sistem selain sekedar menjalankan SOP. Kenapa demikian?

Sistem produksi adalah kunci dari IT. Keberadaannya telah melalui seabreg pengujian untuk menekan sekecil mungkin peluang munculnya masalah. Oleh karena itu, sistem produksi harus dijaga seketat mungkin jangan sampai ada perubahan apapun tanpa kesepakatan antara tim produksi dan tim SE. Untuk menjaga agar rule tersebut berjalan, maka tim produksi dibatasi aksesnya sebatas kepentingan operasi. Sedangkan tim SE sama sekali tidak diberi akses sedang diperlukan untuk melakukan update tertentu. Satu-satunya yang memiliki akses paling tinggi adalah secadmin, bahkan mutlak. Maka, jika dia orang IT, bisa saja dia tertarik mempelajari komponen tertentu dan melakukan akses kesana yang dampaknya bisa mengganggu stabilitas sistem produksi. Jika dia di bawah manajer produksi, bisa saja mendapat tekanan untuk memberi akses lebih kepada tim produksi. Jika dia berada di bawah manajer SE atau manajer IT lainnya, bisa juga memberi paluang yang sama. Oleh karena itu secadmin untuk sistem produksi biasanya berada di luar divisi IT.

SE harus menyiapkan sarana dan SOP bagi secadmin sedemikian rupa agar tidak bisa melakukan apapun selain mengadministrasikan sekuriti, meskipun dia mengaksesnya dari superuser. Persiapan ini dilakukan sebelum sistem dipromosikan menjadi sistem produksi, yaitu ketika masih development system. Nah… bila anda SE, sudahkan anda melakukan hal ini?

Salah kaprah seputar QA dan sekuriti

Sejak awal kehadirannya hingga hari ini, QA di negeri kita umumnya salah kaprah. Pertama, QA sistem tidak pernah ada. Yang menyatakan lulus tidaknya entitas dan komponen sistem (hardware dan software) memasuki wilayah produksi adalah tim SE. Padahal yang merancang dan merekayasa sistem serta menerbitkan SOP mereka juga. Kadang mereka juga ikut membantu system support dan sysadmin di fase awal sembari sosialisasi SOP. Tentu apapun yang mereka hasilkan pasti mereka nyatakan sukses. Artinya SE memiliki kewenangan yang mutlak tanpa ada yang mengevaluasi.

Kedua, QA hanya sebatas aplikasi dan bukan orang yang dipanggil pertama kali manakala ada masalah di aplikasi di wilayah produksi. QA adalah pihak yang menyatakan layak tidaknya obyek aplikasi masuk ke wilayah produksi. Artinya, QA harus bertanggungjawab manakala ternyata muncul masalah pada obyek tersebut. Bukan untuk membetulkan, tetapi sebagai hukuman moral agar kecerobohan dalam melaksanakan tugasnya tidak terulang. Yang melakukan koreksi tetap programmer.

Ketiga, QA membuatkan script atau JCL untuk obyek-obyek apllikasi yang telah dinyatakan lulus untuk memasuki wilayah produksi. Ini salah total. Karena script atau JCL juga termasuk obyek yang harus dievaluasi oleh QA. Kalo mereka bikin sendiri tentu tidak ada evaluasi, sehingga kualitasnya tidak ada yang bertanggungjawab.

Ini memang kesalahan konsep organisasi. Mestinya QA punya sistem komputer sendiri yang konfigurasinya persis plek sistem produksi, biasanya disebut test system. Karena sistem ini hanya diperlukan untuk test, maka sebaiknya virtual. Lantas program yang akan dipromosikan ke sistem produksi dimasukkan ke sistemnya QA dan seluruh script atau JCL pendukungnya disesuaikan dengan sistem QA tersebut oleh programmernya tanpa bantuan QA. Setelah semua siap, baru QA melakukan evaluasi. Jika lulus maka langsung di-cloned ke sistem produksi oleh programmer tanpa perubahan satu byte pun. Dan QA tidak boleh memiliki akses apapun di sistem produksi. Programmer juga hanya memiliki akses manakala sedang menyalin obyeknya (yang telah dinyatakan lulus) ke sistem produksi. Setelah selesai, akses dicabut kembali oleh secadmin.

Sayangnya kenyataannya di kebanyakan instansi di negeri ini tidak begitu. QA tidak punya test system. Evaluasi dilakukan di development system dan setelah lulus langsung disalin ke sistem produksi. Tentu saja script atau JCL pendukungnya harus disesuaikan dengan sistem produksi karena konfigurasinya pasti berbeda dengan development system.

Keempat, QA merangkap secadmin. Ini adalah kesalahan fatal. Bagaimana tidak? QA menyusun security rule untuk wilayah produksi. Padahal, selain security rule adalah obyek yang sangat vital dan harus dievaluasi kualitasnya. Lah kalo yang bikin QA sendiri, lantas, lantas siapa yang mengevaluasi?

Seharusnya security rule dan SOP-nya untuk sistem produksi dirancang dan dipersiapkan oleh SE di test system. Setelah rampung, lantas dievaluasi oleh QA sistem. Jika lulus, maka security rule tersebut kemudian disalin ke sistem produksi oleh SE memalui superuser tanpa ada perubahan satu byte pun. Setelah cloning selesai, superuser SE dinonaktifkan lagi oleh secadmin. Secadmin selanjutnya mengambil alih security rule tersebut untuk mengadministrasikannya sehari-hari yang sifatnya hanya menambah atau mengurangi detil setiap rule sasuai kebutuhan.. Secadmin tidak boleh menambahkan rule baru tanpa persetujuan SE. SE tidak bisa memasukkan rule baru tanpa diberi akses superuser oleh secadmin. Demikian aturan main yang seharusnya.

Jika terjadi kebobolan, yang harus diborgol terlebih dulu adalah secadmin. Semua jurnal sekuriti dikeluarkan untuk membuktikan apakah secadmin dalam melaksanakan tugasnya sudah sesuai dengan SOP yang ditetapkan oleh SE. Jika tidak, maka secadmin yang bersalah. Jika sudah sesuai SOP, maka SOPnya yang salah. Berarti QA sistem harus diperiksa karena meluluskan SOP yang salah. Karena tidak ada QA sistem, maka SE lah yang bersalah.

Tapi entah kenapa di negeri ini masih banyak instansi yang menyelenggarakan kesalahkaprahan yang sangat beresiko tinggi ini.

SDM IT era modern

IT modern ditengarai dengan hadirnya alat-alat bantu yang serba visual dan produk-produk otomasi serta sejumlah script canggih yang mampu menggnatikan puluhan hingga ratusan perintah program hanya dalam satu dua baris kalimat. Sejak hadirnya peralatan serba visual, produktivitas programmer meningkat drastis. Seorang programmer mampu menyelesaikan pekerjaan yang semula memerlukan 3 orang programmer. Bahkan dengan hadirnya berbagai script canggih dan SQL, programmer pemula pun sanggup menggantikan 10 programmer senior atau lebih. Diiringi dengan hadirnya sejumlah produk paket siap pakai, lowongan programmer turun drastis.

Hadirnya produk-produk otomasi, secara teoritis operator sudah tidak diperlukan lagi. Semua pekerjaan system support yang bersifat rutinitas juga digantikan dengan otomasi. Bahkan rekayasa lokal yang dulunya kerjaan sysprog atau SE pun tidak lagi diperlukan, karena sudah ditangani dengan mudah oleh otomasi.

Terlebih setelah muncul GUI di pertengahan dekade 1990an, profesi teknis seperti programmer dan support dan SE semakin terkikis. Orang-orang aplikasi tugasnya hanya seputar menyusun script dan halaman-halaman web saja. Sebutannya pun menjadi aneh dan tidak seragam. Ada yang menyebut web programmer, ada pula web master. Mungkin ada lagi yang lain apalah. Sebenarnya user pun banyak yang bisa melakukannya. Yang masih konsisten mungkin profesi DBA.

Di kelompok sistem juga sudah tidak jelas batas-batasnya, mana SE mana sysadmin dan mana systems support. Kadang hanya sysadmin saja untuk mengawal kinerja operasi sehari-hari. Instalasi, setup, pemecahan masalah dan pekerjaan musiman lainnya ditangani oleh tim SE dari vendor atau pihak ketiga (konsultan).

Padahal di era IT modern, otomasi tidak sebatas inboard saja. Otomasi sudah meluas ke wilayah outboard yang melibatkan aneka peralatan di luar wilayah IT seperti sensor kecepatan kendaraan, sensor dan pengendali polusi dll. Memang saat ini belum terlalu konvergen dengan sistem informasi sehingga kebanyakan masih ditangani oleh tim insinyur di luar tim SE. Kelak mereka akan konvergen. Misalnya, manakala ada melaju melebihi kecepatan yang diijinkan, maka sensor otomatis menyampaikan informasi kepada database kendaraan dan otomatis akan mengirim tagihan denda kepada pemiliknya, karena ada link antara database kendaraan dengan database e-KTP. Jika dalam jangka waktu tertentu tagihan tidak digubris, maka otomatis muncul laporan pengaduan dan perintah penangkapan di SI kepolisian. Itulan contoh konvergensi antara otomasi outboard dan sustem informasi dalam e-Gov (yang benar). Dalam situasi seperti ini, insinyur otomasi outboard dan SE adalah satu tim. Artinya, SE dituntut menguasai ketrampilan rekayasa kontrol.

SDM IT di dapur industri IT

Di lingkungan vendor atau industri IT, SDM IT secara umum dibagi dalam 2 kelompok tim, yaitu tim di dapur riset dan pengembangan (R&D) dan tim di wilayah pemasaran. SDM IT di R&D secara umum dinamakan principal engineer atau product engineer baik untuk software maupun hardware.

Principal engineer atau product engineer adalah SDM yang tugasnya melakukan mulai dari riset dan pengembangan produk-produk IT, baik untuk menciptakan produk-produk baru maupun menyempurnakan produk-produk yang sudah ada, hingga pengemasan dan dokumentasi. Untuk produk software disebut software engineer atau software developer dan untuk hardware umumnya disebut hardware engineer. Di wilayah tersebut sebenarnya masih ada jenjang dan pembidangan sesuai volume pekerjaan dan penamaannya kadang tidak selalu pakem seperti itu, tergantung selera dan kepentingan perusahaan. Jenjang tertinggi biasanya menggunakan istilah product architect. Jenjang terendah mungkin dokumenter, karena dengan menyusun dokumen, seseorang bisa menjadi tahu banyak. Bahkan yang lucu, di IBM ada kelompok dokumen yang penulisnya dipilih dari kalangan pengguna, yaitu kelompok red book.

Latarbelakang pendidikan dan pengalaman tentu disesuaikan dengan bidang masing-masing. Yang saya tahu, latarbelakang programming adalah wajib, baik untuk produk software maupun hardware. Untuk produk hardware, harus ada bekal systems programming atau mungkin cukup control programming (skup khusus). Sedangkan untuk produk software tergantung kategori produknya. Untuk kategori aplikasi (user-level software), bekalnya seperti programmer biasa. Untuk kategori sistem (system-level software), tentu harus berbekal systems programming yang memadahi. Baik kategori sistem maupun aplikasi, mereka harus memahami dan memiliki ketrampilan software engineering.

Namun seperti halnya di lingkungan pengguna, yang terpenting adalah pembuktian ketrampilan. Karena pada dasarnya, orang kerja yang paling penting dan yang dibayar adalah hasil kerjanya. Sederet gelar pendidikan tidak ada artinya kalo tidak memiliki ketrampilan. Banyak engineer R&D yang berasal dari kalangan pengguna.

SDM IT di lingkungan pemasaran IT

Lingkungan pemasaran produk-produk IT bisa seluruhnya satu bendera dengan dapur industri, bisa juga sebagian perusahaan terpisah yang bisnisnya hanya memasarkan. SDM di lingkungan tersebut lazim systems engineer (SE) untuk sistem dan software dan field engineer (FE) untuk hadrware. Pekerjaannya memberikan layanan teknis kepada pengguna. Pekerjaan SE minip dengan SE di lingkungan pengguna. Sedangkan FE mirip teknisi atau bengkel panggilan. Namun untuk mengoptimasi kerja mereka menggunakan strategi pembagian wilayah yang lazim disebut level-1 support dan level-2 support.

Level-1 support adalah tim SE dan/atau FE di lingkungan pemasaran yang pekerjaannya berinteraksi langsung dengan pengguna di wilayah pengguna. Tim ini bisa di bawah bendera principal maupun sekedar distributor atau dealer. Layanan tim ini seringkali harganya dikemas menjadi satu paket dengan harga pemakaian produk. Layanan utamanya adalah melakukan instalasi/setup dan meresolusi masalah. Namun kadang mereka sudah nimbrung sejak fase perencanaan dan perancangan sistem, dan pengguna kadang lengah, atau sengaja melibatkan mereka untuk maksud tertentu (?). Maklum misi utama mereka adalah memasarkan produk.

Level-2 support adalah tim SE dan/atau FE di lingkungan pemasaran yang pekerjaannya sebagai penghubung antara level-1 support dengan dapur industri (R&D). Tim ini selalu berada dalam bendera principal. Layanan yang diberikan hanya sebatas meresolusi product error. Jika level-1 support menemukan bahwa masalah yang sedang dihadapi adalah product error, maka harus segera menyampaikannya kepada level-2 support. Level-2 support lantas melakukan analisis dan determinasi lebih jauh guna mencari katagori masalah yang akan digunakan untuk melacak knowledgebase apakah masalah serupa sudah pernah ada dan sudah ada solusinya. Jika iya, maka level-2 support menginstruksikan kepada level-1 support untuk mengunduh solusi tersebut dan mengaplikasikannya di lapangan pengguna. Jika tidak, level-2 support segera menghubungi R&D untuk membuatkan solusi dan setelah solusi tersedia, mengirimkannya kepada level-1 support untuk mengaplikasikannya di lapangan pengguna.

Pentingnya SE di lingkungan pengguna

Level-1 dan level-2 support umumnya makin hari makin baik. Didukung dengan hadirnya internet, interaksi antar mereka dan antara level-1 dengan pengguna semakin efektif. Memang sudah menjadi kiat para pemain bisnis dalam iklim persaingan yang semakin ketat, para vendor tidak hanya adu kualitas produk, tetapi juga kualitas layanan prajual dan purnajual. Akibatnya, sebagian besar pengguna merasa tidak lagi perlu menggaji mahal SE sendiri. Selain bayarannya mahal, toh kerjaannya musiman dan semuanya tuntas ditangani oleh layanan vendor. Lagi pula sebenarnya mereka sudah dibayar karena harga mereka sudah dikemas satu paket dengan harga produk.

Di lingkungan pengguna cukup tim kecil yang mempu mengadministrasikan sistem dan memberikan layanan dukungan teknis tingkat awal saja. Yang penting mereka tangkas berhubungan dengan level-1 support yang disediakan para vendor. Karena SDM vendor umumnya menggunakan istilah SE, maka mereka pun sering disebut SE.

Sepintas kelihatannya benar, terutama dari sudut pandang efisiensi. Namun ada kekurangan yang sangat mendasar terutama manakala pengguna sedang merencanakan pengembangan. Karena SE pengguna sebenarnya belum memililki kualitas setingkat SE yang sebenarnya, maka dalam beberapa hal menyerahkan sepenuhnya kepada SE vendor. Akibatnya misi pengembangan berubah menjadi misi pemasaran produk. Hal ini pernah di alami oleh 2 bank BUMN berskala besar. Katakanlah Bank X dan bank Y.

Keduanya hampir sama besarnya, sama-sama sedang menuju ke model sistem terpusat dan kejadiannya pun pada kurun yang hampir bersamaan. Bedanya, Bank X baru setahun menikmati mimpi buruk dengan sistem SCO Unix tersebar berbasis PC (Qompaq).setelah downsize dari sistem terpusat berbasis mainframe. Sedangkan Bank Y memang baru saja menggelar IT ke cabang-cabang dengan sistem SCO Unix tersebar berbasis PC (Qompaq) setelah bertahun-tahun IT hanya untuk proses batch di kantor pusat. Dan itrupun sebagian besar belum online satu sama lain. Wal hasil memang keduanya beralih ke model sistem terpusat. Bank X menggunakan platform RISC dan Bank Y AS/400. Bank X sempat tersendat 3 tahun implementasinya, konon karena sulit mencari aplikasinya. Sedangkan Bank Y sempat down selama 3 hari entah kenapa. Yang aneh, sistem kartu kredit di Bank X maupun Y memilih mainframe dan lancar implementasinya maupun operasinya sampai hari ini.

Kalo kita cermati, RISC maupun AS/400 adalah produk vendor yang sama, vendornya mainframe juga. Kenapa tidak menawarkan salah satu saja biar seragam nggak ribet? Atau kenapa nggak satu pengguna satu produk saja? Kenapa Bank X harus RISC dan mainframe dan Bank Y AS/400 dan mainframe? Bukankah sang vendor memiliki tim SE yang sangat mumpuni untuk melakukan pengkajian? Katakanlah karena aplikasi kartu kredit yang ngetop hanya di mainframe, kenapa bukan mainframe saja yang ditawarkan? Padahal mainframe merupakan produk primadonanya dan sudah terbukti mendominasi perbankan di seluruh dunia.

Itulah seninya orang jualan.. dan itu sudah di luar jangkauan saya. Logisnya, vendor kan hanya bendera. Pelakunya kan manusia (sales) atau perusahaan lain (remarketer). Setiap penjualan tentu ada insentif bagi pelakunya. Yang menjual RISC ingin mendapat insentif. Yang menjual AS/400 juga sama. Demikian pula yang menjual mainframe. Jadi apa salahnya berbagi 🙂 Lagi pula mau pilih RISC maupun AS/400, di akhir hari kelak, jika Bank X dan Bank Y tetap hidup, pasti akan ke mainframe, entah karena bisnisnya yang berkembang maupun disetir oleh perkembangan teknologi. Namun yang jelas, jika ketika itu tim SE di Bank X belum keburu minggat (karena sumpek), pasti mainframe yang dipilih. Demikian pula di Bank Y, ketika itu ada SE, tapi hanya label. Jam terbangnya baru tahap belajar seputar PC dan SCO Unix.

Memilih platform, selain referensi juga kesederhanaan. Multiplatform dan enterprise memang bagus. Tapi hanya orang bodoh saja yang mengartikan bahwa IT kita harus nano-nano yang rame rasanya. Bagus yang dimaksudkan adalah portabilitasnya. Misalnya Linux adalah OS yang multiplatform. Ketika IT kita cukup skala PC, Linux oke. Ketika skala harus naik ke midrange, Linux juga masih oke. Setelah mentok dan harus ke mainframe, Linux tetep oke. Dengan demikian, bisa diharapkan perubahan di tingkat aplikasi sangat minimal dan investasi kita tidak terlalu besar seperti jika awalnya Windows lantas migrasi ke AIX dan akhirnya ke z/OS. Memikirkan hal semacam ini cukup sederhana. Tapi bagi yang belum pernah mengalami, bisa jadi tidak kepikir.

Yang paling penting dipertimbangkan dalam memilih platform adalah prediksi skalabilitas dan ketersediaan aplikasi. Kita tidak perlu menjadi pionir pemakai awal sebuah produk, kecuali untuk produk lokal dalam rangka misi mendukung inovasi dan kreativitas anak bangsa. Tanpa misi tersebut, lebih baik memilih produk yang paling banyak referensinya. Karena banyaknya referensi umumnya berbanding lurus dengan kualitas.

Nah.. hari ini sudah mulai ada titik terang. Perkembangan RISC dan AS/400 sudah mulai mentog, dan keduanya bermuara ke satu titik, yaitu zBX yang digendong oleh mainframe z/Enterprise. Produsen rupanya sudah mengantisipasi tuntutan kebutuhan kapasitas dan skalabilitas IT ke depan bahwa yang perlu di prioritaskan adalah e-Gov. Dunia hari ini sedang bergetar serempak menuju e-Gov. Skala muatan e-Gov tidak mungkin bisa dibandingkan.dengan perbankan maupun bisnis lain. Sementara produsen rupanya tidak ingin menggarap 3 arsitktur (RISC, AS/400 dan mainframe) dengan skalabilitas yang sama. Maka RISC dan AS/400 dipaksakan konvergen ke mainframe z/Enterprise, dan zBX adalah titik awalnya. Beruntunglah mereka yang sudah memulainya dengan mainframe. Karena betapapun smooth-nya konvergensi dari RISC atau AS/400 ke zBX dan kemudian ke mainframe z/Server murni, tentu ada konversi aplikasi.

Pentingnya SE dalam pembangunan e-Gov

Sudah berapa kali pemerintah negeri ini menyelenggarakan proyek IT? Mana saja yang berhasil? Di antara proyek-proyek yang pernah ada, barangkali yang skalanya nasional dan dipublikasikan secara luas sejak awal antara lain IT KPU dan e-KTP. IT KPU sudah lewat, maka kita semua (rakyat) seharusnya sudah bisa menyimpulkan berhasil atau gagal. Apakah kita pemilu dan pilkada sudah menggunakan “e”? Atau masih kertas dan tinta? Apakah penghitungan suara sudah komputasi, atau masih corat-caret pake pensil? Itulah tolok ukur awam yang bisa kita rasakan bersama dari belanja IT KPU yang tidak sedikit.

e-KTP belum tuntas. Meskipun di antara kita mungkin ada yang mampu memperkirakan, tapi rasanya masih terlalu dini untuk menilai. Saya bahkan belum melihat seperti apa wujud kartunya. Kelak setelah dinyatakan tuntas, kita bisa merasakan apakah e-KTP berhasil, atau sekedar abal-abal. Tolok ukurnya mudah. Yang susah bikin sistemnya. Dengan e-KTP, seharusnya seseorang tidak lagi bisa kehilangan identitas. Artinya, bila si Pulan lenyap “kesambergelap” dan tiba-tiba menyublim bugil di daerah atau pulau lain, identitas dirinya dapat diketahui pasti. Tinggal dihadapkan saja ke pos tertentu dan menyebutkan nama “Pulan”. maka layar komputer akan menampilkan sederet nama Pulan. Bila alamatnya juga disebutkan, maka hanya Pulan yang beralamat itu yang muncul di layar. Dengan sensor forensik akan ketahuan apakah Pulan yang muncul di layar komputer memang orang itu. Bahkan bisa jadi yang muncul nama lain jika ternyata orang itu bukan Pulan. Kalo bisa begitu, berarti e-KTP berhasil. Tapi kalo seribet KTP biasa, atau bahkan lebih ribet, berarti yang kita dapatkan hanya e-KTP abal-abal. Silakan simak posting ini.

Era e-Gov merupakan prospek paling gurih bagi para vendor IT. Terlebih di negara-negara yang konservatif menokohkan SDM berdasarkan rentetan gelar akademik serta kekayaan retorika dan kosakata terminologi pemerintahan tanpa melihat latarbelakang jam terbang di lapangan praktek IT. Mereka adalah sasaran empuk para vendor. Kurangnya pengalaman praktek dan pergaulan dengan vendor menjadikan mereka mudah disetir sesuai misi sang vendor. Parahnya lagi oleh misi para sales di balik bendera vendor seperti contoh kasus Bank X dan Y di atas.

Bagaimana dengan negeri kita? Saya tidak tahu persis siapa-siapa yang sedang diberi peran dalam pembangunan e-Gov dan siapa arsiteknya. Telah memiliki jam terbang sukses dimana saja sang arsitek kita? Semoga saja jatuh ke tangan SDM yang tepat. Namun yang mengherankan, masterplan IT disusun sendiri-sendiri setiap kabupaten/kota. Itulah yang menjadi tanda tanya besar. Sangat tidak lazim! Salah strategi apa salah orang yang dipercaya bikin strategi? Semoga saja jam terbang arsitek e-Gov kita bukan jam terbang seminar saja.

Yang lebih mengerikan, masyarakat kita selain berbakat mengagumi orang asing, juga mudah latah dalam menokohkan seseorang, tanpa dicermati lebih dulu apa latarbelakang si tokoh tersebut. Sifat ini bukan saja masyarakat awam, tapi juga orang-orang pemerintahan dan insan media. Belum lama ini kita baru saja menokohkan seseorang yang tidak tahu IT menjadi pakar telematika Indonesia kan? Ternyata orang tersebut hanyalah pehobi fotografi dan radio HT. Latarbelakang pendidikannya pun dari ilmu-ilmu sosial. Untung belum sampai menyerahkan proyek-proyek IT fital kepadanya. Semoga hal ini menjadi catatan sejarah agar tidak terulang.

Aplikasi IT yang termasuk jajaran paling komplex antara lain IT perbankan. e-Gov lebih komplex ketimbang perbankan. Jika perbankan saja kru IT-nya harus profesional yang punya jam terbang cukup, apa lagi e-Gov. IT perbankan yang dibangun dan dirawat oleh kru IT yang sangat profesional bisa acakadul manakala kemasukan campurtangan para petingginya yang tidak tahu IT. Apalagi IT sekomplex e-Gov dan dibangun berdasarkan rembug, pemikiran dan pendapat masyarakat awam IT 🙂

Yang selamat tentu negara-negara yang menokohkan profesionalisme. Mereka akan memasang tim SE yang berbekal jam terbang yang memadahi dan menguasai pengetahuan IT yang sangat luas, khususnya wawasan tentang bagaimana e-Gov seharusnya, untuk melakukan assessment yang benar guna menyusun strategi yang tepat sejak mempersiapkan infrastruktur hingga pengelolaan pengembangan dan perawatannya. Jangan sampai kelak baru jalan setahun dua tahun ternyata OS-nya sudah tidak di-support lagi, atau hardware-nya tidak memadahi dan harus upgrade, atau aplikasi harus dirombak karena tidak sesuai dengan harapan. Semua itu harus bisa diantisipasi dari awal oleh tim SE.

Tim yang kapabilitas dan kualitasnya seperti ini pasti tidak antusias ngalor-ngidul seminar dan diskusi, karena sudah tahu apa yang harus dikerjakannya. Terlebih mereka yang memiliki pengalaman di dapur industri, seakan gerak-gerik mata vendor sudah ada di genggamannya. Jadi … bukan tim ini yang menghadiri seminar, tetapi justru sebaliknya, tim ini memanggil para vendor untuk mempresentasikan solusi yang ditawarkannya. Bukan berarti tim ini akan mengikuti salah satu dari solusi vendor yang dianggap terbaik, tetapi sekedar menggretak agar setiap vendor yang berminat harus mempersiapkan SDM terbaiknya bila memang berminat berpartisipasi.

Pentingnya jam terbang IT bagi manajer IT

Pernah dengar layanan online sebuah maskapai penerbangan paling keren mandeg beberapa hari baru-baru ini? Saya tahu karena selain koran, hampir semua milis heboh membicarakannya. Konon ada kegagalan migrasi IT tapi nggak ada persiapan fallback. Kok bisa ya… merencanakan migrasi tanpa fallback plan?.

Pernah dengar seorang bos di sebuah bank BUMN paling top iseng mematikan server kartu kredit di siang bolong pada tahun 2002? Padahal sistem perbankan termasuk kartu kredit harus hidup 24 x 7 lho! Konon gara-gara si bos iseng “uji nyali” dengan teman-teman operator, nantangin siapa berani mijit saklar berwarna merah sebesar bungkus rokok di badan server System z. Melihat bentuk saklarnya saja operator sudah pada jiper. Yaah aslinya mereka tahu, saklar itu berada di belakang UPS sehingga jika di-off, server mati. Rupanya si bos merasa bangga nggak ada yang brani lantas tanpa ragu dia sodokkan jempol pas di angka 0. Kontan saja sistem kartu kredit berhenti di tempat dan butuh sekitar 2 jam melakukan recovery. Meskipun tidak melihat langsung, saya pas kebetulan sedang disana, sehingga sempat melihat senyum kecutnya sang bos tolol itu.

Pernah dengar bank swasta IT-nya mati sampai 18 hari? Kejadiannya kalo nggak salah tahun 2003. Hampir semua manajer di divisi IT dipecat, termasuk kawan saya. Konon gara-gara merubah parameter tertentu di server pusat, katika itu AS/400. Entah parameter yang mana kurang jelas karena yang ngomong orang aplikasi.

Pernah dengar sebuah lembaga negara membangun IT dengan biaya besar tapi bukan untuk produksi? Saya sempat ikut ngrecokin milisnya pada saat masih tahap perancangan, kalo nggak salah pada tahun 2003. Banyak ilmuwan IT dari perguruan tinggi paling top berpartisipasi menjadi relawan disana. Yang saya bingung, dari awal semua pihak sudah tahu IT tersebut tidak akan diproduksikan. Padahal skalanya nasional yang tentu biayanya tidak kecil.

Mungkin kalo kita gali ingatan, masih banyak kejadian lucu lainnya yang patut dicatat dalam sejarah. Termasuk kisah downsizing yang gagal total dan terpaksa belum 2 tahun harus investasi ulang untuk kembali ke centralized system. Itu semua akibat manajer dan auditor tidak berbekal jam terbang praktek IT. Instansi pemerintah atau BUMN biasanya ada kendala kepangkatan dalam memilih seseorang untuk menduduki kursi pimpinan. Lebih baik memilih orang yang pangkatnya cukup tanpa latarbelakang profesi ketimbang yang bekal jam terbangnya cukup tapi pangkatnya belum sesuai.

Kadang kita dengar orang mengatakan untuk memimpin sebuah pekerjaan, ketrampilan teknis tidak diperlukan. Yang terpenting pengalaman manajemen. Saya rasa ini hanya berlaku untuk posisi pimpinan puncak yang bersifat politis. Untuk posisi semacam manajemen IT pasti 100% omong kosong. Bagaimana mungkin seseorang yang tidak memiliki jam terbang di lapangan IT memimpin pekerjaan IT. Jangan disamakan dengan para cukong bernyali besar menggarap proyek IT pemerintah atau BUMN seorang diri. Cukong ginian memang hebat. Tanpa bekal jam terbang, hanya bermodal duit, dia bisa pinjam tangan orang-orang dalam untuk menggarap proyeknya. Tidak ada satupun hikayat yang mengatakan kerjaannya sukses. Yang sukses ya si cukong itu, meraup keuntungan besar. Justru masuknya vendor model gituan gara-gara manajer IT tidak tahu IT. Kalo dia tahu, meskipun mau kong kali kong, tetap saja pekerjaan harus sukses.

Manajer IT yang berbekal jam terbang di lapangan IT, tentu lebih cermat dalam mengelola pekerjaan. Pertama dia akan mengevaluasi diri sendiri wilayah mana yang dia yakin dia menguasai dan wilayah mana yang dia tidak menguasai. Di wilayah yang tidak dia kuasai, dia akan menempel ketat SDM yang dia percaya. Dia juga pasti selalu dekat dengan SE yang dia miliki, jika ada. Karena SE dimana-mana dianggap sebagai pakar yang paling tahu sistem yang dia tangani.

Sedangkan manajer IT yang tidak memiliki jam terbang di lapangan IT, meskipun tidak buta IT, umumnya tidak memahami tahap-tahap pekerjaan lapangan IT. Sehingga pernyataan atau perintahnya sering aneh dan tidak dimengerti oleh bawahannya. Umumnya terlalu lambat dalam membuat keputusan, atau bahkan terlalu cepat tanpa mempertimbangkan resiko. Rasanya contoh-contoh kasus di atas sudah cukup dijadikan bukti.

Terlebih pada saat-saat awal pembangunan masterplan infrastruktur IT atau pengembangan infrastruktur IT. Peran manajer IT sebagai pengambil keputusan sangat kritis jika tidak memiliki pengalaman dan pengetahuan yang luas soal IT. Selain dirinya harus memiliki wawasan yang luas soal sistem yang sedang dia tangani, juga harus mampu melihat kecenderungan perkembangan teknologi produk-produk IT secara obyektif. Untuk itu, selain harus memiliki jam terbang sebagai SE, juga selalu bekerja sama dengan para SE dalam melakukan assessment, termasuk mendengarkan opini-opini dari luar.

Pentingnya jam terbang IT bagi auditor IT

Auditor IT juga harus memiliki jam terbang praktek IT yang cukup. Audit tidak cukup dilakukan dengan omong-omongan sambil melihat dokumen dan gambar. Seperti halnya QA, auditor IT harus mampu menjejaki secara teknis bahwa yang ada di gambar dan dokumen serta yang dijelaskan oleh tim proyek IT. Bedanya, QA adalah internal audit yang kerjaannya mencakup hingga hal-hal rutin setiap kali ada obyek atau update yang akan dipromosikan ke sistem produksi. Sedangkan audit IT umumnya external, bisa divisi lain atau bahkan perusahaan kontrakan, dan biasanya hanya untuk proyek-proyek yang menghadirkan sesuatu yang baru.

Jika IT yang sudah dinyatakan lulus audit ternyata bobol, maka auditor adalah orang pertama yang harus diperiksa. Lantas QA sebagai internal auditor. Yang terakhir baru SDM IT penanggungjawab obyek tersebut. Lulus audit bisa karena (1) memang lulus beneran atau (2) tidak lulus tapi diluluskan. Untuk kasus (2), auditor (dan QA) secara yuridis adalah bersalah. Jika ternyata tidak ada kebohongan tapi bobol, maka audotor (dan QA) kena hukuman akibat kesalahan audit. Tinggal dicermati kesalahan audit tersebut keteledoran lumrah atau ketidakmampuan melakukan audit. Tentu ketidakmampuan akan memberatkan sang auditor karena bisa dianggap kebohongan profesi. Semetara sang penanggungjawab obyek/proyek tidak bersalah karena dia telah paparkan apa adanya dan diluluskan.

Jika kebobolan ternyata karena auditor telah dibohongi, maka auditor (dan QA) kena 2 kesalahan sekaligus. Kesalahan pertama adalah kesalahan audit. Yang kedua adalah kebohongan profesi. Auditor (dan QA) yang bisa dibohongi pasti karena tidak tahu IT. Bagaimana dia bisa menilai indahnya sebuah gambar jika dia buta? Terlepas seberapa banyak sertifikasi yang dia miliki, dia dianggap telah melakukan kebohongan profesi atau bahkan penipuan. Kalo dia praktek dengan ijin resmi, ijinnya harus dicabut. Terlepas ada ijin praktek atau tidak, sang pemilik proyek bisa memperkarakannya sebagai kasus penipuan.

Namun untuk kasus kebohongan ini, si penanggungjawab obyek/proyek IT secara yuridis juga bersalah karena berbohong. Apesnya jika ternyata karena pertanyaan dilemparkan kepada orang yang tidak tepat. Misalnya pertanyaan detil soal OS dilempar ke pimpinan proyek yang tidak menanganinya langsung. Nah.. untuk menghindari hal-hal tersebut sekaligus menangkal hadirnya auditor palsu (penipu profesi), maka sebaiknya tidak pernah menjawab pertanyaan apapun ketika diaudit sebelum sang auditor mengakses obyek yang sedang diaudit. Dari sana kita akan tahu sang auditor mengerti apa yang dilakukan atau tidak. Di lain pihak, pemilik proyek/obyek juga harus menyadari hal ini agar jangan memberi peluang auditor menyalahgunakan otoritasnya untuk menutupi ketidak mampuannya. Karena jika muncul kesalahan audit, baik meluluskan yang gagal maupun menggagalkan yang lulus, yang rugi adalah pemilik proyek/obyek.

Yang pasti dan harus, jangan pernah berpikir audit IT pekerjaan konseptual. Audit IT adalah pekerjaan teknik yang dibatasi dengan berbagai spesialisasi. Untuk dapat menjejaki obyek-obyek yang akan diaudit, audit IT harus mampu masuk ke obyek tersebut dan memeriksanya menggunakan tools yang disediakan. Kalo obyek tersebut berada di server, maka dia harus bisa memasuki dan menggunakan audit tools yang ada di server tersebut. Bagaimana bisa mengaudit Linux dan z/VM kalo tahunya cuman Windows? Bagaimana bisa mengaudit mainframe yang CPU dan harddisk terbentang beda propinsi jika yang terbayang hanya konfigurasi sekelas warnet? Nah.. para bohir juga jangan terbalik (tertipu) gara-gara auditor tahunya hanya Windows, maka jangan pake selain Windows agar bisa diaudit.

Sayangnya, beberapa kali saya berhadapan dengan auditor IT, umumnya tidak seperti yang saya bayangkan. Meskipun sertifikatnya direnteng mirip gelar akademik, ternyata banyak yang tidak memiliki pengetahuan IT yang cukup. Sehingga sering nggak nyambung dengan penjelasan kita. Mereka hanya berpatokan prosedur yang mereka dapatkan dari pelatihan audit tanpa memahami kaitannya dengan misi IT yang mreka audit. Padahal yang diperlukan bekal jam terbang di lapangan IT, bukan sekedar pengerahuan. Pantesan yang diaudit hanya seputar dokumen perencanaan, perancangan dan prosedur. Argumentasinya mbulet mirip kentut di celana. Sekali tempo kita iyakan tapi tidak kita implemen di lapangan, dia tidak tahu. Tapi tidak merasa bersalah karena merasa kerjaannya telah selesai. Jika SOP audit IT memang demikian, maka bisnis audit IT sama juga bisnis tanaman “gelombang cinta” tempo hari. Hanya orang tolol saja yang mau beli.

Namun ternyata auditor yang sering saya jumpai justru yang seperti itu. Juni 2008 saya diminta memberikan pelatihan IT audit di sebuah BUMN.(Bank Y contoh di atas). Bosnya (KaUR) minta agar dibuatkan kurikulum khusus tidak lebih dari 3 hari. Bahkan dia datang ke rumah membawa buku OS/390Audit untuk pedoman menyusun materi. Saya pun nurut dan dalam 3 hari materi siap dan saya antar kepadanya. Iseng-iseng saya nanya apakah para calon peserta sudah mengerti OS/390. Dia jawab belum. Saya nanya lagi apakah mereka bisa login ke OS/390 dan melakukan sesuatu sebagai user. Katanya juga belum. Bagaimana bisa mengaudit wong masuk saja belum pernah?. Saya ajukan syarat mereka harus kenal dengan semua komponen yang akan diaudit. Sang KaUR tidak menjawab sampai saya pamitan. Mungkin dia cari pelatih lain yang mau melatih sesuai permintaannya.

Dari situ saya bisa bayangkan berapa banyak auditor yang dicetak dengan cara seperti itu. Pantas saja sulit menerima argumentasi. Mirip mbuletnya jaksa yang menolak bukti dari forensik digital. Susah dijelaskan. Maka tidak aneh jika ada auditor yang mendukung masterplan e-Gov disusun sendiri-sendiri tiap kabupaten/kota dengan alasan proyek-proyek IT yang dari pusat umumnya tidak lulus audit. Jadi yang terpenting lulus audit, bukan misi penyelenggaraan IT itu sendiri. Mungkin lebih bagus lagi tiap RT/RW, karena lebih mudah mengevaluasinya. Analoginya, sepeda motor, mobil, kereta api, kapal laut, kapal terbang dll tidak lulus karena resiko kecelakaannya banyak membawa maut. Hapuskan saja semua dan gantikan dengan sepeda ontel dan becak yang terbukti paling aman.

Pendidikan SDM IT

Bicara soal pendidikan, kadang suka muncul kilasan kontradiktif. Manakala kita nonton filem atau baca komik, seorang guru silat yang sudah tua renta itu sekali gebrak bisa bikin kocar kacir ratusan pendekar muda. Di pawayangan juga sama. Bhisma, pendekar tua renta dan guru Drona, pendekar yang sudah pikun itu nyaris tak terkalahkan dalam perang besar di Kuruksetra. Tapi yang saya lihat dan alami di dunia nyata tidak demikian. Tidak ada yang seperti Bhisma dan Drona di pawayangan maupun suhu encek-encek di filem HongKong. Ternyata ketangkasan tarung lebih tergantung pengalaman ketimbang tingkatan ilmu yang kita miliki. Kyu (sabuk berwarna) yang gemar latih tanding, tidak aneh mengalahkan yudansha (sabuk hitam) yang hanya cuap-cuap di lapangan. .

Demikian pula di jagat IT. Oleh karena itu belajar IT sebaiknya jangan melulu teori. Kampus memang mengajarkan sesuai kurikulum dan titik beratnya untuk program S1 pasti teori. Namun sebaiknya mahasiswa jangan pasrah bongkokan dengan kurikulum, melainkan mesti kreatif latih tanding sendiri di luar kampus. Sehingga kelak begitu lulus tidak sekedar mendapatkan secarik ijazah dan menjadi orang yang siap dilatih. Setidaknya sudah memiliki bekal yang cukup untuk bekerja sebagai programmer di atas pemula. Sebab kalo tidak demikian, lantas apa bedanya dengan mereka yang dari kujuruan lain? Kalo cuman menyusun halaman web, lulusan apapun banyak yang mampu. Kalo cuman manajemen sistem informasi, kebanyakan juga bukan berbekal akademik, karena semua orang yang berkecimpung di seputar IT lama-lama akan tahu snediri. Lantas dimana esensi dari lulusan pendidikan akademik IT?

Sebenarnya tidak hanya IT. Kejuruan apapun diharapkan memberi bekal lulusannya kemampuan bekerja setidaknya sedikit di atas pemula. Lagipula kan lucu, ngaku lulusan S1 elektro kok TV sendiri rusak sama sekali tidak mampu membetulkan. Lulusan S1 mesin kok sepeda motor sendiri mogok nggak bisa ngapa-ngapain. Kita-kita yang tahu mungkin bisa memaklumi. Tapi masyarakat awam tidak akan memaklumi. Tokoh dan penentu kebijakan pendidikan juga tidak etis memaksa masyarakat awam untuk memaklumi.

Praktek IT yang paling penting hemat saya adalah programming. Karena inti dari IT memang programming. Setidaknya pandangan awam memang demikian. Mesin-mesin IT beroparasi umumnya karena software, dan software adalah wujud dari hasil programming. Maka sangat aneh jika ada orang IT tidak ngerti programming. Selain itu, programming sangat melandasi ketangkasan berpikir. Dan dari programming, pengetahuan akan meluas ke obyek yang sedang diprogram. Programmer di bank kadang memiliki pengetahuan perbankan yang lebih luas dari kebanyakan bankir.

Setelah cukup lincah, lantas berlanjut ke systems programming. Karena selain lincah berlogika juga membiasakan kita memahami kerja masin komputer yang sebenarnya. Memang mau tidak mau harus mendalami arsitektur komputer yang kita gunakan untuk berpraktek. Artinya, kalo kita berpraktek dengan Intel, mau tidak mau ya harus mempelajari arsitektur Intel. Untuk sementara akademisi, mempelajari produk spesifik katanya rugi rugi waktu dan pikiran. Tapi apa boleh buat, ketimbang tidak mencoba kan nggak pernah tahu apa-apa, malah rugi sekolah kan? Pengajar pun tentu ngecap doank jika belum pernah mencobanya. Jadi di kelas mirip guru agama berkhutbah tentang akhirat. Yang diajar belum tahu dan yang ngajar juga belum pernah mengalami.

Apesnya, banyak pihak yang meremehkan programming. Entah siapa yang memulainya dulu ya? Ada yang mengatakan: “Ah itu kan cukup mereka lulusan kursus”. Bahkan ada yang dengan bangga mengatakan: “Ah programming mah bukan level saya donk”. Mestinya dijawab: “Lah sampeyan level apa dan bisa apa?”. Memang kadang menggemaskan. Programming dianggap seperti pekerjaan ngaduk semen di bidang teknik sipil, atau ngelas di teknik mesin. Padahal programming merupakan maskot utama IT. Programming membutuhkan kecerdasan lebih ketimbang corat-coret menggambar diagram maupun ngobrol sana-sini menggali informasi. Seorang product/software architect biasanya ambil bagian kunci dalam fase programming. Bahkan hardware architect sering kali memaparkan rancangannya dengan emulasi yang dia program sendiri. Hercules, sebuah freeware emulator mainframe untuk komputer berbasis Intel, dibikin oleh mantan arsitek hardware yang membuat mesin mainframe. Mereka itulah manusia IT sejati. Meskipun bergelar profesor doktor jangan ngaku orang IT kalo nggak bisa programming.

Ilmuwan IT

Ilmuwan IT atau ulama IT adalah orang yang mengkaji IT dari sisi keilmuan. Yang paling mudah menengarainya dilihat dari sertifikasi akademisnya, misalnya bergelar PhD atau ScD di bidang ilmu komputer atau informatika atau apa saja yang berkaitan dengan komputasi dan/atau teknik kontrol digital. Dalam masyarakat, idealnya mereka adalah narasumber IT yang paling handal dalam menyelesaikan kasus-kasus komputasi yang sangat teknis. Ketangkasannya boleh kalah dengan praktisi. Maklum, ketangkasan dan ketrampilan sangat tergantung dari keseharian. Walaupun masih SD kalo tiap hari ngoprek Java bisa jadi lebih tangkas dari ilmuwan. Namun manakala ketemu kasus yang tidak lazim, maka disitulah seharusnya nampak kelebihan ilmuwan.

Misalnya (1) ada tantangan bikin program untuk capacity planning. Peralatan yang tersedia hanya compiler C/C++ dan spreadsheet Microsoft Excel. Meskipun sederhana, program tentu melibatkan sejumlah formula statistika seperti regresi linier, M/M/c/K/K, D/c/K/K dan sebagainya yang tidak tersedia di C/C++. Excel menyediakan formula regresi, tapi queuing system tidak tersedia..

Praktisi IT yang tidak terbiasa dengan komputasi statistika boleh jadi menyerah. Praktisi statistika pun jika tidak menguasai komputasinya, mungkin juga tidak sanggup. Paling-paling mengusulkan agar dipasang SAS atau SPSS.

Kasus di atas jika diserahkan kepada ilmuwan IT, seharusnya beres. Meskipun formula-formula tersebut tidak tersedia dalam peralatan yang ada, ilmuwan IT seharusnya sangat sanggup merekayasanya sendiri. Mereka sudah dibekali dengan metoda numerik dan teori algoritma yang sangat mumpuni. Bekal statistika-nya boleh saja tipis. Namun kemampuan komputasinya menjadikannya mudah menyelesaikan masalah-masalah ginian. Hanya saja, mungkin perlu waktu jika sang ilmuwan IT tidak fasih dengan C/C++ atau Excel. Memang aneh sih ilmuwan IT nggak fasih C/C++ 🙂

Contoh lain misalnya (2) sebuah pabrik yang didukung dengan sejumlah mesin berbasis motor diesel konvensional ingin meingkatkan efisiensi operasi tanpa mengorbankan perawatan mesin-mesin tersebut. Selama ini biaya perawatan mesin yang paling besar adalah biaya ganti oli yang dilakukan reguler setiap bulan sekali. Disana ada manajer peralatan yang pakar mesin dan tidak ada rencana investasi mesin-mesin baru. Idenya, bagaimana caranya ganti oli dilakukan sesuai kondisi oli, bukan berdasarkan tanggal, karena dia yakin umur oli tergantung jenis oli, kondisi mesin dan intensitas kerjanya. Dia tahu cara mengukur kondisi oli, bahkan membuat alatnya bila perlu. Yang dia butuhkan adalah bagaimana alat ukur bisa otomatis memberi tanda pada layar komputer manakala ada mesin yang harus segera ganti oli dan mencatatnya ke database perawatan peralatan. . Data tersebut selain dikaitkan dengan perhitungan biaya operasi juga bisa digunakan untuk memberi petunjuk mesin-mesin mana yang kondisinya sudah tidak normal berdasarkan panjang pendeknya umur oli.

Yang harus diyakini, perubahan kondisi materi apapun selama ada dampak (effect) pasti bisa dideteksi. Selanjutnya pasti bisa dibuatkan alat sensor. Kalo sudah ada sensor pasti urusan beres. Informasi non-numerik pasti bisa dinumerikkan atau dikodekan. Informasi non-digital pasti bisa di-digital-kan. Tinggal kecerdikan manusianya.

Namun demikian, manusia umumnya terbelenggu oleh pengetahuan, lingkungan, kebiasaan dan pengalamannya. Praktisi IT seperti saya yang tidak terbiasa merekayasa hardware bisa jadi menyerah tidak sanggup. Praktisi hardware IT pun belum tentu siap menanganinya jika tidak terbiasa merekayasa interfacing peralatan non IT ke komputer. Terlebih peralatan non-standard bikinan sendiri.

Untuk contoh kasus di atas, solusi yang terbaik adalan panggil ilmuwan IT, seharusnya beres. Yang di luar jangkauan si ilmuwan IT hanya bagaimana mengindikasikan kondisi oli secara fisik atau visual yang paling mudah untuk dikonversi menjadi digital. Mungkin sudah ada sensornya tapi bukan untuk dikaitkan dengan IT. Mungkin juga harus bikin alat sendiri dengan input kekentalan, berat jenis, kecepatan menghantar panas, atau warna dll, terserah pakarnya. Mungkin harus diextrimkan secara fisik atau kimiawi dengan mengambil contoh satu tetes setiap hari dan dicampurkan dengan zat tertentu sebelum diukur. Bagaimana cara pengambilan contoh dan pencampuran dilakukan secara otomatik juga sepenuhnya diserahkan kepada pakarnya.

Tugas sang ilmuwan IT adalah merekayasa konversi dari indikator fisk atau visual yang ditampilkan oleh alat ukur tersebut ke data/sinyal digital dengan protokol tertentu agar bisa diterima oleh komputer sebagai data/sinyal dari device tertentu yang dikenal komputer. Bisa juga asal digital, tapi di sisi komputer harus dibikin driver (system program) agar data yang datang dikenal sebagai data/sinyal dari device tertentu. Dengan demikian data bisa disampaikan ke database.

Apakah semua ilmuwan IT bisa melakukan hal serupa? Harapan sebagian masyarakat termasuk saya sih demikian. Karena dari beberapa silabus pendidikan IT dari sejumlah perguruan tinggi selalu mengandung komputasi (algoritma dan programming) dan/atau kontrol digital. Tapi ya nggak tahu juga kalo ada IT yang tanpa komputasi, entah apa namanya dan apa misinya. Maklum lah wong awam akademis 🙂 Saking awamnya jangan-jangan kedua contoh di atas malah sudah menjadi makanan sehari-hari mahasiswa S1 IT semester awal he he 🙂 Namun demikian, mohon beribu maaf, ilmuwan IT yang tidak mampu memecahkan masalah komputasi hemat saya tetap tidak patut diakui sebagai ilmuwan IT.