Home

ITIL Service Design Overview

Leave a comment

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 dan YANG AKAN 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 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

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 dang a 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 lancer)

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)

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/

ITIL Service Design Overview

Leave a comment

Service Design in General

Service Design in ITIL is to design IT services, together with the governing IT Practices, processes, and policies to realize the service provider’s strategy and to facilitate the introduction of these services into supported environments, ensuring quality service delivery, customer satisfaction, and cost-effective service provision (ITIL Service Design book page 4)

Translate: Service Design ini ditujukan kepada Service Provider untuk memudahkan (service) strategy yang sudah dibuat agar dapat diaplikasikan kelingkungan yang sedang berjalan

Dibawah ini komparasi dari ITIL Service Lifecycle-nya dengan Cisco PPDIOO-nya

Cisco PPDIOO and ITIL

So…tujuan dari service design adalah:

  • Reduce TCO (total cost ownership) – well, klo bisa ini network dihandle orang lain (dan murah), kenapa mesti kita yang handle…
  • Quality of Service Improvement – berdasarkan trend sekarang, (contoh) customer pake jasa ISP lebih kearah gaming (strategy, demand management)…oleh karena itu mari kita rancang suatu produk/service untuk meningkatkan kenyamanan user dalam bermain
  • Consistency, whether new or ongoing service – self explanatory
  • Streamlined IT Process – ketika kita memasuki tahap design sebuah service…yang ditekankan memang processnya (how to-nya sedetail mungkin)
  • Improvement in IT Governance – design yang baik akan menghasilkan prosedur IT service yang ga bertele2, trouble ticket ga harus melewati 4-5 orang lagi…cukup maximal 2 step (contohnya)…trouble ticket langsung dikerjakan
  • Efficient Decision Making in ITSM – well, klo IT Governance bagus ya ITSM nya juga ikut kebawa bagus harusnya

Service Design in ITSM affect these guys:

  • People – of course, lol
  • Products – in ITIL this is called Service (mau bikin service apa?)
  • Processes – how this service works, in ITIL this is called SDP (Service Design Package)
  • Partners – siapa yang bantu kita untuk service ini jalan, the supplier of service

Dalam service design kita kenal namanya SDP alias define the process to make sure the strategy works, there’s 4 things for making SDP

  • Requirement – apa aja yang dibutuhkan untuk bikin design ini jadi nyata
  • Organizational Readiness Assessment – make sure we ready to deliver this service if it comes out
  • Service Lifecycle Plan – klo mau update gimana prosesnya…klo mau upgrade gimana planningnya…
  • And 5 aspect of Service Design – to make sure you make the right service

Which are…

  1. Service Solutions – lu mau bikin product/service apa? Hahaha…biasanya dilihat dari Service Portfolio di Service Strategy (service apa yang sudah ada, service apa yang belum ada, atau service apa yang harus di enhance)
  2. MIS (management information system) – gimana cara lu manage ini service solution? Termasuk service lifecycle-nya
  3. Technology Architecture – pake technology apa untuk service ini jalan? Dot1x? PKI/CA? atau Cuma pake port-security (missal klo lo jualan network security services)
  4. Process – ya pasti, make sure we have the capabilities to perform the process (lu jualan Cisco ISE yang support Radius CoA tapi switch lu cuma support dot1x-nya aja (ipbase IOS), kan kaga lucu)
  5. Measurement and Metric – well, to make sure we “hit” the target (read: agreed standard between you and customer), tentu harus ada pengukurnya…contohnya pake NetFlow (bener ga http trafficnya ke reduce pake QoS, contoh)

Ketika hal2 tersebut diatas sudah ada atau lengkap, sekarang saatnya “merancang” (design) service dari planning (strategy) yang sudah disepakati

And remember one of affected things in service design is Partner or Supplier, we need to manage those guys to in order our design plan looking good…in common words…Supplier Management

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

Supplier Management

Supplier Management in ITIL is to ensure that suppliers and the services they provide are managed to support IT service targets and business expectations. Also, it obtains value for money from suppliers and contracts, while ensuring contracts with suppliers are aligned to business needs (ITIL Service Design book page 207)

Translate: memastikan bahwa partner (supplier) dan service yang mereka provide bisa dimanage demi kepentingan bisnis

What is supplier? Supplier in ITIL is 3rd party partner to help Us to deliver services…kek Cisco yang provide alat2 dan jasa untuk mengembangan Collaboration technology untuk perusahaan kita (Voice and Video over IP)

