Home

ITIL Service Operation Overview

February 23, 2017

Miftah Rahman Other Stuff , , , , , , , , , , , , , , , , , , , 1 Comment

Setelah masa transisi selesai, saatnya duduk…diam…dan nunggu complain wkwkwk

Pada dasarnya memang Itulah inti dari Service Operation, to make sure the IT services delivered effectively and efficiently

bedain sama Project ya,

Project: Temporary, ada start project, ada stop (closing) project

Operation: Ongoing, terus2an…

jadi klo ada Project “ga kelar2” suka disebut Operation Project hahaha

In a nutshell, Service Operation is about “steady state”

pembahasan service operation berkisar seputar

  • Stabilitas vs Responsivitas (stabil tapi lemot, responsive tapi ga stabil)
  • Cost vs Quality (ada harga ada rupa bro…)

Ada beberapa proses yang termasuk dalam inti bahasan Service Operation

  • Event Management
  • Access Management
  • Incident and Problem Management (ilmu yang cocok buat IT help desk)
  • Request Fulfillment
  • IT Operation Control
  • Facilities Management
  • Application Management
  • Technical Management

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

Event Management

“eh besok garam abis nih…NasGor-nya gimana?”

“tiap jam 12 kok bandwidth kepake lebih dari 80% ya?”

Inti dari Event Management adalah monitoring service dan CI-nya (see Service Transition for CI definition)

Event: semua perubahan keadaan pada CI. Tools untuk ngeliat event adalah SYSLOG Server/Event Viewer/etc.

Tools2 tersebut akan menghasilkan Alerts (notifikasi kek “failure has been occurs”, “threshold warning”, dll)

Di ITIL, ada 3 tipe event yang ditekankan

  1. Informational Event – logging system, ada user (yang berhak) masuk
  2. Warning Event – warning sign klo storage udah lebih dari 80% capacity
  3. Exception Events – lebih ke arah emergency event, CPU heat, malware detection, dll

Ada beberapa bahasan dalam Event Management

  • Maintenance of Event Monitoring Mechanism and Rules: mengatur rule2 filter dan set up server untuk event log
  • Event Filtering and 1st Level Correlation: mengkategorisasikan mana event yang bisa di ignore dan mana yang harus di tindak lanjuti
  • 2nd Level Correlation and Response Selection: menginterpretasikan event dan memilih respon yang tepat untuk event tersebut
  • Event Review and Closure: ya review, mana event yang bisa ditangani mana yang tidak, dari review2 tentang event ini akan menghasilkan Event Trends and Patterns

    “eh, tiap jam 12 kok internet lambat ya” “eh, kek-nya tiap 2 minggu garam dapur abis de“

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

Access Management

“siapa yang berhak dapet diskon 50% untuk menu NasGor”

“siapa yang boleh akses VPN ke DaCen”

Inti dari Access Management ya ngasi otorisasi ke user yang berhak mendapat service tersebut

Kadang disebut juga Identity Management atau Rights Management

Isinya berkisar tentang user ID, user Group, profile, LDAP atau ActiveDir, sekitar2 itulah

Ada 2 objektif dari Access Management

  • Maintenance of Catalog of User Roles and Access Profiles: bikin katalog/menu tentang user roles dan profiles dan mencegah orang punya akumulasi/beberapa access profile
  • Processing of User Access Requests: memproses request untuk add/change/revoke access right dan make sure hanya authorized user yang boleh menggunakan fitur ini

———————————

Incident and Problem Management

“eh, kompor tiba2 mati nih, ga bisa masak NasGor kita”

“kok akses ke DaCen ga bisa ya”

Sebenernya Incident dan Problem Management ini dalam ITIL dipisah sendiri management-nya (Cuma gue gabung, soalnya intinya sama…service kita bermasalah, gimana nanganinnya)

Incident Management: gimana caranya untuk restore Service yang mengalami gangguan performa, secepat mungkin tentunya

Problem Management: menganalisa akar masalah yang menyebabkan incident terulang lagi

