Perusahaan harus mulai rajin baca blog dan keluhan customer di Internet

Baca surat pembaca di detik.com tentang layanan Garuda Indonesia yang berjudul “ Status OK Tiket Garuda Bukan Berarti OK Terbang” sangat menarik. Saya kutip sebagian keluhannya:

Saya melakukan chek in Jam 08.45 (belum terlambat) di desk khusus kartu GFF. Pada saat chek in diterima oleh Mbak Gita. Namun, betapa terkejutnya saya karena ternyata pesawat telah penuh dan tidak ada kursi kosong. Padahal di tiket tertera status OK.

Lalu ada beberapa komentar, salah satunya sebagai berikut:

Dewi, Hal ini persis terjadi dengan suami saya. Status ticket OK, dan satu malam sebelum keberangkatan ada petugas Garuda yang menelpon untuk kepastian keberangkatan dan suami saya menjawab bahwa suami saya confirm berangkat. Tetapi aneh bin ajaib waktu akan check in namanya tidak ada. Garuda cukup bertanggung-jawab dan akhirnya suami saya bisa terbang. Tetapi yg saya heran kenapa hal ini bisa terjadi dan ternyata tidak hanya terjadi pada suami saya tetapi pada lebih dari satu penumpang. Ada apa denganmu Garuda???

Komentar-komentar lainnya cukup pedas untuk dibaca, diantaranya ada yang mendukung untuk tetap mendapatkan larangan terbang ke Eropa sebagai pelajaran buat Garuda. Belum ada (baca: mungkin tidak akan ada) komentar dari pihak Garuda soal ini.

So, sekali lagi, menurut saya, perusahaan-perusahaan di Indonesia harus mulai rajin membaca blog serta surat pembaca di media-media online di Internet. Informasi-informasi seperti ini akan menjadi informasi yang menurunkan citra perusahaan dan menjadi informasi gratis yang sangat berharga untuk kompetitor-kompetitor perusahaan kita.

Semoga bermanfaat!

Posting lain yang berhubungan:

• Perusahaan harus mulai rajin baca blog!!!

Iklan

Perusahaan harus mulai rajin baca Blog!!!

Sampai saat ini, jika kita jadi customer suatu perusahaan dan mendapat tanggapan yang buruk atas suatu keluhan kita, maka cara yang paling ampuh dan ditakuti oleh perusahaan adalah menulis keluhan kita di media masa (surat pembaca). Jika sebelumnya kurang ditanggapi, maka setelah kita keluhkan di koran, mendadak perusahaan tersebut menjadi bersikap baik kepada kita.

Banyak orang, juga perusahaan yang belum menyadari bahwa BLOG juga telah menjadi senjata ampuh yang mungkin lebih berbahaya secara jangka panjang. Kini, jika anda posting sesuatu di WordPress, dalam waktu beberapa menit sudah bisa di-search dari Google. Luar biasa!

Nah saya punya satu contoh yang menarik! Dua kali saya menulis keluhan tentang SMS Banking BNI yang sampai saat ini belum mendapat tanggapan yang jelas dan tuntas. Saya tidak berniat untuk menjatuhkan BNI, hanya menceritakan keluhan tersebut apa adanya di BLOG saya. Hal seperti ini sering dilakukan pula oleh banyak orang. Coba anda search di Google dengan kata kunci ‘SMS Banking BNI‘. Jangan kaget, hasilnya adalah seperti ini:

Dua entry pertama adalah situs resmi BNI, dan dua entry berikutnya (urutan 3 dan 4) adalah keluhan yang saya tulis. Bayangkan, sebetulnya effort BNI untuk menanggapi dengan cepat keluhan saya mungkin tidak besar, tapi dampak negatifnya adalah seperti itu. Dan posting keluhan ini akan tersimpan terus di Internet. Berapa besar biaya iklan yang telah dikeluarkan BNI untuk mempromosikan Layanan SMS-Banking; itu menjadi sia-sia hanya karena keluhan yang tidak segera ditanggapi.

Jadi belajar dari kasus ini, saya mengingatkan kepada perusahaan-perusahaan (apapun) agar mulai rajin-rajin melakukan seaching keluhan customernya di Internet dan tentunya segera menanggapinya secara serius. Mudah-mudahan saran ini bermanfaat!

