Selasa, 01 Maret 2011

IT – Infrastructure Library (IT- Service Management) Sebuah Acuan Pengoperasian Teknologi Sistem Informasi di Industri


A.   PENDAHULUAN
Saat ini bagi dunia industri, Teknologi Informasi (TI) sudah menjadi salah satu pilar organisasi utama dalam menjalankan bisnisnya. Hampir semua sektor industri bisnis maupun pemerintahan (produksi, perdagangan, keuangan, transportasi, kesehatan, pendidikan, informasi dan komputer, telekomunikasi, administrasi pemerintahan, dsb) telah menerapkan Teknologi Informasi (TI) di Institusinya dari skala rendah sampai dengan skala yang kompleks. TI telah dianggap menjadi pendukung (supported) keberhasilan bisnis sekaligus juga menciptakan (enabler) bisnis-bisnis baru. Hal ini pula menyebabkan hampir di semua institusi mengimplementasi unit organisasi TI nya terutama di industri bisnis untuk mengelola investasi TI nya.
Sebuah institusi / organisasi dalam menjalankan Teknologi Sistem Informasi (System IT) terdapat tiga pilar utama (triangle pilars) keberhasilan penerapan TI, yaitu :
·         People, mencakup pelanggan, pengguna, pengelola TI, pengelola management.
·         Process, mencakup metodologi, petunjuk pelaksana dalam hal ini adalah ITSM.
·         Technology (Product), mencakup tools, teknologi dan produk TI.
Masa lalu seringkali praktisi TI lebih terfokus pada pilar Technology sebagai faktor keberhasilan penerapan TSI dalam mencari solusi permasalahan dan melupakan pilar yang lain seperti People dan Process sehingga pada kenyataannya masih menghadapi kendala (atau kurang sukses) dalam penerapannya, apalagi dikaitkan dengan ukuran efektifitas dan efisiensi. Menyadari hal itu, saat ini praktisi IT memberikan fokus kepada pilar lainnya yaitu Process (juga People) yang selama ini tertinggal untuk keberhasilan penerapan TI di organisasi bisnisnya.
IT Infrastructure Library (IT Service Management) adalah salah satu proses menerapkan TSI dalam triangle IT tersebut bagi institusi / organisasi.
ITSM sering disebut sebagai “Arsitektur Operasional” untuk TI. Secara garis besar ITSM memilki 2(dua) level yaitu (a) level pengambil keputusan yang menetapkan sasaran-sasaran organisasi kemudian menurunkannya menjadi aktifitas-aktifitas besar yang harus dilaksanakan sesuai dengan hasil-hasil yang diharapkan nantinya yang dapat diukur; (b) level operasional merupakan level yang lebih rinci yang menetapkan proses-proses yang harus dijalankan oleh setiap unit organisasi berdasarkan masukan-masukan (input) prosesnya dan harus menghasilkan (output) sesuatu yang ditentukan. Secara sederhana level ITSM menggunakan metodologi Deming (Plan - rencana proyek; Do – proyek; Check – audit; Act - pelaksanaan) sebagai siklus peningkatan kualitasnya secara terus-menerus dan bertahap.


Gambar 1. Level dari ITSM

B.  SEKILAS TENTANG ITSM
ITSM adalah sebuah petunjuk/panduan proses-proses yang dijalankan untuk pengelolaan Teknologi Informasi bagi sebuah institusi/organisasi sehingga tujuan dari penerapan TI nya dapat dicapai secara efisien dan efektif.
Service Management adalah layanan-layanan TI (IT services) kepada pelanggan (customer/user) yang berfokus terhadap berbagai perspektif dari pelanggan dengan menggunakan pendekatan atau metodologi yang berorientasi kepada konsistensi proses-proses yang dijalankan.
Sasaran dari Service Management adalah :
·         Menyelaraskan layanan-layanan TI nya sedemikian sehingga akan selalu memenuhi kebutuhan bisnis / organisasi dimana akan selalu berubah.
·         Menyediakan peningkatan kualitas dari layanan-layanan TI nya.
·         Secara jangka panjang menyediakan pengurangan biaya yang cukup berarti namun dengan peningkatan kualitasnya atas layanan-layanan TI nya.
Secara best practice unit organisasi TI di sebuah institusi bertanggung jawab terhadap pengelolaan TI dan menyediakan layanan-layanan TI baik kepada pengguna internal di institusinya dan kepada pelanggan (pihak eksternal) yang diwakili oleh atau disebut unit organisasi bisnis. Dalam memenuhi layanan TI nya, unit organisasi TI dimungkinkan memperoleh dukungan dari pihak lain diluar institusinya yang disebut provider dan atau suplier Teknologi Informasi.
Dalam memenuhi layanan TI nya kepada unit organisasi bisnis, ITSM menyarankan adanya Service Level Management (SLM) yang meliputi :
·         Service Level Agreement (SLA) untuk berbagai layanan yang ditentukan antara unit organisasi TI dengan unit organisasi bisnis.
·         Underpinning Contract (UC) untuk berbagai layanan yang ditentukan antara provider/suplier TI yang memberikan dukungan kepada unit organisasi TI.
·         Dan Operational Level Agreement (OLA) didalam unit organisasi TI sendiri.