Kita perlu tau bedanya Event, Incident, dan Problem…

  • Event: segala sesuatu yang berubah pada sistem, kek kita “write mem” untuk save perubahan
  • Incident: Event2 yang bersifat negative tapi kita tau penyebabnya dan cara koreksinya, kek “duplicate IP has been detected”
  • Problem: Incident yang berulang/belum diketahui penyebabnya dan koreksinya seperti apa, contohnya…Internet mati, tapi ISP bilang ga ada yang bermasalah

Incident Management proses:

  • Incident Management Support: tujuannya untuk provide dan maintain tools, proses, skill, dan rules yang dibutuhkan klo ada incident
  • Incident Logging and Categorization: setiap incident harus di record/catet dan memilih incident mana yang harus diprioritaskan untuk dibenerin terlebih dahulu
    • Prioritization: Urgency + Impact
  • Immediate Incident Resolution by 1st Level Support: solving incident dalam rentang waktu yang disetujui (secepat mungkin intinya), siapa ini? Biasanya Help Desk/Service Desk
  • Incident Resolution by 2nd Level Support: klo 1st level support ga bisa solving, workaround-nya gimana. Siapa ini? Biasanya IT Spesialis-nya…netAdmin, sysadmin, dll
  • Handling Major Incidents: ini 3rd Level support yang handle
    • 3rd Level Support: biasanya dilimpahin ke vendor/TAC/specialist consultant/3rd party supplier..intinya yg udah expert
  • Incident Monitoring and Escalation: monitoring incident secara terus-menerus jadi begitu ada counter-measure terhadap incident langsung bisa di benerin saat itu juga
  • Incident Closure and Evaluation: menutup case dari incident yang sudah selesai dan mengevaluasi Incident Record (berkas incident), biar ga kejadian lagi
  • Pro-Active User Information: inform semua pengguna service yang kena incident (tugasnya help desk), jadi user bisa “memposisikan” diri saat incident berlangsung (biar ga banyak email complain masuk, udah dikasi tau duluan soalnya)
    • Sistem IT yang sudah mapan biasanya dibikinin User FAQ (biar user ga nanya2 mulu, tinggal liat FAQ-nya di file, dokumen, atau website-nya)
  • Incident Management Reporting: pastikan berkas2 incident ini bisa dipake untuk improvement service berikutnya

Fase Incident Management (taken from pearsonitcertification.com)

Pencarian solusi terhadap incident yang belum ketemu penyebabnya sehingga harus menunggu incident terulang lagi (agar lebih clear akar masalahnya) disebut Reactive Problem Identification (slow response solution, but providing the best solution)

Untuk Problem Management, ada 7 proses yang dibahas

  • Proactive Problem Identification: gimana caranya kita memprovide workaround sebelum incident terulang lagi, fast solution (belum tentu best solution)
  • Problem Categorization and Prioritization: sama seperti incident categorization
  • Problem Diagnosis and Resolution: mendiagnosa suatu problem, with RCA
    • RCA: Root Cause Analysis, kita bahas detail dibawah
  • Problem and Error Control: monitoring problem yang urgent, klo ada tindakan korektif bisa langsung diaplikasikan
  • Problem Closure and Evaluation: bikin problem record/catatan dokumentasi problem yang disebut Known Error Database (KEDB), database tentang semua error yang diketahui penyebabnya dan cara mengatasinya
  • Major Problem Review: solusi2 dari problem itu di review kembali, kali aja ada yg lebih bagus
  • Problem Management Reporting: sama seperti incident management reporting

tadi kita sedikit menyinggung soal RCA, apa sih yang dibahas di RCA?!?

RCA (Root Cause Analysis) itu punya 5 step proses

  1. Define the Problem (what happen? Gejala2nya apa?)
  2. Collect Data (how long it happens? What proof? What impact?)
  3. Identify Possible Cause (what sequence lead to this? What condition this occurred?)
    1. so what? Mungkin gara2 budget cut, mungkin skill IT-nya kurang, mungkin…
    2. why? Kenapa harus 1Gb storage?, kenapa harus pake VPN, kenapa…gara2 itu mungkin
    3. drilling down…cari semua informasi secara intensif (tentunya yang relevan)
    4. bikin diagram Cause and Effect, kek dibawah ini (taken from mindtools.com)


      jadi begini…

  4. Identify Root Cause (why this cause exist)
  5. Recommend and Implement Solutions (what can you do to prevent from happening again)

