Home

A Journey into IT Management, Part 2: Network, IT Risk, dan Pandemi

Leave a comment

Part 1 disini

OK, now I want to ask you guys…

…kalau ada 3 keyword… Network…IT Risk…dan Pandemi

Apa yang ada dibenak para kisanak sekalian? ini apa nyambungnya

(yak, sama…setidaknya untuk low level employee kek kita2)

But here’s why we were wrong, kita akan nyambungin ini semua berdasarkan contoh use case di IT Training Center that I work at (and all-in-one tools for risk assessment, link ada dibawah)

——————

In the last post, saya sudah curhat Tersesat 1.0 … Tersesat 2.0 … Tersesat 3.0

Sekarang kita berada pada point Tersesat… Advanced level version

First, kita bahas Pandemi

Gila jungkir balik mas (turun) beroh

Every business, every person, every nation… semua yang sudah settle dengan bisnis proses-nya masing2, begitu Covid muncul… *BAM* …lalu di tangkap… (*maaf… anak saya masi suka nyanyi cicak di dinding)

Intinya situasi ini bikin RUSAK…merusak tatanan dunia yang sudah ada

Dengan adanya pandemi ini, semua entitas harus puter otak, how to survive… at least sampe 2021 akhir (gue udah pernah ngomong sama temen awal 2020 lalu, ini bisa 2 tahun, and im afraid its true… and not proud of that)

Nah…disini benang merahnya tentang judul diatas

At the moment the pandemic spread, apa yang dipikirkan oleh para business owner??

Yup…2 things, preserving (their) lives… and also saving their ASSETS

Mau ga mau memaksa every person on earth changing how their business works (udah kek anak jaksel belum)

Yaitu customer tetap ingin training (surprisingly a positive thing in this situation, gue kira malah ga ada samsek), but… can you do it without interacting directly?

Kalau dalam CObIT, customer needs harus dimapping ke enterprise needs…so, kebutuhan klien tentang training virtual semakin marak disaat permintaan training offline/tatap muka semakin berkurang…klo ga bisa dibilang ZERO ya (ya kalau ngomongin rejeki mah ya… satu pintu tertutup, yang lain pasti kebuka lah ya)

So, how do we do it? what component should we have and provide?

Salah satu core value dari IT Governance adalah providing value…and according to CObIT this can be achieved by 3 things: Benefit Realization, Resource Optimization, and Risk Optimization

Nah, point of view akan saya fokuskan ke optimisasi (control) resiko, secara nanti kita sambungin dengan network dan nyambung pula ke video tutorial yg ada di channel yutub saya (link dibawah), karena klo ngomongin benefit realization ya udalah ya, ada permintaan training, selama bisa ya hajar aja, asal halal ya embat, dari segi resource di kantor juga mumpuni (dilihat dari sisi infrastruktur, trainer, booklet, and so on) plus ga terlalu gagap dengan training model itu (kita pernah ngadain training data center secara virtual sudah sejak lama, lebih tepatnya…trainernya ga bisa ke Indonesia)

OK… now we have a goal, business goal… in this pandemic situation

Our use case = VIRTUAL CLASSROOM TRAINING

—————

Second, how to do risk (control) optimization correctly

Pertama, identifikasi asset.

Aset mana saja yang mendukung bisnis proses (in this case, online/virtual training), lalu dimapping “dependency” alias ketergantungannya, asset mana yang tergantung ke asset mana, barulah ketemu aset2 kritikal dalam pelaksanaan virtual classroom

Biasanya informasi2 tentang dependency ini di taro di dokumen yang namanya BIA (business impact analysis), dokumen ini juga sangat berguna untuk orang2 yang mengurusi BCP (business continuity planning), itu tu..yang (salah satunya) orang2 yang ngurusin DRC (Disaster Recovery Center), karena didalamnya ada informasi2 penting terkait RTO (recovery time objectives, how fast we can recover) dan RPO (recovery point objectives, how long we can survive)

Link gambar diatas ada disini

Nah, according to NIST SP 800-30 tentang guideline untuk asesmen resiko, aset2 tersebut harus kita framing (RISK FRAMING a.k.a RISK CONTEXT), kenapa? Agar kita bisa melihat vector2 atau arah darimana resiko berasal

Dalam kasus virtual training, asset kita apa saja? PertamaInfrastruktur (Jaringan/Network), KeduaInstruktur, Ketigabahan ajar (softcopy maupun lab material)

Untuk identifikasi aset dari segi infrastruktur, ada 2 tipe training, yaitu manajemen dan teknikal

Untuk yg pertama… arah masalah yang akan muncul atau yang kita biasa bilang threat (defisini threat: event yang punya potensi merugikan) hanya dimasalah koneksi ke virtual room, dari koneksi trainer maupun koneksi peserta.