Gambar 2. Hubungan Suplier, Unit Organisasi TI, Unit Organisasi Bisnis
SLA, UC dan OLA (SLM) berbentuk dalam sebuah dokumen kesepakatan antara pihak yang garis besarnya memuat hal-hal antara lain :
·         Pendefinisian layanan-layanan TI apa saja yang diberikan dan diterima oleh Pihak yang terlibat.
·         Pendefinisian kualitas serta jangka waktu tersedianya layanan dari setiap layanan TI yang didefinisikan.
·         Pendefinisian biaya/harga dan penalti (reward & punishment) atas layanan TI yang terpenuhi dan yang tidak terpenuhi dari kesepakatan tersebut dari dan ke para pihak yang terlibat.
·         Pendefinisian pengecualian-pengecualian yang dimungkinkan selama SLA / UC / OLA berjalan.
ITSM menyarankan agar layanan TI pada sebuah institusi/organisasi dilakukan secara terpadu (atau ‘satu pintu’) yaitu melalui unit organisasi TI nya, agar kepastian dan akuntabilitas nya dapat terjaga serta memudahkan pengelolaannya. ITSM tidak menyarankan unit organisasi bisnis mendapatkan layanan langsung dari pihak lainnya selain unit organisasi TI yang ada.

Gambar 3. Hubungan Suplier, Unit Organisasi TI, Unit Organisasi Bisnis Yang Tidak Diperbolehkan
Berdasarkan OGC (Office of Government Commerce – UK) dan CCTA (Central Computer and Telecommunications Agency – UK Government) model ITSM memilki 10(sepuluh) disiplin dan 1(satu) fungsional yang terbagi menjadi 2(dua) disiplin besar, yaitu Service Delivery dan Service Support dan fungsional Service Desk serta Security Management.
Adapun disiplin rinciannya adalah sebagai berikut :
1.    Service Delivery :
    1. Service Level Management.
    2. Financial Management for IT Services.
    3. Capacity Management.
    4. IT Service Continuity Management.
    5. Availability Management.
2.    Service Support :
    1. Release Management.
    2. Change Management.
    3. Configuration Management.
    4. Problem Management.
    5. Incident Management.
3.    Service Desk (funsional)
4.    Security Management (payung pelindung sistem infrastruktur).

Gambar 4. Model Referensi ITSM
Model referensi ITSM ini dapat dijadikan sebagai acuan pelengkap sebuah model untuk unit organisasi TI di sebuah institusi/organisasi.

C.  LEBIH JAUH IT SERVICE MANAGEMENT (ITSM)
C.1. Service Support
Menyediakan panduan/petunjuk proses-proses yang sifatnya pendukung atas layanan TI.

C.1.1. Configuration Management
Semua komponen TI yang berperan dalam penyediaan layanan TI disebut Configuration Item (CI). Sebuah configuration item (CI) memilki ciri-ciri :
·         Berperan/diperlukan untuk pemberian layanan TI.
·         Dapat diidentifikasi secara unik.
·         Memungkinkan adanya perubahan dari kondisi/keadaan komponen.
·         Dapat dikelola.
Didalam configuration management ini juga dibentuk sebuah Basisdata Configuration Management Database (CMDB) yaitu sebuah basisdata dimana berisi semua detail-detail dari setiap CI dan detail-detail relasi yang penting diantara CI’s nya.
Seringkali terdapat kerancuan dalam penentuan CI dengan komponen TI/bisnis lain yang sebenarnya adalah masuk kategori aset. Aset adalah elemen atau komponen atau bagian termasuk proses dari bisnis atau organisasi secara keseluruhan, sedangkan CI adalah elemen atau komponen atau bagian dari infrastruktur TI atau sebuah item yang dikaitkan dengan sebuah infrastruktur TI dimana masuk dibawah kontrol dari Configuration Management.
Sasaran dari Configuration Management adalah sebagai berikut:
·      Menyediakan informasi mengenai total infrastruktur TI yang masuk kedalam (proses-proses) ITSM dan atau yang masuk kedalam pengelolaan TI (IT Management).
·      Menjaga kontrol infrastruktur TI saat pelaksanaan monitoring, pemeliharaan dan updating informasi untuk semua sumber daya yang terkait dalam pemberian layanan TI, status dan histori dari CI dan relasi-relasi dari setiap CI.
Proses pada Configuration Management dapat digambarkan pada gambar dibawah ini.

Gambar 5. Proses pada Configuration Management
Proses-proses yang dilakukan dalam Configuration Management adalah :
·         Merencanakan kegiatan-kegiatan configuration management.
·         Mengidentifikasi kandidat-kandidat komponen TI baru yang dapat dijadikan CI dan memverifikasi CI yang lama.
·         Mendaftarkan dan mencatat CI’s ke CMDB.
·         Menentukan status akuntansi dari CI’s
·         Melakukan kontrol, update data dan audit CI’s di CMDB.
Adapun infrastruktur TI yang dijadikan Configuration Item (CI’s) harus memenuhi informasi antara lain :
·         Jenis layanan yang diberikan oleh setiap CI.
·         Persyaratan lingkungan agar CI bekerja optimal.
·         Profil data lengkap dari CI (hardware / software).
·         Informasi dari dokumentasi terkait lain seperti prosedur-prosedur, proses dan kontrak-kontrak (SLA’s, OLA’s, UC’s).
·         Manual agar berfungsi (work instructions).
·         Relasi-relasi kepada CI’s lainnya (realtionships between CI’s).
·         Baseline models yang ditentukan.
Configuration Management yang baik dengan relasi-relasi antara CI yang benar akan memudahkan dalam menentukan DAMPAK jika satu CI mengalami kejadian ‘kegagalan’ (incidents).
Dalam Configuration Managemen juga ditentukan Configuration Baseline. Dimana configuration baseline dapat didefinisikan sebagai berikut :
·         Konfigurasi dari sebuah produk (hardware / software) atau sistem yang dibangun yang menjadi spesifik pada saat tersebut, dimana menangkap informasi baik struktur dan detail dari produk/sistem tersebut.
·         Snapshot atau sebuah posisi dimana direkam adalah baseline. Meskipun posisi/status akan berubah (di-update) dikemudian hari, maka baseline tidak berubah dan berlaku sebagai referensi kondisi awal dan sebagai pembanding posisi sekarang.