Untuk meminimalisir RCA, kita bisa pake metode Failure Mode and Effect Analysis (FMEA) atau bahkan pake Kaizen Method

  • FMEA: di desain oleh DoD tahun 1949, yaitu metode analisis resiko untuk QC, di ITIL ini dibahasnya pada Service Design


  • Kaizen Method: metode ini lebih kearah filosofi (people oriented) daripada sekedar tools. It relies heavily on Continuous Service Improvement phase (link artikel menyusul)

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

Request Fulfillment

“ada yang request NasGor-nya ga pake acar nih, satu lagi minta NasGor aga pedesan dikit”

“ada yang minta dibikinin user account buat akses DaCen via VPN”

Inti dari Request Fulfillment adalah bagaimana kita sebagai service provider bisa menyanggupi atau tidak sebuah permintaan (biasanya yang ringan2/minor request), artinya bikin kanal/bikin tim tempat “penampungan” request service tersebut

bahasa mudahnya… harus ada CASHIER/kasir wkwkwkwk

Jadi klo ada user mau minta hak akses VPN, dia harus bikin/minta Request for Service document

Request fulfillment biasa dihandle oleh Service Desk

Ada 5 proses (ada tambahan di ITILv3 2011) dalam Request Fulfillment

  • Request Fulfillment Support: menyediakan tools2, proses, skill yang dibutuhkan buat handling request
  • Request Logging and Categorization: mengkategorisasikan request yang masuk, jadi bisa menentukan mana yang mau dikerjain duluan
  • Request Model Execution: memastikan request yang dikerjain sesuai dengan time schedule
  • Request Monitoring and Escalation: monitoring request2 yang belum dikerjain, mesti diapain ni request
  • Request Closure and Evaluation: mengevaluasi request record/catatan2 request yang ada sebelum request tadi dinyatakan selesai/done, berguna juga klo mau improvement service kedepannya dengan melihat request trend

—————————–

IT Operation Control, Facilities Management, Technical Management, dan Application Management

“saatnya kita bentuk tim untuk café, tim Koki/tim dapur, tim managemen keuangan, tim Barista”

“yang ngurus complain DaCen ada tim sendiri, yang ngurus tshoot ada sendiri, yang review request ada sendiri”

Inti dari IT Ops Control, Facilities, Technical, dan Application Management adalah untuk monitoring IT services dan semua infrastructure yang menunjang service itu berjalan, dengan cara…bikin TEAM

Di ITIL team, group, atau organisasi yang ngurus hal tertentu dari proses disebut FUNCTION

Yang paling dibahas di ITIL adalah Service Desk (the 1st Level Support), ada bbrp tipe Service Desk menurut ITIL:

  • Local Service Desk: ini yang umum, itu TS (technical support)-nya tempatnya deketan ama user. Jeleknya dari tipe ini adalah kadang requestnya by person…ga pake trouble ticketing dulu, mintanya cepet wkwkw
  • Centralized Service Desk: itu TS/help desk di kumpulin di satu ruangan sendiri (kek mirip call center gitu)
  • Virtual Service Desk: kek Centralized, Cuma lokasi engga ditempat yang sama
  • Follow The Sun: ini yang diterapin di vendor2 gede, tempat call center-nya dimana2 diseluruh dunia /distributed call center…jadi klo lo telpon help desk-nya malem di Amerika, yang jawab dari Call Center-nya India yang masi pagi…, klo lo telpon-nya malem dari Indonesia, yang jawab dari Eropa (yg masi pagi juga)

“good morning, may I help you?”

“(dalem hati)…gue bukannya telpon jam 12 malem nih, ini gue yang bingung apa Die yang dongo sih?”

…jadi, selalu greeting-nya Good Morning…dimanapun elo berada