Salam,
Arry Akhmad Arman
Nasabah setia BNI, juga praktisi TI

Hati-hati dengan Keamanan Wifi Anda!

Buat ahli jaringan dan sekuriti, saya kira info ini bukanlah hal yang baru. Tapi untuk anda yang awam, mungkin ini adalah informasi berharga yang harus anda pikirkan ketika membuka akses informasi penting melalui jaringan wireless.

Dalam satu kegiatan workshop/seminar tentang IT Security Kamis-Jumat kemarin, Pak Budi Rahardjo dan Pak Andika mendemokan kepada para peserta bagaimana cara menyusup ke jaringan Wifi yang sudah dilengkapi proteksi menggunakan WEP, bahkan sudah menggunakan filter MAC address.

So, hati-hati! Jangan biarkan informasi super penting dapat diakses melalui Wifi secara langsung! Harus ada pengamanan extra untuk mengakses informasi tersebut! Paling tidak, setelah sukses menjebol proteksi wifi, masih ada benteng lain untuk menjaga akses informasinya!

Semoga bermanfaat!

Re-definisi Fungsi dan Ukuran Prestasi Auditor IT

Kemarin dan hari ini saya menemani Pak Budi Rahardjo untuk suatu Workshop IT di Preanger, Bandung. Ketika sedang membahas berbagai standar security di lingkungan IT, ada satu pertanyaan yang menarik:

Bagaimana mengatasi standar yang berbeda antara pelaksana IT dengan Auditor IT, sehingga kami (pelaksana IT), cenderung selalu salah karena banyak temuan dalam pelaksanaan IT?

Akhirnya menjadi diskusi yang ramai dan mengarah pada suatu kesimpulan seperti ini

Pertama, fungsi atau misi seorang auditor harus didefinisikan ulang, bukan untuk mencari-cari kesalahan pelaku, tapi menemukan kelemahan sistem, memahami penyebabnya, dan turut memikirkan solusinya dalam bentuk rekomendasi-rekomendasi perbaikan sistem.

Kedua, cara mengukur prestasi auditor bukan dari banyaknya temuan (saja), tapi dari kualitas pemahaman “temuan”, pemahaman penyebabnya, juga kualitas rekomendasi-rekomendasinya. Bahkan seorang auditor yang dengan yakin menjamin bahwa sistem yang di-audit-nya sangat baik (tak ada temuan), tapi didukung laporan yang sangat teliti dan sistematis, maka auditor itu harus dianggap berprestasi!

Ketiga, harus ada standar (acuan) yang disepakati bersama antara pelaku IT dan auditor IT. Jangan kucing-kucingan. Kebanyakan, auditor menggunakan standar tertentu yang dirahasiakan kepada pelaku IT, supaya banyak temuan dan dianggap berprestasi. Ini terkait dengan yang kedua. Salah satu peserta dari Krakatau Steel manyampaikan bahwa di KS sudah ada standar yang disebut standar KS.

Mari kita renungkan kembali, apa sebenarnya tujuan Audit IT? Tentunya untuk meyakinkan bahwa manajemen IT sudah dijalankan dengan benar untuk kepentingan perusahaan. Nah kalau hasil Audit mengatakan sudah baik, mengapa harus mencari-cari lagi kesalahan? Bukankah tujuan kita sudah tercapai?

Semoga bermanfaat!

Dua Faktor Utama Penyebab Kegagalan IT Plan

Sejak kemarin sampai hari ini saya menyampaikan workshop tentang pengembangan IT Plan. Framework dan metodologi untuk melakukan pengembangan IT Plan sebetulnya sudah banyak yang bisa dipilih dan sudah mulai matang, tapi pada prakteknya tidak sedikit kegagalan yang sering dialami ketika melakukan perancangan IT Plan. Apa penyebabnya?

Pertama, Technocentric View; perancangan berorientasi pada teknologi, bukan pada bisnis. Seharusnya bisnis dijadikan acuan, teknologi dirancang mengikuti rencana bisnis ke masa depan.