Gambar 6. Status dari CI’s


C.1.2. Incident Management
Sasaran dari Incident Management adalah sebagai berikut :
·         Untuk memperbaiki operasi layanan menjadi normal secepat mungkin sesuai SLA yang disepakati.
·         Jika terjadi incidents, meminimalkan dampak pada operasional bisnis.
·         Menjamin level kualitas dan ketersediaan layanan yang terbaik sesuai SLA yang disepakati.
·         Mengelola incidents dan permintaan layanan mulai dari awal hingga akhir dan mengkomunikasikannya kepada pihak-pihak yang bekepentingan hingga incident tersebut ditutup.
Dalam model referensi ITSM Incident Management berkaitan erat dengan fungsi Service Desk, dimana Service Desk memiliki peran sbb :
·         Mengontrol incidents. Service Desk menjadi pendekatan yang lebih terstruktur.
·         Sebagai Single Point of Contact (SPOC).
·         Sebagai wajah dari unit organisasi TI nya.
·         Bukan sebuah proses, tetapi merupakan sebuah fungsional dalam metodologi ITSM.
·         Tempat dimulainya proses/prosedur eskalasi masalah.
·         Semua laporan (berbagai jenis) datang terlebih dahulu ke Service Desk (=Service Requests & Incidents).
·         Bertanggungjawab untuk memberikan dukungan ‘first line’ dan membantu dalam keseharian operasional dari layanan TI.
·         Dilihat dari sudut pandang pengguna/pelanggan, Service Desk hendaknya bersifat terpusat, lokal (nomor kontak) dan transparan (seolah-olah ada kapansaja, dimana saja).
Terdapat beberapa terminologi yang perlu diketahui dalam Incident Management sbb :
·         Incident : segala kejadian / interupsi yang bukan bagian dari prosedur standar layanan atau yang menyebabkan berkurangnya kualitas dari layanan tersebut.
·         Work-Around : metode / solusi sementara dari penghindaran sebuah incident sehingga operasional standar normal masih berjalan / dilanjutkan.
·         Service Request : setiap incident yang bukan kegagalan dalan infrastruktur TI (mis. pendefinisian ulang password, tambahan fitur layanan).
Proses pada Incident Management dapat digambarkan seperti gambar dibawah ini.
Gambar 7. Proses dari Incident Management
Proses-proses penting yang dilakukan pada Incident Mangement adalah:
·         Mendeteksi incident dan mecatat incident dari Service Desk.
·         Mengklasifikasi setiap incident dan permintaan layanan (Service Request) dalam hal dampaknya (impact) dan uregency-nya.
·         Menentukan prioritas penyelesaian setiap incident berdasarkan level high, medium, atau low.
·         Mengkategorisasikan setiap incident, misalnya kategori hardware atau software.

C.1.3. Problem Management
Sasaran dari Problem Management adalah sebagai berikut :
·         Menjamin minimalisasi dampat operasional ketika incident dan problem terjadi yang disebabkan oleh errors didalam infrastruktur TI.
·         Menghindari incident yang sama terjadi kembali akibat errors yang sama atau errors lainnya yang belum terdeteksi.
·         Meningkatkan produktifitas atas penggunaan sumber daya (TI) dengan mengetahui dan memahami cara bagaimana menggunakannya (dibentuk Knowledge Database).
Adapun terminologi yang berkaitan dengan Problem Management adalah :
·         Problem : error yang tidak/belum diketahui yang menjadi akar penyebab satu atau lebih incident.
·         Known Error : Sebuah kondisi yang terjadi setelah dilakukan diagnosa yang berhasil atas akar penyebab dari sebuah atau lebih incident, dan ketika dipastikan ada sebuah CI yang gagal. Merupakan suatu keadaan dimana error-nya dapat dihilangkan dengan mengimplementasi perubahan pada CI.
Proses awal yang dilakukan dalam Problem Management setelah mendapatkan eskalasi incident adalah :
·         Mencatat eskalasi incidents.
·         Menugaskan sumber daya (people,technology, tools) untuk menanganinya.
·         Lakukan workaround terlebih dahulu agar dampak operasional bisnis tidak terganggu terlalu lama.
·         Tindaklanjuti problem tersebut ke proses-proses berikutnya.

Gambar 8. Proses Awal dari Problem Management
Tindaklanjut proses berikut dari Problem Management adalah :
a.    Mencari akar penyebab masalah sehingga berubah dari kondisi ‘Problem’ menjadi kondisi ‘Known Error, dengan melakukan identifikasi, klasifikasi permasalahan; menugaskan sumber daya (people, hardware, software, tools) untuk mencari penyebabnya; menyelidiki dan mendiagnosa data/informasi yang didapat.
b.    Mencari dan mengimplementasi solusi terbaik sehingga merubah dari kondisi ‘Known Error’ menjadi kondisi ‘Error closure’, dengan melakukan identifikasi dan pencatatan errors yang terjadi.
c.    Eskalasi ke pihak penyedia solusi dengan memberikan data-data (informasi) diatas sehingga dapat dikembangkan / dicari software & hardware solusinya.
Gambar 9. Proses Lanjutan dari Problem Management