and next…we’ll talk about ITIL CSI (Continous Service Improvement)

——————————

References:

http://www.pmchamp.com/3-things-you-need-to-know-about-projects-and-operations/

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

http://www.pearsonitcertification.com/articles/article.aspx?p=2260779&seqNum=7

https://www.mindtools.com/pages/article/newTMC_80.htm

http://asq.org/learn-about-quality/process-analysis-tools/overview/fmea.html

http://www.valuebasedmanagement.net/methods_kaizen.html

http://www.myitstudy.com/blog/2013/04/types-of-service-desk-in-itil/

 

ITIL Service Transition Overview

September 7, 2015

Miftah Rahman Other Stuff , , , , , , , , , , , , , , , , Leave a comment

“To build and deploy IT services. Service Transition also makes sure that changes to services and Service Management processes are carried out in a coordinated way.”

Translate: memastikan bahwa perubahan2 pada services bisa berjalan dengan bagus…core subject dari service transition itu memang bagaimana menghandle PERUBAHAN alias CHANGE MANAGEMENT

Kita mau ganti dari BA (business analyst) application yang lama ke software bernama SAP misalnya…apa aja yang harus disiapkan, disinilah Service Transition bekerja

Inti dari service transition adalah:

  • Manage service changes with efficiency – setiap berubahan dalam servis harus bisa di handle dan ada planningnya
  • Successfully deploy the new or changed services – harus bisa dihandle yang berujung suksesnya services itu berjalan
  • Meet the agreed requirement – service ini berubah sih boleh, tapi pastikan sesuai dengan business requirement
  • Educate about services and assets – perubahan service berarti kadang kita harus training orang lagi
  • Manage risk – one of the most important, service transition memastikan bahwa perubahan2 service dari design yang sudah direncanakan itu punya mekanisme dalam menghandle resiko2 yang akan muncul kedepannya

Benefit nya:

  • Enable more accurate cost, timing, and resource requirement – please tell me anyone who disagree with this
  • Make it easier for people to adopt and follow – educate anyone?
  • Reduce delays due to unexpected clashes and dependencies – proper planning transition pastinya akan reduce delay for delivering newly changed service
  • Improve expectation setting for all stakeholders – self explanatory
  • Ensure that new or changed services will be maintainable –Service Transition heavily adopt SDP Lifecycle (dibawah dijelasin)
  • Improve control of service assets and configurations – self explanatory

Untuk Service Transition kita berhasil maka kita harus punya yang namanya Transition Planning and Support

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

Transition Planning and Support

“To provide overall planning for service transitions and to coordinate the resources that they require” (ITIL Service Transition book page 51)

Translate: supaya transisi service berjalan maka kita harus punya planning dan koordinasi sumber daya yang dibutuhkan supaya transisi nya berhasil

Biasanya sebuah service ada namanya Release Policy, ada 3 macam release policy:

  • Major Release: kek dari Windows 8.1 ke Windows 10 (replaces the old one with new one)
  • Minor Release: kek dari Windows 8.0 ke 8.1 (biasanya bug fixes)
  • Emergency Release: kaitannya dengan security patches (paling banyak security patches-nya tuh kayak Windows XP)

Untuk bisa service transition kita running smoothly, berarti kita akan sering2 melihat SDP (Service design package) lifecycle yang kita punya, karena disitulah dijelaskan bagaimana sebuah proses berjalan didalam service, bagaimana update sebuah service, bagaimana upgrade sebuah service, dll.

Tools2 dari SKMS (Service Knowledge Management System) akan sangat membantu kita mengambil keputusan…singkat kata, SKMS = database/guideline/model/document dari configurasi, policy, services2 yang kita punya…tentunya harus up-to-date

Setelah kita tau SDP kita dan dibantu dengan SKMS yang kita punya, maka kita perlu membuat kriteria2 apa saja alias parameter2 apa saja yang mengindikasikan bahwa transisi service berjalan sukses, in ITIL this called SAC (Service Acceptance Criteria)

Dari SAC ini baru kita bahas bagaimana caranya kita bisa move our transition softly/smoothly by managing change…or Change Management

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