Untuk koneksi trainer dengan kebijakan WFH yg bisa ngajar dari rumah dalam keadaan koneksi jelek bisa diatasi dengan masuk ke kantor, disana disediakan 1:1 bandwidth allocation dari ISP, sekarang tinggal leftover alias residual risk-nya…yaitu koneksi peserta (biasanya di mitigasi/reduksi dengan cara “diwanti-wanti” koneksi harus bagus atau memakai koneksi dari kantor masing2)

Kan bisa direkam? Bukannya ini jadi salah satu solusi? justru ini Threat selanjutnya

Kita ga ingin rekaman itu bisa di download/replayable untuk peserta (kalau tidak ada ijin dari manajemen), you know lah… jadi menurunkan value trainingnya, bukankah sudah banyak video2 tutorial dari Pluralsight, Lynda, dll?!? Versi “torrent”nya juga banyak beredar di internet… ini salah satu threat. So, giving training record is not so recommended risk response selection, apalagi kalau peserta konek dari kantor, telinga memang dengerin instruktur, tapi mata dan tangan ngerjain kerjaan kantor… apalagi dengan video off dan mic off, entah dimana itu orang2

Lalu untuk yang teknikal… kantor menyulap kelas/ruangan training yg biasa diisi manusia menjadi ruangan yang diisi “hantu”, alias virtual attendee

Contoh untuk kelas Cisco, EC-Council (klo somehow ga bisa iLab), etc. yang membutuhkan bahan ajar seperti lab/praktek… kita menyediakan akses ke ruangan fisik di kantor kita (via teamviewer/anydesk) agar peserta dengan segala keterbatasannya bisa praktek

Challenge nya adalah… belum tentu peserta mengikuti instruksi kita, kita bisa monitoring MONITOR mereka di kelas, adaaa yg gerak…adaaaa yg meneng ae (diem aja), sampai sekarang setiap ada kelas training, kita bikinkan WAG agar bisa koordinasi secara realtime

Disini kantor punya ide bikin satu konsep training “X” (masih digodok oleh R&D), supaya peserta bisa full focus di online training, ibarat kata… “kaki, tangan, dan matanya” ga bisa lepas dari layer yg disuguhkan oleh instruktur, we’ll see what happens in the future about this “X”…mudah2an lancar dan sukses

NAHHH lalu… kita sudah identifikasi asset dan melihat threat2 terhadap asset, ketemulah perkiraan (guessing method, nanti kita bahas dibawah) seberapa sering (chance/likehood) threat ini muncul, lalu impact terhadap bisnis bagaimana, termasuk vulnerability2 kalau kita melakukan apa yang sudah kita rencanakan

Tinggal manajemen dikantor lah yang decide (merekalah RISK OWNER, yg nanggung resiko)…”how much they willing to tolerate the risk” a.k.a risk acceptance, itu tandanya harus ada asesmen

————

Third, Asesmen Resiko

What Risk? Resiko kalau ngadain training secara virtual pastinya

Did it has a risk? How we find it? Makanya asesmen.

How to assess? Ok, look…

Langkah pertama… kita “mapping” Risk Identification-nya dengan cara collecting Audit Report, Vuln. Assessment, Interview (metode ini yang dipilih), Workshop, Seminar, and so on

Kenapa Interview? The easiest one, tapi akurasi dalam identifikasi resiko terbilang rendah (bisa jadi karena bias, underestimate risk yang malah anggep enteng pandemi, atau malah overexaggerate alias parno berlebih)

Any tips on interview? 1. Do research about the problem first (virtual training itu karakteristiknya seperti apa, komponen2 pendukungnya apa), 2. Terjadwal, 3. Pertanyaan2 sudah disiapkan 4. Semua entitas/orang2 yang terkait tentang virtual training ditanyakan (IT staff, sales, marketing, instruktur, dll)

Langkah kedua… choose your assessment analysis method

Ada 2 garis besar dalam risk assessment, Qualitative Analysis vs Quantitative Analysis

Perbedaan:

  • Quantitative = using tools, time consuming
  • Qualitative = “guessing” method, faster

Contoh tools yang sering digunakan dengan Quantitative adalah FMEA (failure modes and effect analysis)

Contoh lain quantitative risk analysis adalah dengan Expected Monetary Value

Lalu ada yang namanya Decision Tree Analysis (googling up yourself) dan…*aha* Monte Carlo Analysis

See those pic above? Its monte carlo quantitative risk analysis for COVID-19 in Australia (keknya grafik simulasi penyebaran klo lockdown vs ga lockdown di sosmed juga salah satunya pake monte carlo analisis deh *CMIIW*)