C.1.4. Change Management
Sasaran Change Management adalah untuk mengimplementasi perubahan yang telah disetujui dan diotorisasi oleh anggota-anggota Change Management. Perubahan yang akan diimplementasi diyakini terbukti efisien dan efektif sehingga implementasinya atas infrastruktur TI yang ada atau penambahan layanan-layanan TI yang baru memilki risiko yang dapat diterima terhadap operasional bisnis.
Adapun terminologi dalam Change Management adalah :
·         Change : penambahan, modifikasi atau penggantian dari ‘sesuatu’, yang disetujui dan didukung CI’s atau baseline CI’s.
·         Request for Change : penggunaan formulir untuk mencatat detail-detail permintaan sebuah perubahan terhadap CI. RFC dimungkinkan dikirim dari setiap unit proses dari ITSM.
·         Forward Schedule of Change : jadwal yang berisi detail-detail dari semua perubahan yang telah diotorisasi untuk pelaksanaan implementasi dan tanggal usulan implementasinya. Menginformasikan ketergantungan setiap perubahan.
ITSM mengkategorikan dampak/level dari setiap Perubahan yang akan diimplementasi sebagai berikut :
·         Standard : perubahan dapat dieksekusi tanpa menghubungi Change Manager (perubahan sesuai standar manual).
·         Catagory 1 : berdampak kecil pada layanan-layanan bisnis. Hanya Change Manager cukup untuk mengotorisasi RFC ini.
·         Category 2 : berdampak skala menengah pada layanan-layanan bisnis. RFC ini harus didiskusikan di CAB (Change Advisory Board). Change Manager meminta saran untuk otorisasi dan perencanaannya.
·         Category 3 : berdampak besar pada layanan-layanan bisnis. Keseluruhan management terlibat dalam proses keputusan ini.
Prioritas dari sebuah Perubahan yang akan diimplementasi dapat dikategorikan sebagai berikut :
·         Urgent. Segera memerlukan perubahan, persetujuan oleh Change Advisory Board / Emergency Committee (CAB/EC).
·         High. Perubahan diperlukan secepat mungkin.
·         Medium. Perubahan akan memperbaiki errors atau fungsionalitas yang hilang / terganggu. Kondisi yang berjalan saat ini tidak berdampak parah sehingga dapat dijadwalkan kemudian atau bisa dilakukan saat upgrade.
·         Low. Perubahan hanya memperbaiki hal kecil, sehingga tidak diperlukan jadwal yang spesifik. Bisa dilakukan saat release atau upgrade.
Proses-proses pada Change Management dapat digambarkan sebagai berikut :

Gambar 10. Proses dari Change Management
Selama proses Change Management berjalan ITSM menyarankan untuk dilakukan audit secara periodik dan audit ini dilakukan oleh organisasi eksternal yang independent.
Untuk mendukung proses Change Management, ITSM menyarankan dibentuknya sebuah CAB (Change Advisory Board) dengan anggota-anggotanya paling tidak setingkat manager yang terdiri dari Change Manager, Release Manager, Service Level Manager, Incident Manager, Problem Manager, Configuration Manager, Financial Manager, perwakilan Manager dari user atau departemen lain dan perwakilan dari unit bisnis.

Gambar 11. Anggota-anggota dari Change Advisory Board (CAB)

C.1.5. Release Management
Sasaran dari Release Management adalah sebagai berikut :
·         Merencanakan dan mengelola rollout (implementasi masal) dari software dan hardware.
·         Mendisain dan mengimplementasi prosedur-prosedur secara efisien dan efektif.
·         Mengelola ekspektasi customer selama rollout.
·         Menyetujui (proses persetujuan) isi dan rencana rollout untuk sebuah release.
·         Mengimplementasi release software dan hardware baru ke dalam lingkungan production.
·         Mengelola dan menjaga keamanan semua master software dalam pustaka (library) software yang ditentukan.
·         Meng-update CMDB menggunakan proses Configuration Management untuk menjamin bahwa semua hardware dan software lisensi yang telah di-rollout atau hardware dan software lain yang terpengaruh telah ter-update di CMDB. Sehingga aman dan memudahkan dalam pelacakan nantinya.
Contoh arsitektur yang disarankan oleh ITSM untuk pustaka software dan hardware adalah seperti gambar berikut :
Gambar 12. Arsitektur Pustaka untuk Software & Hardware
Adapun jenis-jenis formulir release dapa dikelompokkan sebagai berikut :

Gambar 13. Jenis-jenis Formulir Release

C.2. Security Management
Proses-proses Security Management adalah :
·         Merupakan proses atas tingkat pengelolaan yang tepat dari keamanan pada informasi dan layanan-layanan TI.
·         Merupakan pengamanan dalam hal sistem keamanan secara lebih terstruktur dan terorganisasi.
·         Mengelola dan mengendalikan prosedur-prosedur sistem keamanan.
Security Management selain sebagai pendukung proses-proses ITSM juga sebagai pelindung (shield). Dengan Security Management maka pemenuhan SLA kepada unit organisasi bisnis lebih terjamin karena terdapatnya proteksi terhadap serangan / gangguan (ancaman) dari sisi security IT terhadap sistem infrastruktur TI. Perencanaan dan bentuk keamanan sistem TI tergantung kepada kebijakan keamanan yang diambil disesuaikan dengan arsitektur, konfigurasi sistem infrastruktur TI organisasi bersangkutan.
Terdapat defenisi-definisi dari keamanan sistem TI antara lain :
a. Tujuan / sasaran keamanan sistem TI :
·         Aspek Kerahasiaan (Confidentiality); memproteksi informasi-informasi yang sensitif.
·         Aspek Kesatuan (Integrity); penjaga keamanan atas akurasi dan kelengkapan dari informasi-informasi yang saling berelasi.
·         Aspek Ketersediaan (Availability); menjamin bahwa informasi dan layanan-layanan penting TI tetap tersedia dan berfungsi.
b. Proses / prosedur keamanan sistem TI :
·         Melakukan proses kuantitatif yaitu menganalisa risiko dan proses kualitatif yaitu melakukan penilaiannya (mengukur atau menentukan level) atas layanan-layanan TI  dan bisnis secara menyeluruh jika sistem infrastruktur TI berhasil dimasuki oleh penyusup/pengganggu terhadap keamanan TI.
·         Menetapkan kebijakan keamanan sistem TI dengan menjawab secara menyeluruh mengapa sistem keamanan TI dilakukan.
·         Menentukan standar-standar keamanan sistem TI dengan menganalisis secara menyeluruh apa yang akan dilakukan untuk mengimplementasinya.
·         Membuat prosedur-prosedur kamanan sistem TI dengan menganalisa dan mempelajari bagaimana sistem keamanan TI ini akan dijalankan.
Terdapat beberapa standar untuk kemanan sistem TI seperti antara lain BS 7799 (Code of practice for Information Security Management) dan ISO/IEC 17799 (dokumentasi yang dikembangkan di Inggris yang awalnya oleh 6 pemimpin organisasi-organisasi komersial, jangan dianggap sebagai buku resep untu keamanan sistem TI).