Kedua, Fokus Bisnis Lemah; rencana bisnis ke depan akan dijadikan acuan perancangan, sehingga fokus bisnis yang lemah otomatis akan membuat IT plan akan lemah juga karena mengacu pada sesuatu yang tidak fokus.

Semoga bermanfaat!

‘Project History’ adalah Sesuatu yang Penting Untuk Meningkatkan Kualitas Pelaksanaan Project

Ketika sebuah project dijalankan, biasanya akan banyak masalah-masalah tidak terduga yang kita hadapi. Meskipun dalam tahap project planning kita sudah melakukan risk assessment dan risk planning, tetap saja ada sesuatu yang mungkin tidak terduga yang bisa terjadi. Seorang project manager yang mempunyai jam terbang tinggi mungkin bisa dengan cepat menangani keadaan karena berbagai pengalaman yang tersimpan di kepalanya. Tapi bagaimana dengan project manager pemula yang jam terbangnya masih rendah?

Bagaimana menularkan pengalaman tersebut kepada orang lain di dalam perusahaan? Harus ada suatu mekanisme untuk share pengalaman project, baik pengalaman positif maupun pengalaman buruk dalam menangani berbagai kesulitan project.

Jika anda membaca buku Project Management, salah satu hal yang selalu dianjurkan ketika melakukan project closing diantaranya adalah mengupdate pengalaman project ke dalam suatu kumpulan project history (experiences), lalu di-share secara online untuk semua pelaku project di dalam perusahaan. Setiap kali seseorang menghadapi masalah dalam menjalankan project, tinggal search ke knowledge base perusahaan. Jika kejadian serupa pernah dihadapi oleh orang lain dan pengalamannya di-share disana, maka orang yang sedang menghadapi masalah tersebut dapat belajar dari pengalaman orang lain. Dengan cara ini, lambat laun, kualitas pelaksanaan project di suatu perusahaan akan meningkat terus.

Siapa yang biasanya me-manage project history tersebut? Biasanya dilakukan oleh PMO (Project Management Office).

Semoga bermanfaat!

Banyak Perusahaan Tidak Mempunyai Standar Dokumentasi Pengembangan Software

Bagaimanapun bentuknya, saya kira perusahaan-perusahaan besar pada umumnya mempunyai standar proses pengembangan software yang secara umum biasanya disebut SDLC (Software Development Life Cycle). Di beberapa perusahaan yang manajemen TI nya sudah mapan, SDLC tersebut biasanya diterapkan secara konsisten baik untuk pengembangan software oleh pihak internal, maupun pengembangan software yang melibatkan pihak eksternal (outsourcing). SDLC yang diterapkan secara ketat secara tidak langsung akan meningkatkan kualitas software yang dihasilkan. Bagian dari SDLC juga mensyaratkan adanya dokumentasi software yang baik.

Apakah SDLC saja serta keberadaan dokumentasi software sudah cukup? Jawabannya biasanya baru diketahui setelah ada masalah-masalah berkaitan dengan software aplikasi yang sudah pernah dibuat. Beberapa permasalahan tipikal diantaranya adalah sebagai berikut:

1. Dokumentasi software ternyata tidak lengkap, ada bagian penting dari software yang tidak dijelaskan dengan cukup, sehingga sulit untuk memahaminya.
2. Format dan struktur dokumen berbeda-beda
3. Cara pemodelan berbeda-beda. Mungkin ada yang masih menggunakan flowchart + ER Diagram saja, ada yang menambahkan Data Flow Diagram (DFD), ada yang mencampur adukan UML dengan DFD, atau ada yang secara penuh sudah menerapkan UML.

Permasalahan-permasalahan tersebut di atas akan menghambat tujuan-tujuan sebagai berikut:

1. Melakukan modifikasi software menjadi sulit dilakukan. Kadang perusahaan ingin melakukan modifikasi kecil dari software yang sudah dibuat dan sudah diluar masa garansi. Tapi sulit dilakukan karena hambatan dokumentasi.
2. Melakukan pengembangan lebih lanjut menggunakan vendor lain. Dokumentasi yang buruk, yang hanya dimengerti oleh pembuatnya saja, menyulitkan dipahami oleh pihak lain yang akan meneruskan pekerjaan tersebut.
3. Melakukan integrasi dengan aplikasi lain. Ketika sistem berkembang dan ada tuntutan integrasi, dokumentasi yang buruk mungkin akan menyulitkan untuk memahami struktur data, cara berkomunikasi data, apalagi kalau ada keperluan modifikasi algoritma untuk mencapai tujuan integrasi.