Kalau Qualitative bagaimana? Contohnya adalah Bayesian Analysis (penjelasan tentang ini ada di link video dibawah) dan Brainstorming, kita pake ini…using Delphi Method

Delphi Method? OK, begini… delphi method itu punya proses namanya E-T-E a.k.a Estimate-Talk-Estimate a.k.a Round 1-Discussion-Round 2

Contoh kita pake case yang ada, ketika pandemi muncul, revenue turun drastis… kenapa? How? What happen aya naon?

Ronde pertama (Round 1)… semua stakeholder internal dikumpulin…RAPAT, Isinya pembicaraan tentang kenapa-bagaimana-dan-solusi keluar dari permasalahan yang ada. But heres what makes Delphi method unique, kita semua dikasi selembar kertas, isinya questionaries tentang keadaan tersebut, trus dikumpulkan secara anonymous

Discussion… setelah paper2 (lebih tepatnya ms word sih) itu dikumpulkan, lalu dianalisalah pendapat2 para stakeholder itu dan dipaparkan pada rapat (executive report summary), yang ternyata (pada kasus kita) revenue menurun yang disalahin ya gara2 Covid ini, nahh disini…kita semua para stakeholder di challenge, apakah kesimpulan ini benar, biasanya ada aja yg kritis dan menyangkal (efek dari anonymous collecting), ini saatnya ronde ke 2

Ronde kedua (Round 2)…sama, questionaries…jawaban yang diberikan BIASANYA beda dari yang pertama (adanya changing point of view setelah paparan sebelumnya)…

Summary… kesimpulannya alias long story shortnya…ternyata bukan karena covid, sebelum covid pun emang sudah turun karena beberapa ada salah strategi penjualan (official learning partner point of view, custom IT training material yang tidak sesuai, dll), Covid ini cuma bikin situasi yang ada makin parah aja

Get it?!?

Di NIST SP 800-30 ada sub bab dimana kita bisa combine “best of both worlds” jadi SEMI-QUALITATIVE (long story short…ini tuh kek bikin range/skala, contoh 1-40=low, 41-80=medium, 80-100=critical, jadi nilai quantitative nya ada, “kira-kira” masuk ke range mana ala qualitative juga ada)

Karena kita sudah tau tentang mengidentifikasi resiko (risk identification) serta kita sudah memilih what best for risk assessment for our case, sekarang output risk assessment ini mau diapain?

—————-

Fourth, Setting Risk Criteria and Risk Responses

Difase ini adalah fasenya manajemen dan tata Kelola, karena karakteristik penekanan pertanggungjawaban resiko ada pada ownernya, responsibilities of senior management

Report dari risk assessment ini akan ditaro dalam semacam “risk databases” yang disebut dengan Risk Register

Dari database tersebut, risk management akan membuatkan Risk Assessment Report-RAR (pake powerpoint, excel, atau ms word aja, ilmu infografis lumayan membantu agar senior management get the big picture, untuk dianalisa, mana resiko2 yang akan diprioritaskan untuk di control)

Analisa2 tersebut membutuhkan kriteria, yaitu Risk Criteria, mana saja yang masuk ke low risk, medium risk, atau high risk

Bagaimana cara membuat kriteria resiko? Cara yang paling gampang (yg lebih akurat dari ini sih banyak) adalah Likehood x Impact = Prioritization Criteria, semakin tinggi nilainya, semakin di prioritaskan untuk di control

Dalam kasus Virtual Classroom, kita punya 2 resiko utama

  • Internet Putus
  • Dokumen/Video/Materi training Bocor

Let’s calculate roughly… internet putus (atau slow) itu chance (likehood)nya dari skala 1-5 (rendah sampai tinggi) adalah 3 (artinya bisa dan agak sering terjadi), tapi dari segi impact nilainya 2 (bisa banyak alternatif koneksi), kalau di kalkulasi berarti 3 x 2 = 6

Sedang Materi bocor, chance-nya mungkin 2, tetapi impactnya besar dengan nilai 4 (competitor knows how to do it, materi bisa di atm-amati tiru modifikasi, weakness dari segi materi dan instruktur keliatan), kalau di kalkulasi berarti 2 x 4 = 8

Artinya, berdasar risk criteria (level) yang menunjukkan bahwa materi (8) lebih di prioritaskan daripada internet (6), kantor memutuskan kita harus membuat semacam mekanisme agar materi otentik dan tidak gampang bocor

contoh risk level (criteria)

Guideline untuk kriterianya ada di NIST SP 800-30 atau salah satu referensi saya yang lain adalah ssatoolkit.com