Gambar 17. Disiplin dalam BS7799 & ISO/IEC 17799
Secara umum aktifitas-aktifitas dalam Security Management adalah sbb:
·         Menilai (menganalisa) Risiko; merupakan persyaratan untuk menetapkan ukuran-ukuran apa saja yang harus ada dalam keamanan TI.
·         Mengelola risiko secara reaktif; dengan bereaksi cepat, hitung nilai ukurannya.
·         Rancang dan tetapkan  Kebijakan sistem keamanan TI; dengan dokumentasi yang mudah dibaca dan dipahami.
·         Kelola risiko secara proaktif; terus dilakukan modifikasi dan pembaharuan atas sistem keamanan TI yang ada untuk mencapai level yang optimum dengan biaya yang wajar dan risiko dampak yang dapat diterima.
·         Monitor sistem keamanan TI; dengan melakukan pengawasan pada porsi / frekuensi yang tepat untuk setiap periode waktu yang sesuai (reguler).
·         Buat laporan; laporan yang periodik maupun yang ad hoc adalah aspek penting untuk menjaga sistem keamanan TI tetap handal. Merupakan hal yang utama dalam paradigma organisasi untuk segenap unsur organisasi.
Adapun manfaat dengan diterapkannya sistem keamanan TI adalah :
·         Manajemen perusahaan menjadi lebih yakin untuk mendapat jaminan atas kelangsungan layanan dari sistem infrastruktur TI nya.
·         Lebih memberikan jaminan atas kelangsungan bisnis perusahaan.
·         Aktifitas penilaian (assessment) terhadap risiko menjadi “dipaksakan”.
·         Perhatian manajemen difokuskan pada ukuran-ukuran nilai.
·         Setiap orang dalam organisasi memandang secara berbeda mengenai informasi (data yang sama) tergantung dari kepentingan yang menjadi tanggungjawabnya.
Namun demikian terdapat kendala (atau paradigma yang salah) untuk mengimplementasi sistem keamanan TI dalam organisasi antara lain:
·         Menganggap sistem keamanan TI mahal dan tidak bermanfaat.
·         Menganggap ringan tentang ancaman penyusup/pengganggu sistem TI dengan paradigma “Hal itu tidak akan terjadi kepada saya!”
·         Berpikir (menyerah) bahwa “kita tidak dapat memproteksi semua ancaman”.
·         Manajemen senior (lebih tinggi) kurang perhatian atau kurang memahami mengenai sistem keamanan TI.
·         Perlu ‘endurance’ dan usaha yang lebih mengingat sistem keamanan TI menurun sejalannya waktu. Menjaga sistem keamanan TI pada level yang disepakati adalah sebuah usaha yang tidak akan pernah berhenti.
·         No security by design”, kebanyakan aplikasi-aplikasi ‘legacy’ tidak memiliki sistem keamanan TI yang tertanan didalamnya sehingga jangan mengandalkannya.
·         Membutuhkan pemikiran, rancangan dan implementasi yang menyeluruh dan tidak terkotak-kotak. Tidak ada gunanya mengamankan satu bagian dari sebuah sistem informasi atau infrastruktur TI jika di bagian lainnya tidak aman, artinya gagal di satu area kecil sekuriti adalah gagal secara keseluruhan.


C.3. Service Delivery
Service Delivery menyediakan panduan/petunjuk proses-proses yang harus dilakukan agar ekspektasi user/pengguna terpenuhi melalui layanan TI nya.

C.3.1. Capacity Management
Sasaran Capacity Management adalah untuk menentukan kapasitas yang pas (optimum), berdasarkan pertimbangan biaya yang wajar dan perimbangan logis lain dari sumberdaya TI, sehingga Service Level yang disepakati dengan unit organisasi bisnis dapat dicapai pada jangka waktu yang tepat dan saat yang tepat.
Penentuan perencanaan kapasitas atas kebutuhan layanan infrastruktur TI pada proses Capacity Management menggabungkan aspek atas kebutuhan kapasitas dari bisnis, layanan-layanan dan sumberdaya yang ada. ITSM menyarankan juga dibentuknya basisdata untuk mencatat parameter-parameter dan nilai ukuran yang berkenaan dengan proses Capacity Management serta sebagai data masukan (baseline).

Gambar 14. Proses Capacity Management
Cara terbaik dalam penentuan kapasitas sistem adalah dengan melakukan sizing dan modelling,
·         Application Sizing; Menentukan kapasitas hardware yang dibutuhkan untuk mendukung aplikasi-aplikasi (atau tambahan/penyesuaian modul-modul aplikasi) baru sesuai SLA yang disepakati.
·         Modelling; Dapat dilakukan dari salah satu atau gabungan proses analisa kecenderungan (trend analyzing), model simulasi (model simulation) dan model-model yang telah dijadikan baseline.