Bagaimana solusinya? Sederhana!

Buatlah standar (template) dokumentasi pengembangan software aplikasi di perusahaan anda. Standar dokumentasi berbeda dengan standar proses pengembangan (SDLC).

Semua pengembangan software, baik yang dilakukan oleh pihak internal maupun cara outsource harus membuat dokumentasi sesuai standar tersebut. Hal yang harus diingat adalah:

Jangan membuat standar dokumentasi yang bentuknya tidak biasa. Saya sarankan untuk mengadopsi dari suatu standar, lalu lakukan penyesuaian minor. Untuk pemodelannya, saya menganjurkan untuk menggunakan UML secara penuh.

Nah, kalau ini sudah tercapai, anda buka dokumen software manapun selalu sama bentuknya dan kelengkapannya cenderung lebih terjamin karena mengikuti template yang sudah ada.

Semoga bermanfaat!

‘Software Testing’ Harusnya Dilakukan Dari Awal Hingga Akhir Pengembangan Aplikasi Perangkat Lunak

Dalam salah satu komentar balik dalam posting tentang ‘etos kerja yang tinggi‘, saya berjanji mau share ‘benang merah’ dari presentasi saya dalam satu acara yang saya ceritakan disana. Materi yang saya sampaikan waktu itu, sesuai dengan permintaan, adalah tentang UAT (User Acceptance Test). UAT adalah prosedur baku yang biasanya dilakukan untuk menguji perangkat lunak yang dibangun, dan akhirnya setelah melalui proses tertentu, pada akhirnya memberikan pernyataan bahwa perangkat lunak tersebut layak digunakan.

Saya ingin share dan mengingatkan saja (mungkin sebagian besar pembaca sudah mengetahuinya) bahwa

pengujian sebuah perangkat lunak idealnya dilakukan tersebar sejak awal pengembangan sampai menjadi produk yang dinyatakan selesai secara engineering.

Mengapa? Mari kita perhatikan gambar berikut.

Grafik sederhana tersebut memperlihatkan bahwa effort relatif yang harus dikeluarkan untuk memperbaiki sebuah perangkat lunak akan membesar luar biasa jika kita biarkan terus. Jika pada saat DEFINITION (menentukan user requirement) kita melakukan pengujian user requirement dengan teliti, maka effort relatifnya adalah 1 (satu). Jika kita biarkan lolos begitu saja sampai tahap development (design, programming), maka effort tersebut bisa bengkak sampai 6 kali lipat. Nah, lebih mengerikan lagi! Jika kita biarkan sebuah software tidak diuji secara serius dan ada kesalahan yang baru disadari setelah release, maka effort relatif yang harus kita lakukan untuk memperbaiki dampaknya bisa mencapai 100 kali lipat. Jadi pilih mana?

UAT biasanya dilakukan setelah proses development selesai. Jika kita mengharapkan manfaat maksimum dari pengembangan software di perusahaan atau organisasi kita, maka sebaiknya jangan hanya mengandalkan proses UAT, tetapi juga meningkatkan pengawasan (pengujian) software pada tahap-tahap sebelumnya.

Diharapkan pada saat proses UAT, tidak ditemukan lagi kelemahan engineering, tapi hanya sedikit perbaikan dari perspektif user dan pengoperasian. Error teknis seharusnya sudah terdeteksi dan diperbaiki pada tahap sebelumnya!

Mudah-mudahan bermanfaat.

Etos Kerja Tinggi, Salah Satu Kunci Keberhasilan Organisasi!

Kemarin seharian di Jakarta saya mengisi acara training/workshop untuk satu Bank swasta papan atas di Indonesia. Ada hal menarik yang ingin saya share dalam forum ini. Kami mulai acara jam 08.30. Semua peserta mengikuti dengan serius tapi santai, banyak yang bertanya dengan semangat tinggi. Setelah shalat Jumat ada selingan acara Ice Breaking yang dilakukan, lalu segera dilanjut dengan acara training yang kami sampaikan. Singkatnya, acara bersama kami berlangsung hingga hampir pukul 17.30 dan masih berlanjut dengan acara internal mereka.