Management supplier ini juga mengatur bagaimana pengaturan tentang contract2 bisnis dengan supplier, sesuai ga harga dengan service yang mereka tawarkan

Contoh, Kita mau bikin service VoIP didalam perusahaan kita, kita minta bantuan supplier untuk pengadaan barang dan jasa…check if the price is right, check if the service offered by them is correct, and check if aligned with business needs (biasanya kan di Indonesia ga terlalu butuh2 banget Telepresence/Video Conference…tapi tetep aja disodorin ama mereka…dengan iming2 ini itu dan janji2 surga lainnya hahaha)

Supplier management ini harus ada MIS nya…yaitu SCMIS (Supplier and Contract Management Information System), yaitu management kontrak kerja dengan vendor

SCMIS ini nanti ada kaitannya ke SKMS (Service Knowledge Management System) di Service Transition phase, SKMS ini berkisar tentang configuration database dan teman2nya (we’ll talk later)

Biasanya klo uda ngomongin tentang supplier…berarti kita ngomongin kontrak kerja dengan mereka…apa aja sih yang penting untuk dibicarakan dalam hal kontrak ini?

  • Basic term and condition – biasalah…siapa yang handle kerjaannya dan berapa lama kontrak ini berlaku
  • Description and Scope – service apa yang ditawarkan kepada kita
  • Standards – kesepakatan dengan partner, contoh: vendor akan ngasi ip phone, ngerjain implementasinya, sama maintenance-nya…singkat kata…SLA (service level agreement)
  • Workload Range – simplenya…which service for which price
  • Management Information – data2 apa aja yang mereka kirim ke kita agar kita tahu service yang ditawarkan berjalan lancer, biasanya ini KPI (key performance indicator) atau CSF (critical success factor)
  • Responsibilities and Dependencies – taro orang dikantor (outsource), role-nya apa alias ngapain disana/kerjanya apa, trus sampe jam berapa

Nah, kita perlu tahu bahwa untuk 3rd party ini alias supplier harus kita kategorisasikan berdasarkan Value-and-Importance atau berdasarkan Risk-and-Impact

  • Strategic Supplier – critical, klo ga ada dia, service kita ga jalan (Cisco dengan IP Phone-nya, ga ada mereka…kita ga bisa nyediain service VoIP ke user…klo pengennya Cisco-atau kasarnya-Board of Director kita udah “kepegang” ama Cisco lol)
  • Tactical Supplier – Important, partner-nya Cisco yang kerja sama sama kita (Vendor/IT Solutions Company), klo ga ada ya bisa diganti vendor lain yang support Cisco juga
  • Operational Supplier – Common, contohnya supplier untuk software license, maintenance, dll
  • Commodity – not important, klo ga ada mereka…kita bisa handle sendiri, contoh kek install ulang…ga perlu pakek vendor lah beginian doang

Bisa ga 1 SI (sistem integrator) masuk ke semua tipe? Bisa…

Untuk menentukan supplier2 ini tentu kita harus mendefine new supplier (kita butuh service apa, vendor apa aja yang siap memenuhi kebutuhan kita), trus kita evaluasi itu supplier (contoh: track record dan service portfolio yang mereka tawarkan), setelah itu baru kita kategorisasikan itu supplier2…mana vendor yang penting ama yang engga, dan jangan lupa Supplier Contract Management juga harus dihandle (biasanya annual/per tahun), terakhir baru kita putusnya untuk renewal atau termination

Hal2 diatas itu penting untuk menentukan Service Level Management yang kita tawarkan ke customer/user

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

Service Level Management

Service Level Management in ITIL is to ensure that all current and planned IT Services are delivered to agreed achievable targets. This accomplished with a constant cycle of negotiating, agreeing, monitoring, and reviewing IT Service targets and achievements (ITIL Service Design book page 106)

Translate: Service level management itu berbicara tentang bagaimana memastikan bahwa service2 IT yang sedang berjalan (dan lagi dibahas/dirancang) itu sesuai dengan target yang kita mau

Caranya? Dengan selalu memonitor dan me-review target2 yang ingin dicapai oleh IT Service

Dengan begitu kita bisa merancang SIP (Service Improvement Plan), yaitu rencana FORMAL (ga cuma ngemeng doang, ada hitam diatas putih dan tgl berapa dilaksanakan) untuk membantu meningkatkan proses/kualitas service yang dikarenakan SLA yang tidak tercapai, weak system testing, tidak adanya training yang memadai, ataupun gara2 komplain dari customer/user…kadang SIP ini muncul klo suatu service gone wrong (bermasalah)