C.3.2. Availability Management
Sasaran dari Availabity Management adalah untuk memprediksi, merencanakan dan mengelola availability dari layanan-layanan yang disediakan dengan menjamin bahwa :
·         Semua layanan-layanan memenuhi yang dipersyaratkan/disepakati, handal dan dipelihara dengan benar termasuk CI’s nya.
·         Dalam hal CI’s yang dipakai untuk mendukung layanan TI ke unit organisasi bisnis tidak didukung oleh organisasi internal TI (unit organisasi TI), selanjutnya harus ada dasar kontrak yang benar (UC’s) kepada provider/suplier eksternal yang mendukung CI’s tersebut.
·         Request for Change’s (RFC) harus secara konsisten dilaksanakan untuk mencegah kesulitan pelacakan jika terjadi hilangnya layanan-layanan TI.
Secara garis besar tanggungjawab dari Availability Management adalah :
·         Mengoptimalkan availability dengan melakukan kegiatan-kegiatan monitoring, pengelolaan / pengaturan dan pelaporan.
·         Menentukan persyaratan-persyaratan atau ketentuan-kententuan availability sesuai kebutuhan bisnis.
·         Memprediksi, merencanakan dan merancang level-level (ukuran-ukuran) yang dapat dicapai atau diperkirakan (logis) dari availability dan security.
·         Mengembangkan rencana (roadmap) availability.
·         Mengumpulkan, menganalisa dan mengelola data-data berkaitan dengan availability.
·         Memonitor level-level availability dalam operasionalnya untuk menjamin SLA’s dan OLA’s tercapai.
·         Secara berkesinambungan dan bertahap meningkatkan level-level (ukuran-ukuran) availability.
Beberapa terminologi dalam proses Availability Management adalah :
·         Availability = MBTF (Mean Time Between Failures = Up Time); jumlah waktu dimana sistem (CI’s) dalam kondisi berfungsi normal.
·         Maintainability = MTTR (Mean Time to Repair = Down Time); jumlah waktu dimana sistem (CI’s) dalam kondisi tidak berfungsi normal.
·         Serviceability = MTTR (Mean Time to Repair = Down Time); jumlah waktu dimana sistem (CI’s) dalam kondisi sedang diperbaiki, dan masuk dalam kondisi Maintainability.
·         Reliability = MTBSI (Mean Time Between System Incidents); frekuensi kejadian (incident) dimana sistem (CI’s) dalam kondisi tidak berfungsi normal (Down Time).
·         Resilience (Redudancy); jumlah waktu dimana sistem (CI’s) memberikan layanan normal namun dalam kondisi berfungsi menggunakan sistem (CI’s) cadangan (backup). Hal ini adalah untuk sistem (CI’s) yang diimplementasi secara redudancy (hot swap / automatic transferswitch failure).
·         Security = Confidentiality, Integrity & Availability; kondisi sistem (CI’s) masih terlindungi oleh perisai sistem keamanan sehingga kerahasiaan, integritas dan ketersediaan data/informasi terjaga.
Siklus hidup dari ketidak tersediaan layanan dari sistem (CI’s) dapat digambarkan sebagai berikut :
Gambar 15. Siklus Hidup Availability
Layanan-layanan TI tidak tersedia kepada user/customer (unit organisasi bisnsi) jika fungsi-fungsi yang dibutuhkan selama waktu layanan (yang disepakati) pada lokasi (sistem atau CI’s) itu tidak dapat berfungsi atau digunakan. Hal ini belum tentu berarti bahwa SLA tidak terpenuhi, mengingat jika didalam perhitungan SLA masih ada toleransi down time yang disepakati. Untuk menghitung Availability digunakan formula berikut :
            Availability = (AST-DT)/AST x 100%
            Dimana :               AST = Agreed Service Time
                                                DT = Actual Down Time during agreed service time
Sebagai ilustrasi penerapan rumus availability kepada sistem (CI’s) dengan konfigurasi yang serial dan paralel (redundant) ini dapat digambarkan sebagai berikut :

Gambar 16. Ilustrasi Penggunaan Rumus Availabity

C.3.3. IT Service Continuity Management (ITSCM)
Tujuan atau sasaran proses IT Service Continuity Management adalah sbb:
·         Mengurangi waktu berhenti layanan TI baik dari setiap CI’s maupun dari sistem infrastruktur TI secara utuh.
·         Menyiapkan pemulihan (recovery) dan menjalankannya dengan secepat mungkin melalui cara yang efisien dan efektif ketika CI’s (sistem infrastruktur TI) yang mengalami gangguan.
·         Mengurangi kerugian finansial dari kesempatan mendapatkan pendapatan bisnis akibat kegagalan layanan-layanan TI untuk waktu yang cukup lama.
·         Menjamin kelangsungan hidup bisnis tetap tersedia untuk waktu yang diinginkan.

Gambar 18. Tujuan dari IT Service Continuity Management
Proses-proses yang dilakukan pada ITSCM dapat digambarkan dibawah ini yang dimulai dari inisiasi, analisa kebutuhan dan strategi serta implementasinya.

