Kamis, 2 Maret 2017

Hari ini berkesempatan mengunjungi salah satu BUMN di Jakarta. Mereka memiliki kendala dalam aplikasi operasional, bukan karena minimnya aplikasi tapi justru jumlah aplikasi yang ada telah mencapai ratusan (wow!). Hal ini membuat bagian IT menjadi sibuk hanya untuk mengurusi ratusan aplikasi2 tsb. Jelas saja bingung, lha jumlah personil IT-nya hanya ada belasan sementara aplikasinya mencapai lebih dari 200! Dan yg membuat lebih rumit lagi, aplikasi2 tsb berdiri sendiri2 tidak ada kesamaan data, misalnya seorang pegawai login ke aplikasi X dgn user “abc” tapi login ke aplikasi Y dgn user “def”.

Fiuuhhh…… sruput teh dulu…..

Ada beberapa hal yg dikeluhkan oleh bagian IT:

1. Dari aplikasi operasional yg berjumlah lebih dari 200 itu, hampir semuanya dikembangkan oleh unit2 di daerah tanpa kordinasi dgn pusat
2. Hampir semua aplikasi dikembangkan oleh pihak ketiga yg seringkali tidak mau membagi source code-nya, sehingga setiap pengembangan harus dilakukan oleh vendor yg sama berulang2
3. Tidak adanya perencanaan roadmap aplikasi sehingga aplikasi2 saling tumpang tindih tanpa standarisasi dan tanpa perencanaan

Dari keluhan2 tsb, bagian IT meminta arahan, bagaimana caranya mengurangi “kesibukan” operasional mereka dan mulai menata aplikasi2 menjadi lebih fokus.

Saran saya untuk mengatasi hal tsb:

1. Tentukan framework standar yg ingin digunakan, terutama framework yg memberikan arahan terkait peta aplikasi. Untuk dunia telekomunikasi, framework yg bisa digunakan adalah TAM dari tmforum.org. TAM atau dulu sering dianggap sbg singkatan dari Telecommunication Application Map (sekarang diklaim sudah terbuka untuk semua bisnis jasa, tidak hanya telekomunikasi saja) memberikan arahan untuk menjawab 3 hal:
   1. dimana posisi suatu layanan aplikasi ?
   2. seperti apa konstelasi layanan aplikasi ?
   3. apakah layanan aplikasi kami telah komplit dan memenuhi semua aspek ?
2. Setelah ditentukan frameworknya, selanjutnya ada 2 jalur yg bisa diambil:
   1. jalur cepat: membangun aplikasi yg sesuai dgn framework dan semua aplikasi eksisting dihapus. Hal ini lebih mudah dari aspek pembangunan tapi akan sulit dalam melakukan sosialisasi (change management)
   2. jalur lambat: mengevaluasi seluruh aplikasi yg ada, lalu memetakan setiap aplikasi ke dalam framework, lalu menentukan:
      1. aplikasi mana yg akan menjadi pusat data (masterdata)
      2. aplikasi mana yg bisa dikembangkan kemampuannya
      3. aplikasi mana yg harus dikurangi kemampuannya
      4. aplikasi mana yg harus dihapus
      5. aplikasi mana yg harus dibuat dari nol
3. jika jalur lambat yg dipilih, maka akan ada 3 fase:
   1. fase pengembangan, dimana kemampuan yg terdapat pada framework namun belum ada aplikasinya, maka aplikasinya akan dibangun dari nol, atau aplikasi yg sudah ada tapi perlu dikembangkan untuk mencakup lebih banyak kemampuan. Selama proses pengembangan, aplikasi yg sudah ada tapi tidak dikembangkan atau akan dihapus akan diintegrasikan dgn aplikasi utama yg sedang dikembangkan, untuk tujuan kesamaan data
   2. fase paralel run, dimana aplikasi utama dan aplikasi lain (yg akan dihapus) berjalan bersama, sembari dilakukan sosialisasi kepada user untuk bisa berpindah ke aplikasi utama
   3. fase go live, dimana aplikasi lain dihapus dan hanya aplikasi utama yg berjalan.
4. Hal terpenting untuk diperhatikan adalah point 2.2.1 di atas, yaitu pentingnya 1 masterdata untuk membangun Single ID (hanya ada 1 login untuk semua aplikasi) dan kemudian bisa ditingkatkan menjadi Single Sign On (SSO) yg berarti login di 1 aplikasi maka user tidak perlu lagi menginputkan login di aplikasi lainnya

Mumet? sruput teh dulu dan biarkan konsultan yg bekerja  🙂