KORELASI DENGAN JARINGAN/NETWORKNYA DIMANA? Nah, risk response yang dipilih oleh kantor adalah risk reduction (selecting risk response link vidionya ada dibawah), alias materi2 tersebut disimpan dalam repository LMS (learning management system), some of you already knows moodle (kita sudah pake secara aktif beberapa tahun yang lalu disaat beberapa kampus BARU INTENS makenya sekarang gara2 pandemi…yang mereka banyak curhat, begitu mau dipake, obsolete alias out-of-date gara2 ga pernah diupdate a.k.a dipake….ya kan!??, ya iya lah… dari kacamata mereka, ‘value’ moodle itu belum tinggi waktu itu, makanya dianak-tirikan)

Peran infrastruktur (contoh Network) disini adalah memastikan koneksi ke LMS harus steady dan reliably plus InfoSec view harus diperhatikan (password policy, how to connect, etc.), karena ini jadi CORE BUSINESS FUNCTION kita.

Mulai dari perencanaan redudancy jaringan, genset, failover server LMS, dll diperhatikan semua…karena itu semua asset penting, lebih tepatnya…itu semua adalah aset2 kritikal yang LMS “depends its life” on those aset

Peserta (akses forum, materi, dan vidio), trainer (akses materi, presentasi/pdf/ppt, lab instructions), sales (dokumen report progress peserta before/after training seperti pre-test, post test, exam, etc), dan yang lainnya kan resolve-nya around LMS

Kenapa yang dipilih risk reduction? Kenapa ga yang lain? Karena ga bener2 menghilangkan resiko… ya namanya orang, mau ambil materi ada aja konsep akal bulusnya, file format “.PDC” nya ec-council aja yang secure bisa dibajak, banyak celah menuju roma ya kan?!?!

Sebenernya ada dokumen NIST SP 800-39 tentang manajemen resiko pada information security, isi dokumennya kalau dijabarkan secara singkat adalah… pembagian domain resiko (Organizational Risk, Tactical Risk, Operational Risk), Role2 yang ada dalam menangani resiko, Trust Model, dll… tapi kita ga bahas kesini (kebanyakan)

—–

Nah, terakhir… adalah monitoring, reporting, evaluating, and reviewing risk

Yang namanya jualan, termasuk virtual classroom, pasti butuh evaluasi performa

artinya ada KPI (Key Performance Indicator), yaitu indikator2 tentang seberapa efektif suatu organisasi achieve their goals

Nah karena goal tersebut pasti ada ancaman gagalnya, artinya kita punya KRI (Key Risk Indicator), ya itu indikator apa saja yang bikin organisasi gagal atau terhambat dalam achieving their goals

KRI Form

diatas adalah contoh KRI

kita masih “godok” mau pake measurement kek apa tentang virtual classroom ini

Yah… yang namanya evaluasi dan review, berarti SUDAH DILAKSANAKAN, berhubung data yg bisa di collect baru sedikit, kita ga tau seberapa besar efektifitas dari risk response yg kita pilih

Jadi…. Progressnya akan saya tulis in the next article, ketika sudah memenuhi threshold untuk dianalisa

Tapi so far sih berdasarkan pengamatan pribadi (observation)… adanya peningkatan permintaan dan kesanggupan kita (request fulfilment) dalam melayani permintaan tersebut menunjukkan Virtual Classroom ini headed to the right direction (ini bias? iya, ya namanya juga pengamatan personal)

——

Link

Video tentang Risk Management – Intro

Video tentang Risk Management – Risk Identification

Video tentang Risk Management – Risk Assessment Method

Video tentang Risk Management – Risk Response

Risk Criteria Template

Tool all-in-one from simplerisk.com

ITIL Service Design Overview

3 Comments

Step selanjutnya dari Service Strategy, yaitu Service Design

ok, budget udah ada nih buat bikin menu baru NasGor, apa dulu nih step2 yang harus dilakukan

BoD sudah approve untuk bikin DaCen, next planning-nya apa nih

Inti dari Service Design adalah untuk merealisasikan strategy yang sudah dibuat, gimana caranya service yang akan dibuat ini bisa beradaptasi kedalam sistem yang ada, dan cost effective

Jadi kita sebagai tim IT bisa menyiapkan service yang “layak di konsumsi” untuk customer dari segala sisi

Nah, tahapan2 atau proses yang masuk dalam fase Service Design adalah:

  • Supplier Management
  • Service Catalog Management
  • Service Level Management
  • Capacity Management
  • Availability Management
  • IT Service Continuity Management
  • InfoSec Management
  • Design Coordination
  • Risk Management
  • Compliance Management
  • Architecture Management

Banyak amat ya…wkwkw