Kek kita butuh peningkatan bandwidth dari 512 kbps ke 1mbps misalnya, karena ada request untuk meningkatkan kualitas pelayanan IT ke customer yang kerjanya memang diarea video conferencing (contoh)

Requirement2 yang dibutuhkan berdasarkan objective bisnis dari customer inilah yang disebut SLR (Service Level Requirement)

SLR ini dipergunakan guna meningkatkan kualitas SLA dalam SIP, apa aja sih yang kita perlu tahu dalam SLA

  • Introduction – Service apa yang pengen di improve
  • Description – self explanatory
  • Mutual Responsibilities – gw sediain bandwidth, tapi modem lu yang pasang sendiri
  • Scope – improvement service…1 mbps yaks…dan ga ngebahas soal service software yaks…(pastikan nyambung dengan SIP)
  • Service Hours – self explanatory
  • Availability – siapa aja yang dapet ini service improvement
  • Customer Support Informationhow we contact the one who responsible for this improvement (pake trouble ticket dulu apa langsung aja)
  • Contacts and Escalation Policy – this is the one who responsible, nomor kontak orang nya…trus klo improvement ini bermasalah atau perlu diupgrade lagi, gw harus ngapain
  • Security – pastikan yang dapet service improvement ini datanya terjaga (well, ga Cuma ini aja sih…banyak contoh2 yg lain)
  • Cost and Charging Method – perlu ga kita kasi charge untuk service improvement ini, 512 kbps is free…tapi klo 1mbps, bayar

SLA ini pun dibagi menjadi 3 type…berdasarkan service catalog yang kita punya

  • Service-based SLA – 1 service for 1 thing only (service naikin bandwidth…ya bandwidth aja)
  • Customer-based SLA – multi service to 1 customer (naekin bandwidth, free modem, setting QoS gratis)
  • Multi-level SLA (ada 3 lagi)
    • Corporate level – general service issue, jam berapa karyawan ga bisa pake VoIP atau security policy in general
    • Customer level – (klo di HQ dapet SLA yang berbeda dari pada di branch, apalagi yang remote user…kek di amerika service ditawarkan dengan bahasa inggris, di Indonesia pake bahasa)
    • Service level – terdiri dari berbagai macam service ke multi customer

Supaya SLA ini bisa tercapai, maka kita harus memastikan team IT Support dan Supplier saling melengkapi agar SLA yang ada terpenuhi sesuai dengan target yang diminta customer (OLA – Organizational Level Agreement)

Nah, SLA yang kita tawarkan ke cutomer ini juga harus dimonitor, di ITIL namanya SLAM Chart (Service Level Agreement Monitor)

Contoh dari aplikasi yang kita bisa refer ke SLAM chart itu kek Solarwind network management tools atau software the DUDE (yg pake mikrotik pasti tau)…klo link-nya merah…tandanya bandwidth kepake banyak (full), kuning tandanya aga lumayan, klo ijo berarti sehat itu link

Nah, report dari monitoring itu bisa dipergunakan untuk improve service yang kita tawarkan, biasanya report ini dikasi ke level managemen per-annum (annual alias per-tahun, tergantung policy perusahaan)

Hasil2 result dari SLAM ini bisa membantu kita dalam management service catalogue (database service yang kita punya)….in ITIL called Service Catalogue Management

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

Service Catalogue Management

Apa yang terpikir ama lu dari gambar diatas? List dari produk minuman yang ditawarkan kan??

Di ITIL ini namanya Service Catalogue…list/database dari service2 apa aja yang kita tawarkan ke konsumen

Service Catalogue: “to provide and maintain a single source of consistent information on all operational services and those being prepared to be run operationally. To ensure that it is widely available to those who authorized to view it” (ITIL Service Design book page 97)

Translate: database dari service2 yang OPERASIONAL alias live IT Services (yang belum atau retired service, ga masuk) dalam 1 source…entah dalam bentuk file excel, sql, atau yang lain. Plus, ini database hanya available dan harus available ke orang yang terotorisasi

Service catalogue inilah yang akan ditampilkan ke konsumen (costumer facing), beda ama service portfolio (kita punya service apa aja…dari yang existing, retired, ataupun future service project)