Change Management

“To control the lifecycle of all Changes. The primary objective of Change Management is to enable beneficial Changes to be made, with minimum disruption to IT services.” (ITIL Service Transition book page 61)

Translate: melakukan perubahan yang menguntungkan dengan seminimum mungkin distrupsi

Untuk bisa mengontrol perubahan, kita perlu CAB (change advisory board) alias the group of people who responsible of making changes, who? The Sr. Management of course…masa gw yang IT support biasa yang responsible?!, bahkan klo memang bener2 mendesak kita bisa membentuk suatu emergency CAB alias ECAB

Look at that picture above…seenaknya maen ganti2 config..siapa yang mau tanggung jawab? Pasti lepas tangan semua…we must build some kind of management of change

Trus bagaimana klo kita sudah ga bisa lagi ngutak-ngatik kerjaan kita? Request for change (RFC)…biasanya kita bikin trouble ticket ke atasan (CAB) untuk di approve, klo perlu kita usulin untuk diganti…missal kek Windows 98 komputer diganti aja…”seeed jadul bets” (Change Proposal)

RFC di ITIL beda dengan IETF RFC yah wkwkw

Change model:

  • Normal Change – perubahan yang mesti ngikutin semua proses untuk bisa berubah (bikin trouble ticket dulu, di-review dulu, di-approve dulu, baru de di jalanin)
  • Standard Change – biasanya pre-approve kek work instruction/instruksi2 kerja…udah dari awal di authorize, kek mouse error, kan pasti langsung diganti…beda lagi klo network error, langsung diganti??? Berabe…biasanya sesuai job task nya, klo ga ada kewenangan untuk merubah sesuatu..ya ga bisa, masuknya ke normal change
  • Emergency Change – security patches biasanya, ASAP – as soon as possible

Yang namanya change management juga memikirkan bagaimana dengan Remediation Planning-nya, klo orang SI bilangnya…klo error, rollback nya gimana? Trus pastikan perubahan2 itu di record (Change Record)

Nah, perubahan itu harus dicatat untuk kepentingan kedepannya, jadi jgn sampe ada incident yang terulang terus menerus, we must have knowledge to face some situation…in ITIL this called Knowledge Management

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

Knowledge Management

“To gather, analyze, store and share knowledge and information within an organization. The primary purpose of Knowledge Management is to improve efficiency by reducing the need to rediscover knowledge.” (ITIL Service Transition book page 181-182)

Translation: mengurangi pencarian knowledge terus menerus untuk hal yang sama demi meningkatkan efisiensi, dengan cara membuat database tentang knowledge, sharing knowledge, dan analisis knowledge

Knowledge Management intinya adalah:

  • user, service desk, support staff, and supplier understanding of new or changed service
  • awareness of the use of the service and the discontinuation of previous versions – EOL (end of life) or EOS (end of support)
  • establishment of the acceptable risk and confidence levels associated with transition

ada 4 proses dalam knowledge management yang dinamakan DIKW chart

  1. Data – raw fact, just news…berita2 mentah
  2. Information – data yang sudah dioleh akan menjadi informasi (yang berharga untuk organisasi tentunya)…disini tempatnya what, where, who, dan when
  3. Knowledge – dari informasi2 tersebut…how we utilize them, experience/ideas/values
  4. Wisdom – why we must use the knowledge, its all about correct decision

Data2 yang seperti apa? Dimana kita bisa dapet data2 itu? Siapa yang punya itu? Kapan kita dapet itu data…disinilah data2 mentah dioleh menjadi informasi

Lalu bagaimana kita bisa mempergunakan informasi2 tersebut…this is called knowledge, dan terakhir kenapa kita harus pake knowledge ini? This is called Wisdom