Ya, memang klo ga begitu…pas service kita masuk ke operational state, pasti acak2an…ga jelas service nya kek apa, siapa yang dapet ini service, berapa banyak/lama ini service bisa didapat, dll

Yuk kita bahas satu2…

————————————–

Service Catalog Management

masa café ga ada daftar menu-nya…bikin lah

bikin daftar IT services yang bisa customer pake untuk DaCen

Inti dari Service Catalog Management adalah…BIKIN MENU

Pentingnya membuat “menu” alias IT Catalog adalah…Menghindari IT Superman

Alias lu semua yang ngerjain, padahal bukan kerjaan dan tanggung jawab lu

bos, benerin printer gue dong…benerin HaPe gue dong“…lu bisa jawab “tugas gue cuma ping, install software, sama setting router

Isi dalam list (menu) yang akan dipublish ke customer tersebut adalah services2 yang sedang “live” alias sedang berjalan

Yang pernah berjalan (retired services) tidak akan ditampilkan di menu tapi hanya ada di Service Portfolio (supaya bisa jadi track record alias sejarah yang barangkali mau kita ulang lagi)

Dalam IT Services, Service Catalog ini hanya akan disediakan kepada customer yang ter-authorisasi (klo customer café cuma liat2 ruangan doang jgn dikasi menu dulu, begitu mereka duduk baru kasih menu)

Karakteristik dari Catalog yang akan kita buat ada 4:

  • Deliverables…memastikan ketika customer request akan langsung bisa di deliver
  • Prices…pastikan harga-nya tercantum…WALAUPUN tercantumnya FREE
  • Contacts…untuk request service ini harus ngomong ke siapa
  • HOW to order and request…cara order service ini gimana (handling request ini akan dibahas detil di Service Operation phase)

Ada 2 tipe katalog

  • Business Service Catalog (BSC): catalog ke customer
    • Cost of services: untuk gunain service ini harganya brp
    • SLA Information: standard acuan ini service bagus apa engga apa
    • User Group: user yang make services ini masuk group apa (user, admin, operator,dll)
    • KPI: reporting and monitoring SLA
  • Technical Service Catalog (TSC): ke orang teknis
    • Link and References to other services which essential for delivery of this service
    • Configuration items (hardware, software, etc.)
    • Startup and Shutdown procedures
    • Recovery and Fallback Information
    • Key Contact Person

BSC itu kek semacam “what”nya, TSC itu kek “how”nya…

BSC buat customer, TSC itu buat orang2 teknis yang akan deliver servis-nya ke customer

————————————————

Supplier Management

bikin NasGor artinya kita perlu list supplier beras siapa aja, siapa main supplier dan siapa backupnya

mau bangun DaCen berarti kita harus kontak SI/Vendor untuk bantuin implementasi alat2nya

Supplier: 3rd party that help Us to deliver services (kek Vendor dan SI)

Inti dari supplier management adalah memastikan setiap kontrak dengan 3rd party sesuai dengan komitment pas kontraknya

Dalam ITIL, dokumen2 tentang kontrak kerja disebut Underpinning Contract

Pastikan dalam dokumen tersebut tercatat detil2 kontrak (pas kerjasama…vendor itu ngerjain apa, masang apa, responsibilities-nya apa)…isinya berkisar:

  • Basic Term and Condition: berapa lama kontraknya, siapa kontak person-nya
  • Service Scope and Description: kerjanya apa, dimana, ngapain aja
  • Service Standard: tolak ukur kinerjanya nya apa
  • Workload Range: simple-nya…”Which service for which price”
  • Management Information: men-define data2 yang secara berkala harus dikirim dari 3rd Party ke kita…kek KPI (Key Performance Indicator), seperti contoh dibawah ini:

  • Responsibilities and Dependencies: taro orang vendor di Kantor, biar klo ada apa2 bisa langsung di-handle, trus define juga…kerjanya apa, sampe jam berapa

Supplier pun ada kategorisasi-ya berdasarkan Value, Importance, Risk, dan Impact-nya

  • Strategic – critical supplier…contoh-nya Supplier beras dan kopi buat café, ISP buat DaCen
  • Tactical – important supplier…supplier bumbu2 NasGor buat café, vendor2 kek Cisco, HP, dll buat Dacen
  • Operational – common supplier…supplier saos, cabe, dll yg non-essential..supplier software license
  • Commodity – non-important supplier…tanpa dia pun kita bisa sendiri, kek courier alias tukang kirim barang2 fisik

——————————————————–

Service Level Management

bagaimana cara mengetahui agar NasGor ini tergolong sukses dan laku ketika di launching