Gambar 19. Proses-proses di ITSCM (management)
Sedangkan proses-proses ITSCM dalam lingkup operasional adalah dengan menjalankan materi-materi yang telah dihasilkan dari proses-proses ITSCM pada lingkup management di atas melalui pendidikan dan pembangunan kesadaran, review dan audit berkala, testing hasil impelementasi, melaksanakan change management, dan pelatihan kepada personil yang terlibat. Kesemua proses-proses ini dapat memberikan jaminan ITSCM dapat dijalankan secara benar.
Gambar 20. Proses-proses di ITSCM (operasional)
Inti dari kegiatan ITSCM adalah melaksanakan identifikasi, penelitian dan analisa risiko secara benar dan menyeluruh dalam kaitannya dengan dampak kepada bisnis untuk setiap elemen-elemen yang mempengaruhi bisnis. CCTA membagi kegiatan (metodologi) ini menjadi Analisa Risiko dan Manajemen Risiko (CRAMM = CCTA’s Risk Analysis Management Methodology).
a.    Analisa Risiko
·         Identifikasi dan menganalisa nilai (value) dari aset-aset bisnis.
·         Identifikasi dan menganalisa ancaman-ancaman terhadap kelangsungan bisnis.
·         Identifikasi dan menganalisa kelemahan-kelemahan dari setiap elemen-elemen bisnis.
b.    Manajemen Risiko
·         Menghitung (menaksir) seberapa ukuran-ukuran dari setiap komponen-komponen bisnis yang ada secara berkala dan konsisten.
·         Kaji dan teliti potensi-potensi bencana yang mungkin menimpa.
·         Kelola dan siasati langkah-langkah pencegahan dan pemulihannya jika potensi-potensi bencana tersebut benar-benar menimpa kepada bisnis.

Gambar 21. CCTA’s Risk Analyasis Management Methodology
ITSM menetapkan pilihan strategi pemulihan (recovery) dari bencana (disaster) menjadi 3(tiga) yaitu Cold Standby (pemulihan secara bertahap (gradual)), Warm Standby (pemulihan dalam waktu yang cukup cepat (intermediate recovery)) dan HOT Standby (pemulihan sangat segera).
ITSM menyarankan dibentuknya struktur organisasi dan Tim khusus untuk pemulihan dari bencana (DR = Disaster Recovery). Personil-personil yang masuk kedalam Tim DR dalam keadaan normal memiliki peranan dan tanggungjawab seperti keadaan operasional normal mengikuti ketentuan struktur organisasi normal, namun ketika terjadi bencana atau situasi krisis maka anggota Tim ini berubah peranan dan tanggungjawabnya serta mengikuti ketentuan struktur organisasi situasi krisis.
Keberhasilan ITSCM ini terletak pada testing dan evaluasi yang mendalam dari rencana ITSCM, adapun hal-hal yang perlu dilakukan dalam testing dan evaluasi ini adalah :
·         Testing dan evaluasi dilakukan setiap 6 s/d 12 bulan dan setiap setelah bencana (disaster).
·         Test (uji) rencana ITSCM dibawah lingkungan dan kondisi sebenarnya.
·         Pindahkan / proteksi (backup) segala layanan-layanan yang sudah berjalan lebih dahulu agar pemulihan konfigurasi (setting) & data dilakukan secara cepat jika selama testing dan evaluasi terjadi perubahan-perubahan.
·         Evaluasi dan lakukan perubahan jika perlu dari rencana ITSCM agar menjadi lebih baik (menutup kekurangan-kekurangan).
·         Semua perubahan harus melalui CAB melalui proses Change Management.

Kegiatan Financial Menagement Teknologi Informasi untuk memberikan pelayanan berawal dari penentuan kebutuhan-kebutuhan bisnis atas TI dalam memenuhi pelayanannya kepada customer. Dari sini kemudian ditentukan perencanaan operasional TI nya termasuk penentuan anggarannya (investasi/pembelian & biaya operasional). Setelah tahap ini perlu dilakukan analisa biaya TI (IT accounting) lebih detail mengikuti kaidah akuntansi TI, dalam tahap ini juga dimungkinkan perubahan kebijakan. Terkahir adalah pembenan-pembebanan biaya dalam bentuk kuantitatif keuangan kepada unit organisasi bisnis.
Pengertian akuntansi TI dalam Financial Management adalah sebagai berikut :
·         Merupakan keputusan-keputusan di bidang TI yang berbasis pada penilaian efektifitas biaya. Merupkan sebuah cara mengukur pelayanan TI dari sudut pandang ekonomi.
·         Menyediakan informasi kepada Manejemen untuk menimbang pengeluaran dan investasi TI untuk keperluan bisnis.
·         Perencanaan dan pendanaan menjadi lebih yakin dan terpadu, sehingga pemangku kepentingan dapat melakukan pengukuran.
·         Memperlihatkan kondisi dibawah atau diatas dari pemakaian (pemberian layanan) oleh TI dalam bentuk keuangan kepada bisnis dan atau customer.
Unit organisasi TI dalam memberikan layanan TI kepada unit organisasi bisnis dapat meminta pembebanan biayanya. Customer membayar penuh biaya dari layanan TI yang disediakan dengan harga yang wajar; “apa yang digunakan adalah apa yang dibayar”. Keuntungan dilakukannya pembebanan biaya adalah:
·         Menjamin bahwa customer sadar akan biaya yang dikeluarkan untuk layanan-layanan TI dan sedikit banyak akan mempengaruhi tingkah laku customer dengan memberikan pendidikan atas seberapa besar pengeluaran untuk layanan TI nya.
·         Membuat evaluasi formal dari layanan-layanan TI dan merencanakan investasinya, didasarkan pada pemulihan biaya dan manfaat bisnisnya.
Adapun pilihan-pilihan pembebanan biaya dan model harga adalah sebagai berikut :
a.    Pembebanan biaya (charging):
·         Tidak ada pembebanan biaya à no charging.
·         Pembebanan biaya tidak tetap / pembebanan biaya tidak seragam.
·         Pembebanan biaya aktual à actual/real charging.
b.    Model harga (pricing):
·         Recover of costs
·         Cost price plus.
·         Going rate.
·         Market prices.
·         Fixed price.