Untuk mengolah Information menjadi Knowledge maka kita memerlukan SKMS (Service Knowledge Management System), a tools and database for knowledge, yang salah satunya adalah mengatur SIAPA dan BISA APA

  • SKMS – Staff, Experience, Abilities, Suppliers…intinya SIAPA dan BISA APA, SKMS ini juga mengatur tentang user education/training…buat apa? Ya biar bisa SIAPA dan BISA APA…wkwkw
    • CMS (Configuration Management System) – database konfigurasi, SKMS juga mengatur CMS ini baik KEDB ataupun Configuration DB itu sendiri (CMDB)
      • KEDB (Known Error DB) – CMS yang bagus punya DB tentang error (klo kita ngetik IP dengan network yang sama di router…pasti tulisannya “IP overlap”, itu tanda bahwa router punya KEDB)
      • CMDB (Configuration Management DB) – database konfigurasi

Setelah kita tau staff apa, bisa apa, pengalamannya sampai mana…artinya kita tau mana yang bisa dijadikan asset untuk organisasi/perusahaan untuk kepentingan transisi, artinya kita harus mengatur juga tentang Service Asset and Configuration Management

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

Service Asset and Configuration Management (SACM)

“To ensure that the assets required to deliver services are properly controlled, and that accurate and reliable information about those assets is available when and where it is needed” (ITIL Service Transition book page 89-90)

Translation: maintain informasi tentang asset (termasuk CI – configuration item) yang dibutuhkan untuk men-deliver IT Services, dan pastinya itu asset harus tersedia ketika dibutuhkan

Terminologi2 yang harus kita tau berkisar Service Assets and Configuration Management (SACM):

  • Service Asset – any resources (tangible) or capabilities (intangible) that Service Provider have
  • CI (Configuration item) – any service asset yang perlu di manage, yang dimanage oleh CMDB
  • Attribute – version number, HDD Space, cost, etc.
  • CI Type – Hardware kah, software kah, atau document?
  • Component – anything to make process of service works
  • Configuration Baseline – standar konfigurasi…simple nya, klo error…rollback kesini
  • Relationship – Service asset ini terhubung dengan proses/service apa
  • Verification – pastinya setiap kita konfigurasi harus di verifikasi biar ga error atau logic traffic path nya ga salah (in network)

SACM ini ada lifecycle-nya:

  • Planning – what scope or type of service asset and configuration will be (intangible or tangible)
  • Identification – inventarisasi
  • Control – authorize which CI can be manage by whom
  • Accounting – Reporting-nya
  • Verification and Audit – ya di verifikasi…abis itu…planning lagi de asset2 lainnya

Nah, ketika kita udah define service asset, knowledge-nya udah punya…sekarang saatnya kita release and deploy ini service yang sudah ada PERUBAHAN (change) ke fase Service Operation (operasional state)

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

Release and Deployment Management

“To plan, schedule, and control the build, test, and deployment of releases. To deliver new functionality required by the business while protecting the integrity of existing services” (ITIL Service Transition book page 114)

Translation: memberikan fitur/fungsi (enhance) baru ke service yang sedang berjalan tanpa mengganggunya atau merubah inti dari servis itu sendiri, tentunya fungsi tersebut harus sesuai dari segi bisnis

Terminologi2 penting:

  • Deployment: aktifitas yang bertanggung jawab atas pergantian (changes) dalam live environment (lingkungan operasional yang sedang berjalan)
  • Release: Service yang sudah ditest perubahan2nya
  • Release Unit: komponen2 dari service yang biasanya bundled (di rilis bersamaan)
  • Release Package: beberapa Service yang dirilis bersamaan
  • Release Record: dokumentasi tentang release
  • Build: version of the packages, such as Windows 8.1 build 7000
  • DML (Definitive Media Library): locations of the authorized version of all the software configuration item (biasanya di hard disk)

Biasanya kita punya Release policy dari Service Validation and testing sebelum di Release and Deploy

Contohnya:

  • Release Package 1: New Service QoS (HTTP and VoIP are guaranteed delivery)
  • Release Package 2: New Service Security (authorized user can access authorized file)
  • …
  • In the end, POS (Point-of-Sale) Update: Service yg include QoS, Security, etc.

Sistem release ini bisa parallel atau kek ITIL:

Planning > build & test with DML library > Deployment > Review and Close

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

References:

ITIL cbt nugget video by Chris Ward