klo DaCen ini di launching, parameter apa yang bisa kita liat untuk menentukan worth apa engga ini Service dimata customer

Inti dari Service Level Management adalah menentukan SLA (Service Level Agreement)

SLA: menentukan parameter2 agar service bisa dikatakan berjalan lancar

denger2 café lu jual menu baru NasGor ya, bikinnya ga pake telor dan ga pake lama ya…

ok…gue akan sediain bandwidth untuk ke DaCen, minimum 512kbps

Klo 2 kalimat diatas tidak terpenuhi bagaimana? berarti ga sesuai dong dengan yang dijanjikan…ini berarti SLA-nya buruk

Karena SLA ini harus sesuai dengan kebutuhan customer maka klo bisa ada semacam SLR (service level requirement)

Isinya apa? penyataan dari customer ke kita…

eh, bikin NasGor dong, bosen French fries terus, klo bisa masak-nya jangan lama2

bikin DaCen yang bisa diakses darimana pun dan kapan pun dong, user kita banyak yang mobile, trus security-nya juga ya, pake VPN

Pernyataan ini akan diterjemahkan ke sudut pandang teknis dan organisasi, namanya SDP (Service Design Packages)

So, contoh…kita punya SDP dengan nama “XYZ” yang isinya user dapet minimum koneksi 512kbps, storage 1 Gbps, plus userpass VPN selama 1 minggu

Berarti klo ada customer request “XYZ”…dia dapet itu semua yang dijanjikan (minimum…sukur2 dapet 1mbps klo lagi lancar)

Apa aja sih yang biasanya dijadiin SLA, contohnya:

  • Introduction and Description: ini service buat apa dan nama service-nya apa
  • Mutual Responsibilities: tim IT sediain DaCen, customer yang tanggung jawab isi storage di DaCen
  • Scope: ruang lingkup dari service yang ditawarkan, biar ga ngerjain apa yang bukan tugas lu
  • Service Hours: kek restoran, ini service buka dari kapan sampe kapan
  • Service Availability: ketika service ini ready dan ada yang request…pastikan service-nya bisa bekerja
  • Customer Support Information: contact person klo ada yang mau make service
  • Contacts and Escalation Policy: klo kenapa2 ini service, siapa yang bisa dihubungi dan apa langkah2 antisipasinya
  • Security: tentukan klo service ini melindungi privasi pengguna (klo memang pake security)
  • Cost and Charging Method: biaya…apa lagi

Jadi klo ada yang nanya…”kok file di server gue error sih“, sementara tim IT DaCen cuma nyediain “jatah” storage aja…lu bisa ngomong bahwa itu bukan bagian dari tanggung jawab tim IT DaCen

Untuk bisa improve SLA, mungkin gara2 banyak yang request lebih dari SLA yang kita kasih…maka diperlukan Service Improvement Plan (SIP), adanya di topik/fase Continual Service Improvement (tahun 2011, namanya diganti jadi CSI Register)

SLA juga terdiri menjadi bbrp tipe:

  • Service-based SLA: 1 service untuk 1 hal saja, contoh…DaCen kita menyediakan storage space
  • Customer-based SLA: all type of service untuk 1 customer…DaCen kita menyediakan storage, security, plus pengaturan QoS-nya kepada perusahaan tertentu
  • Multilevel SLA: 1 service tapi beda customer…ini pun dibagi 3
    • Corporate-level SLA: hal2 umum kek service DaCen bisa diakses kapanpun, tapi tiap minggu jam 1 sampe jam 2 ada maintenance
    • Customer-level SLA: SLA untuk group dari customer, user dari Dept. IT berbeda perlakuan service-nya dari user dari Dept. non-IT…member café dan bukan member dapet NasGor beda harga
    • Service-level SLA: untuk isu2 khusus untuk user group tertentu yang butuh modifikasi SLA, ada user minta NasGor rasa Martabak misal wkwkwk

Supaya tim IT dan supplier bisa bersama2 memberikan service terbaik kepada customer…maka dibentuklah OLA (Operational Level Agreement)

eh…lu punya vendor ngerjain network buat konek ke DaCen ya, nanti maintain-nya dari orang lu, klo ada perubahan2 config jangan langsung diganti…rapat dulu sama kita

Biasanya kita bikin SLAM Chart (SLA Monitoring Chart) untuk ngawasin SLA yang sudah dibikin

So…dari SLR ke SLA ke SDP ke SIP…yang semuanya dimanage dengan kesepakatan dari OLA

—————

Capacity Management

ni kita sanggup handle berapa banyak request NasGor sih?”

storage untuk DaCen cukup ga? Bandwidth gede ga?”

Capacity: the maximum amount of delivery ability that an IT can produce