Service2 yang termasuk dalam catalog harus mempunyai komponen2 berikut

  • Deliverables – pastilah…lu jualan servis tapi ga bisa ngasih servis itu, ga lucu kan…
  • Prices – biasanya ada price nya (walaupun kadang ditulis, negotiable, market price, atau by request…hahha)
  • Contacts – ini juga ga perlu dijelasin, lu mau servis ini harus ngomong ama siapa…ngomong ama hantu? Lu kira pesugihan?!?!
  • How to Order and request – self-explanatory

Karena service kita ada value dimata konsumen, berarti kita juga harus memaintain asset (remember, asset = anything that has a value)…di ITIL disebut Service Asset (dibahasnya di Service Operation)

In official…customer facing catalog biasa disebut Business Service Catalogue

Dan supaya IT support kita juga punya “list resmi” tentang apa aja yang bisa mereka lakukan untuk customer, kita juga harus punya Technical Service Catalogue

Untuk bisa Service2 catalogue ini bisa diakses secara benar, artinya kita juga harus tau cara memaintain Availability-nya…in ITIL this is called Availability Management

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

Availability Management

To ensure that the level of availability delivered in all IT Services meets the agreed availability needs and/or service level targets in a cost-effective and timely manner. This is both current and future needs of the business” (ITIL Service Design book page 125)

Translate: bagaimana caranya agar IT Service yang ditawarkan agar bisa perform sebagaimana mestinya dan harus ada ketika dibutuhkan, dalam kacamata biaya yang diperlukan dan waktu yang dibutuhkan

Biasanya vendor2 yang jualan Availability itu ngomongnya Five’s Nine guaranteed uptime (99.999%, alias 5 menit downtime per tahun, vendor Data Center network yang biasanya yang jualan begini)

Karena availability itu ngomongin tentang ketersediaan service…berarti klo tidak tersedia, apa yang kita harus lakukan

  • Reactive – instant feedback
  • Atau Proactive – pake planning, karena pake planning (dikira2 kenapa, bagaimana, simulasi apa saja yang bikin service down), berarti time-consuming

Yah, lu trade-off aja…mana yang kira2 bagus disituasi tertentu

Dari kacamata ITIL, uptime disebut MTBF (mean time between failures) alias…seberapa lama service ini bekerja sebelum down

Sedangkan downtime disebut MTRS (mean time to restore service) alias…seberapa lama waktu yang dibutuhkan untuk bikin service ini bekerja kembali

Downtime sendiri ada prosesnya:

  • Detection time – waktu yang dibutuhkan untuk mendeteksi adanya service yang down
  • Diagnosis time – waktu yang dibutuhkan untuk mencari penyebab service yang down
  • Repair time – waktu yang dibutuhkan untuk menyelesaikan/menghilangkan penyebab service yang down
  • Restoration time – dan waktu yang dibutuhkan untuk membuat service ini aktif kembali

Nah, bisa jadi dalam suatu perusahaan ada beberapa service yang down…jeda waktu antar service down issue yang satu dengan yang lain disebut MTBSI (mean time between system incidents)

Mengenai incidents, dalam security ada 2 terminologi:

  • Event – yaitu suatu kejadian didalam service
  • Incident – yaitu event yang membuat suatu proses(di ITIL adalah service) terganggu

MTBF, MTRS, dan MTBSI ini dihandle oleh availability manager…siapa itu? Ya IT support…tugasnya kan supaya ensure IT service is running smoothly

Untuk merestore IT service (contohnya network) berarti kita harus punya yang namanya SKMS (service knowledge management system), atau CMDB (configuration management database), atau AMIS (availability management information system)

SKMS – CMDB – AMIS itu beda singkatan aja…intinya harus ada mekanisme untuk restore service

Contoh: sebelum Cisco, Juniper udah punya namanya restore configuration dengan sistem rollback…rollback ke date tanggal berapa, jadi engineer ketika ada yang salah konfig bisa restore ke earlier time tanpa harus nyari2 archive configuration…akhirnya Cisco dengan IOS XR-nya ngikut…inilah yang disebut CMDB

ya, Commit Confirmed

Availability alias ketersediaan service ini terkait dengan

  • Capacity management – klo storage atau bandwidth penuh…service di stop atau nambah lagi?
  • Information Security management – memastikan the right person is able to access the right file
  • Design Coordination management – baik service availability, security, dan capacity harus kita koordinasikan dengan pihak2 terkait

Nah, 3 hal ini ga dibahas di ITIL foundation

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