C.3.5. Service Level Management (SLM)
Prinsip dasar dalam Service Level Management adalah menimbang (keseimbangan) antara tuntutan kebutuhan/permintaan atas layanan-layanan TI dari unit organisasi bisnis dan kemampuan pemberian layanan TI oleh unit organisasi TI.
Sasaran dari Service Level Management adalah sebagai berikut :
·         Sebagai jembatan hubungan antara customer dan pemberi layanan TI (IT Customer Relationship Management).
·         Sebagai media kepada customer untuk memahami kebutuhan-kebutuhan dari layanan-layanan TI nya.
·         Memberikan fleksibilitas dan responsif yang lebih baik dalam menentukan (sebagai referensi) untuk layanan-layanan TI nya.
·         Mengukur keseimbangan permintaan customer terhadap ketentuan layanan-layanan dalam hal biaya.
·         Memudahkan mengukur tingkat-tingkat layanan (SMART = Specific, Measurable, Achievable, Realistic & Time Bound).
·         Sebagai acuan dalam meningkatkan kualitas (acuan review terus menerus dan bertahap).
Dokumentasi dalam Service Management mencakup hal-hal sebagai berikut :
·         Seluruhnya dikukur dari perspektif customer.
·         Data seperti waktu reaksi, waktu eskalasi dan waktu ketersediaan layanan TI, seharusnya dapat terukur dan nilainya wajar.
·         Laporan-laporan pengukuran/pencapaian harus dibuat dengan benar baik secara periodik maupun ketika diperlukan.
·         Laporan-laporan berisi pengukuran nilai-nilai ukuran terutama tingkat ketersediaan layanan TI posisi “saat ini” dan histori/trend perkembangannya.
Adapun proses-proses yang dilakukan didalam SLM adalah :
a.    Pembangunan fungsi-fungsi yang ditentukan sesuai dengan layanan yang akan diberikan. Proses ini dilakukan melalui perencanaan dan implementasi setiap CI’s (komponen TI) sehingga berfungsi memberikan layanan-layanan TI yang diinginkan. Dari hal ini dapat ditentukan tingkat kualitas, waktu ketersediaan, relasi fungsi antar CI’s dari layanan TI nya (dari CI’s / komponen TI).
b.    Implementasi SLM. Dari fungsi-fungsi layanan yang ada, dibentuk katalog layanannya, selanjutnya dapat dibentuk draft OLA/SLA/UC-nya. Draft ini dinegosiasikan kepada para pihak yang berkepentingan (internal unit organisasi TI, unit organisasi bisnis, suplier TI). Setelah dilakukan tahap review secara bersama-sama diantara pihak berkepentingan maka draft OLA/SLA/UC dapat menjadi dokumen kesepakatan.
c.    Selama berjalannya kesepakatan OLA/SLA/UC, maka harus dilakukan pengawasan (monitoring), pelaporan dan review yang terus menerus dan berkala.
d.    Berdasarkan hasil proses pada point c diatas, maka harus dilakukan review & audit nya serta review & audit proses-proses SLM nya untuk peningkatan kualitas dari layanan-layanan TI nya.
Secara umum jenis-jenis dokumen kontrak pada SLM (OLA. SLA, UC) dapat digambarkan sebagai berikut :

Gambar 22. Jenis-jenis kontrak dalam Service Level Management

Dalam usaha meningkatkan kualitas layanan TI nya, ITSM memberikan panduan langkah-langkahnya perencanaannya (Service Quality Plan) sebagai berikut :
·         Penjelasan (awareness) dan komitmen kepada internal services atas peran dan tanggungjawabnya mengenai waktu penyerahan/ketersediaan layanannnya kepada pengguna/pelanggan agar service level yang disepakati dapat dipenuhi.
·         Harus difokuskan pada staff-staff TI dalam hal kinerja dan waktu penyerahan layanan TI nya.
·         Penjelasan (briefing) secara rutin dan rinci dari menajemen organisasi TI mengenai apa yang harus dilakukan untuk memberikan kualitas layanan yang diinginkan pengguna/pelanggan.
·         Penjelasan mengenai aksi yang akan dilakukan ketika tidak dapat memberikan tingkat kualitas layanan yang disepakati pada setiap tingkat (level) pelayanan.
ITSM menyarankan dibentuknya program-program peningkatan layanan (SIP = Service Improvement Program) sehingga tingkat layanan yang diinginkan dapat dicapai :
·         Sasaran : mengendalikan peningkatan dari layanan TI yang disediakan.
·         Dapat digunakan kapan saja ketika diperlukan untuk hal-hal antara lain :
o   Penyimpangan terjadi atas tingkat (level) yang disepakati.
o   Memilih hal-hal yang sifatnya strategis.
o   Untuk peningkatan yang berkelanjutan (continuous improvement).
·         Dapat dibentuk lebih dari satu SIP yang dijalankan secara bersamaan.
ITSM mengelompokkna elemen-elemen dari Service Level Agreement (SLA) sebagai berikut :

Gambar 23. Pengelompokkan elemen-elemen SLA

ITSM adalah bukan satu-satu referensi yang dapat dijadikan acuan dalam mengembangkan tata kelola yang baik terhadap Teknologi Informasi. Referensi yang lain adalah seperti ISO 20000 atau BS 15000 atau Six Sigma, dan lain-lain. Namun kelebihan dari ITSM ini adalah referensi ini dikhususkan untuk Teknologi Informasi.

DAFTAR PUSTAKA
·         The Adoption of ITIL in Large Enterprise, TechRepublic, 2005.
·         An Introductory Overview of ITIL, ITSMF, eBook, 2004
·         ITSM Forum International : www.itsmfi.org .


3 komentar:

  1. mantep gan.. cukup detil bantu banget buat ane yang ngk bisa bahasa inggris...

    BalasHapus
  2. Punya referensi buku yg bhsa indo ga?

    BalasHapus
  3. Kalo menghitung avalability SLA itu referensiny yang mana yaa kak?
    Availability= AST-DOWNTIME/AST x 100%

    BalasHapus