Inti dari Capacity Management adalah bagaimana kita tuning storage, partisi, QoS, adjust bandwidth, dan segala hal yang bisa di “sizing”

Cakupan Capacity Management adalah:

  • Business Capacity Management: gimana caranya kita mentranslate kebutuhan bisnis menjadi service yang ada kaitannya dengan kapasitas dan performa

    kek-nya mulai banyak nih yang mesen Nasgor, sanggup berapa banyak ya kita proses nasgor secara bersamaan?”

  • Service Capacity Management: manage kapasitas service, termasuk memprediksi supaya ga overused sehingga kita bisa melakukan inisiasi sebelum kapasitas yang ada kepenuhan

    dalam sehari ada request 10 nasgor nih, sedangkan panci nasgor cuma 1, artinya kita harus beli lagi

  • Component Capacity Management: manage performa resource yang dibutuhkan oleh service

    klo pake panci biasa, nasgor-nya jadi dalam waktu 10 menit, kita harus mempertimbangkan pake panci Teflon nih…biar masaknya cepet

  • Capacity Management Reporting: pastinya harus ada reportase ke IT Management

Alat untuk ngeliat kapasitas storage ataupun bandwidth (kek Solarwind dkk) didalam ITIL itu disebut CMIS (Capacity Management Information System)

———————————————–

Availability Management

ketika pelanggan request NasGor, maka item tersebut harus ada/ready

gimana caranya agar DaCen kita mencapai 99,999% uptime per-tahun

Inti dari Availability adalah ketika customer request service kita, maka service itu harus ada dan harus siap disajikan

Availability: kemampuan dari IT Service untuk perform sebagaimana fungsi yang telah disepakati ketika dibutuhkan

Ada 2 tipe penanganan ketika Availability tidak ada: Reactive vs Proactive

  • Reactive means ketika suatu service down, tim langsung mencari alternative solusi lain
  • Proactive means ketika suatu service down, service yang lain langsung mengambil alih

Ini artinya…proses Reactive lebih kearah instant solution dibandingkan dengan Proactive yang lebih membutuhkan proper planning sebelumnya

Ada beberapa istilah dalam Availability Management

  • MTBF (mean time between failures): bahasa ITIL dari UPTIME
  • MTRS (mean time to restore services): bahasa ITIL dari DOWNTIME, fase-nya pun didefinisikan
    • Detection Time: berapa lama trouble ini akhirnya ke-detect
    • Diagnosis Time: berapa lama waktu untuk nge-cek problemnya dimana
    • Repair Time: berapa lama waktu untuk benerin
    • Restoration Time: berapa lama waktu untuk bikin service kembali normal
  • MTBSI (mean time between system incidents): jeda waktu dari incident pertama ke incident berikutnya, semakin lama jeda-nya semakin bagus

Karena Availability berkaitan dengan incident…maka diperlukan namanya Maintenance Plan (Bahasa ITIL untuk S.O.P-standard Operation Procedure) sebelum service ini di launching

———————————-

Information Security Management

yang boleh mesen NasGor hanya yang exclusive membership café aja

yang bisa akses DaCen siapa aja, prerequisite-nya apa, ngapain aja

Inti dari InfoSec Management adalah bagaimana service CIA* kita yang kita kasih sesuai dengan kesepakatan

*CIA: Confidentiality, Integrity, and Availability

Ada beberapa hal yang harus diperhatikan dari segi InfoSec ketika kita merancang service sebelum masuk ke tahap operational

  • Design of Security Control: design alur sekuriti-nya, user group siapa yg bisa akses ini itu
  • Security Testing: ya testing
  • Security Incidents Management: kita harus ngapain klo ada incident di IT service, minimize impact-nya gimana
  • Security Review: setiap quarter ato annual/yearly…harus di review policy sekuriti-nya

———————————-

Risk Management

klo kita kehabisan NasGor gimana?”

klo DaCen kita down apa yang harus dilakukan?”

Inti dari Risk Management adalah mengidentifikasi, menilai, dan mengontrol resiko yang akan muncul

Risk = Threat X Vulnerability X Asset

Termasuk menganalisa value dari assets2 bisnis perusahaan, ancaman2nya, seberapa vulnerable-nya asset2 itu

ISO 27005 dan NIST SP 800 30 adalah salah satu sumber yang membahas tentang Risk Management