Capacity Management *bonus*

Hahaha…tanggung lah….hajar bleh

To ensure that the capacity of IT Services and the IT infrastructure meets the agreed capacity and performance related requirements in cost-effective and timely manner. It meets both the current and future capacity and performance needs of the business” (ITIL Service Design page 158)

Translate: memastikan bahwa kapasitas IT baik dari segi infrastructure maupun service itu sendiri memenuhi permintaan

Contoh: paling gampang storage capacity atau bandwidth capacity…

Capacity itu sendiri apa sih? The maximum amount of delivery ability that an IT can produce

Objective dari capacity management adalah:

  • Produce and maintain appropriate/up-to-date plan
  • Assist with diagnosing and resolving performance/capacity issues
  • Ensure all performance achievement meets their target

Untuk itu kita perlu punya CMIS (Capacity Management information System)

Contohnya kek gini: (no commercial promotion intended, wkwkwk)

Trus bagaimana klo kita ga bisa afford untuk buy another storage and bandwidth? QoS config…alias tuning bandwidth ataupun storage (klo ini lebih kearah application sizing, hard disk partition)

Sub-process dari availability management ini ada 4 (ga gw bahas satu2):

  • Business Capacity Management – how we adjust capacity for business objective
  • Service Capacity Management – how to adjust capacity for operational services
  • Component Capacity Management – monitoring IT capacity and utilization
  • Capacity Management Reporting – ya reporting about capacity tentunya

Primary activities dalam Availability management ini adalah:

  1. Performance Monitoring
  2. Controlling Demand Management – hasil dari Demand Management (Service Strategy) akan dimasukan dalam planning Service Design
  3. Modeling and Tuning – QoS oriented
  4. Application Sizing – contohnya kek hard disk partition
  5. Capacity Planning

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

Information Security Management

To align IT Security with business security and ensure that confidentiality, integrity, and availability of the organization’s assets, information, data, and IT services matches the agreed needs of the business” (ITIL Service Design page 197)

Translate: bagaimana caranya IT service security dengan CIA-nya (Confidentiality, Integrity, dan Availability) sudah sesuai belum dengan standard bisnis

Yang dibahas di IS management adalah:

  • Confidentiality – bagaimana caranya data ga bisa dibaca orang yang tidak berhak
  • Integrity – bagaimana caranya data ga bisa dirubah oleh orang yang tidak berhak
  • Availability – bagaimana caranya data ga bisa diakses oleh orang yang tidak berhak
  • Risk Management – finding things that could go wrong and how to stop it from becoming wrong
  • SMIS (Security Management Information System) – how to guide the development and management of your information security program
    • Procedural Security – how you secure things
    • Physical security – lock and keys anyone?!?
    • Organizational Security – general security
    • SMIS = Plan -> Implement -> Control -> Evaluate -> Maintain -> Plan again
  • Security Policy – aturan2 yang harus dipenuhi supaya security berjalan
  • Threat – ancaman IT terhadap organisasi
  • Vulnerability – celah2 yang bisa menjadi threat itu sendiri

Ga bahas 1-1…mending lu baca ISO 27001 deh…komplit pake telor

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

Design Coordination

To provide and maintain a single point of coordination and control for all activities and processes within this stage of the service lifecycle” (ITIL Service Design page 86)

Translate: untuk menyediakan dan maintain seluruh aktivitas dan proses dalam 1 koordinasi

Yang termasuk dalam Design Coordination adalah:

  • IT Service Continuity Management – gimana caranya service ini bisa jalan lagi klo ada hambatan, simplenya…Disaster Recovery Plan yang tentunya sesuai dengan BIA
  • BIA (Business Impact Analysis) – klo kenapa2…opsi apa yang kita punya untuk recovery
    • Immediate – fitur2 kek hot swap atau hot standby (FHRP kek HSRP dan teman2nya)
    • Fast – kek R-PVST dalam switch
    • Intermediate – warm standby…biasanya 1-2 hari downtime (ganti module infrastructure biasanya)
    • Gradual – cold standby …ganti infrastructure itu sendiri biasanya…

Yang termasuk Gradual biasanya yang “we can survive without having that technology/service”, karena klo yg ga bisa survive…masuknya ke immediate atau fast

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

References

ITIL Service Design book

http://www.routerfreak.com/managing-a-large-network/

Cbt Nugget ITIL Foundation video by Chris Ward

Nanda Noviza Rachman as my ITIL mentor