Ada satu hal yang menarik. Hingga akhir acara bersama kami, saya masih melihat dengan jelas, hampir di semua peserta, suatu semangat yang tetap tinggi. Sebagai pembicara, tentunya sayapun terbawa suasana, semangat terus sampai akhir.

Dari situ saya memahami, mengapa Bank ini bisa maju. Memang banyak faktor penentunya, tapi saya cukup yakin, salah kunci utama kemajuannya adalah ‘etos kerja yang tinggi‘ tersebut!

Andai, etos kerja seperti itu bisa kita ciptakan di lingkungan pemerintahan dan di kalangan Anggota Dewan, tentunya negara ini akan maju pesat!

Identifikasi Ancaman dalam Disaster Recovery Jangan Terfokus Hanya Pada Bencana Alam

Salah satu hot issue dalam dunia IT dan bisnis saat ini adalah DRC/DRP. DRP adalah Disaster Recovery Plan, suatu plan (rencana) yang disiapkan untuk melakukan tindakan preventif, melakukan penanggulangan dan pemulihan pasca bencana. Dalam konteks IT, DRP biasanya didukung oleh suatu DRC atau Disaster Recovery Center, suatu lokasi alternatif yang menduplikasi sebagian sumber daya IT terpenting dalam satu perusahaan atau organisasi yang biasanya terletak di Data Center, sehingga fungsi bisnis/organisasi yang tergantung pada IT akan tetap berjalan jika bencana terjadi.

Baik, saya tidak akan mengajari DRC/DRP yang saya yakin anda sudah paham itu. Saya hanya ingin mengingatkan bahwa saat ini telah berkembang berbagai jenis ancaman baru. Di lain pihak (mungkin karena sering terjadinya bencana alam), ketika mengidentifikasikan ancaman dalam merancang DRC/DRP sering hanya fokus pada bencana alam saja. Saya sarankan, anda lebih terbuka untuk memikirkan juga ancaman-ancaman lain non bencana alam. Ancaman non bencana alam cukup sering terjadi, tidak terduga, dan bisa memberikan dampak kerugian yang tidak kalah hebatnya, walaupun tidak mengancam keselamatan manusia.

Security jaringan atau security aplikasi dianggap sebagai salah satu ancaman baru yang harus ditangani secara serius.

Sebuah bank papan atas yang mendapat predikat bank dengan layanan terbaik di Indonesia, terpaksa menghentikan layanan Internet Bankingnya selama 15 hari karena ada ancaman security (beberapa posting saya di kategori IT menceritakan tentang ini). Kalau melihat lamanya penanganan masalah tersebut, serta ketidakmampuan menjawab berapa lama perbaikan akan dilakukan, saya dapat menyimpulkan bahwa ancaman security dalam Internet Banking Bank tersebut tidak masuk dalam daftar prioritas ancaman dalam DRP nya.

Dalam DRP, selalu terdefinisi dengan jelas suatu batas waktu maksimum yang diijinkan untuk terhentinya suatu layanan.

Tidak salah memang, tiap perusahaan berhak menentukan prioritas dari perspektifnya masing-masing. Ini hanya contoh saja bahwa ada ancaman-ancaman baru yang bisa menghasilkan kerugian besar dalam bisnis.

Bahkan, merger antar dua perusahaan (misalnya bank) bisa menghasilkan disaster sistem IT nya. Bayangkan, dua dirut bank bersalaman setelah menandatangani dokumen merger, diliput banyak wartawan dan hasil merger menjadikan bank baru tersebut menjadi bank yang memiliki asset terbesar. Sementara, orang-orang IT dari dua bank yang merger itu sedang jungkir balik menyelesaikan masalah kompatibilitas dari sistem mereka yang sangat berbeda. Sangat mungkin, beberapa hari setelah merger, terjadi masalah besar dalam sistem IT yang menyebabkan kerugian yang sangat besar.

Semoga bermanfaat.