Ada beberapa hal yang di perhatikan dalam Risk Management

  • Risk Management Support: mendefinisikan resiko2 yang ada dan siapa yang handle
  • BIA (Business Impact and Risk Analysis): menganalisa resiko2 yang ada, mana yang impact-mya paling tinggi, hasil dari BIA ini adalah Risk Register (Risk Log)
    • Risk Register adalah kumpulan2 resiko yang sudah teridentifikasi dan bagaimana countermeasure nya
  • Asessment of Required Risk Mitigation: menilai mana resiko2 yang perlu penanganan dan siapa yang bertanggung jawab atas resiko itu
  • Risk Monitoring: monitor seberapa efektifkah countermeasure resiko yang diterapkan, dan melakukan “corrective” action klo diperlukan

Untuk recovery dari resiko, ITIL mengkategorikan menjadi 4 hal

  • Immediate: hot swap, hot standby, semua yang langsung ada redundancy dan failover-nya
  • Fast: contohnya Rapid Spanning-Tree untuk menangani resiko traffic LAN looping
  • Intermediate: warm standby…mungkin 1-2 hari downtime
  • Gradual: cold standby, biasanya replacement device…tanpa device tsb. pun, Perusahaan masih bisa jalan

———————————-

IT Service Continuity Management (ITSCM)

pastikan nasi selalu ada ketika ada yang pesen NasGor

pastikan koneksi ke DaCen di reserve 1mb biar jaga2 klo bottleneck

Inti dari ITSCM adalah memastikan tim IT tetap bisa mendeliver service dalam kondisi yang paling tidak menguntungkan (minimum agreed service) a.k.a Business Continuity yang jadi perencana Disaster Recovery Plan (DRP) 

Ada 4 hal yang dibahas di ITSCM

  • ITSCM Support: memastikan setiap personel tim IT tahu tugasnya masing2 dan semua dokumentasi2 tentang system/service harus tersedia ketika ada disaster
  • Design Service Continuity: merancang recovery plan untuk service2 vital
  • ITSCM Training and Testing: personel harus dilatih biar siap klo ada disaster harus ngapain
  • ITSCM Review: setiap recovery plan, disaster prevention, ataupun tugas personel2 IT harus di review secara berkala

———————————-

Compliance Management

kita mau bikin NasGor pake ala apa? Chef hotel bintang 5? Atau ala warteg?”

bikin DaCen pake standard apa? ISO? PCI? ANSI/TIA?”

Inti dari Compliance Management adalah menyesuaikan service dengan standard2 yang berlaku di dunia international, baik secara legal/hukum maupun tidak (best practice, framework, etc.)

———————————-

Architecture Management

we aiming for best NasGor experience, pastikan bumbu2 dan alat2 dapur dipilih yang best quality

alat2 DaCen harus yang paling canggih (klo kuat bayarnya)

Inti dari Architecture Management itu simple….pastikan up to date…infrastructure-nya

———————————-

Design Coordination

yang ngurus membership siapa? Yang handle supplier siapa? Yang tanggung jawab menu siapa?”

yang tanggung jawab InfoSec policy siapa? Yang handle maintenance siapa?”

New topic in ITILv3 2011, inti dari Design Coordination adalah maintain seluruh sub-proses dari Service Design diatas biar konsisten

Ada beberapa yang dibahas dalam Design Coordination

  • Design Coor. Support: mengkoordinasikan resource dan kapabilitas dari masing2 topik diservice design agar konsisten dan lancar pas masuk operational state
  • Service Design Planning: bagaimana cara agar kita make sistem/pendekatan design yang sama di seluruh fase service design, jadi ga asal maen ganti responsible person atau maen ganti compliance (ISO 27000, dll) sembarangan
  • Service Design Coor. And Monitoring: untuk koordinasi klo customer request minta service -nya aga di “modif” tertentu apakah bisa dipenuhi apa engga, termasuk dalam sisi ekonomi, namanya RFC (Request for Change)
    • RFC – Request for Change of service, dibahas di ITIL fase berikutnya, Service Transition
  • Technical and Organizational Service Design: mendefinisikan bagimana service ini akan “dihidangkan” alias di-provide dari sudut pandang IT
  • Review and RFC submission: nge-review SDP untuk terakhir kali dan membuat suatu dokumen formal untuk RFC klo2 ada perubahan2 service yang di request oleh customer

Next Step…Siap Dilaunching, Service Transition

—————

References

http://wiki.en.it-processmaps.com/index.php/ITIL_Service_Design

https://www.klipfolio.com/resources/kpi-examples

https://www.clearpointstrategy.com/how-to-determine-critical-success-factors-for-your-business/

http://www.seriosoft.com/blog/itil-v3-business-and-technical-service-catalogs

https://en.wikipedia.org/wiki/Service-level_agreement

https://en.wikipedia.org/wiki/Service_level_requirement

https://en.wikipedia.org/wiki/Operational-level_agreement

http://wiki.en.it-processmaps.com/index.php/Risk_Management

https://rmf.org/

Older Entries