Home

IT Service Management (ITIL Introduction)

2 Comments

Muqaddimah

Wkwkwk…(sekali2 pake bahasa arab gpp lah ya)

Kita (terutama gue) selalu treat network itu selalu melulu berurusan dengan bagaimana cara konfig-nya?, bagaimana cara desain network yang baiknya?, ataupun bagaimana sekuriti-nya?

Kita jarang berfikir bagaimana network (atau IT secara keseluruhan) bisa menunjang proses bisnis…bisa ga network ini bikin company makin responsive? Bisa ga sistem IT yg kita terapkan bikin profit perusahaan nambah? Perlu ga kita menerapkan IT Security secara menyeluruh di departement tertentu? Etc.

Pernah kan kita mendengar (atau malah merasakan sendiri) ketika perusahaan ingin membuat IT service baru (contoh bikin Data Center) trus BoD (Board of Director)nya ga jelas mau seperti apa DaCen-nya, Budget-nya ga nyampe, IT maen asal suggest/saran aja…ga nyambung blas…

Karena…bagi bisnis (kebanyakan), IT dipandang sebagai “helper” alias Services untuk membantu mereka…nah, bagaimana cara “membantu” mereka…atau ilmu apa yang bisa kita pelajari untuk meningkatkan Services kita…ilmu tersebut dinamakan ITSM (IT Service Management)

Salah satu dari ITSM adalah ITIL (IT Infrastructure Library)

ITIL adalah suatu cabang ilmu ITSM yang mempelajari bagaimana cara “menyelaraskan” IT services dengan keinginan Business (perspektif bisnis)

Gua akan coba bahas ITIL dari 2 sisi, analogical (mau buka Café misalkan) sama sisi technical (mau bikin Data Center) untuk artikel2 berikutnya

—————————–

ITIL Introduction

Ada macem2 learning course untuk IT Governance/Management

  • COSO (committee of sponsoring organization)
  • CobIT (Control objective for IT)
  • ISO-int’l Standard Organization (9000 – untuk Quality Assurance, 27001 – untuk InfoSec)
  • ITIL, inilah course track yg fokus kepada ITSM

Trus bedanya apa? cek gambar dibawah

Klo pengen belajar IT dari kacamata bisnis…lu bisa ambil COSO

Klo pengen belajar standarisasi perusahaan, lu bisa belajar ISO

Klo pengen belajar IT Management, belajarlah CobIT

Klo pengen belajar bagaimana menjalankan IT Service Process yg baik dan benar…ITIL

Nah, karena ITIL bukan standard…makanya ga ada tuh logo perusahaan trus ada logo ITIL-nya (ga kek ISO), karena ITIL adalah Framework alias best practices

Jadi bisa adopt and adapt…alias ada beberapa komponen dari ITIL yg dipandang kurang perlu bisa dibuang (ga kek ISO)

ITIL ini dibentuk di UK oleh OGC tahun 80an, klo mau exam di handle sama EXIN

ada 4 factor dalam ITSM

  • People…orang yang melaksanakan IT
  • Products…di ITIL dinamakan “service
  • Processes…bagaimana product/service ini bekerja
  • Partners…siapa aja yang bantu kita dalam melaksanakan IT

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

ITIL Service Lifecycle

Nah, ini INTI-nya ITIL…ITIL memandang bahwa suatu Service (IT Service tentunya) harus punya “masa hidup” alias lifecycle….lifecycle untuk improvement

Btw..apa itu Service? means to deliver value to customer by facilitating outcome that the customer want to achieve without the ownership of cost and risk (ITIL Service Strategy Book pg.13)

Bahasa mudahnya…”bagaimana cara bikin IT kita itu berharga (punya value) buat customer

Kita (sebagai pekerja IT) melayani Customer…kita disebut Service Provider (penyedia layanan)

dan pemakai service kita disebut Customer

Dan apa itu lifecycle-nya? Cek gambar ini

Jadi…ITIL itu terdiri dari 5 fase

Karena ITIL ini best practice…lo bisa mulai dari mana aja, klo blum ada IT service mungkin dari fase strategy, tapi klo sudah ada bisa langsung mulai dari Service Transition atau Operation

Apa aja sih yang dibahas di fase2 tersbut….gw akan briefly bahas satu2 (detail-nya di artikel2 selanjutnya)

———————————

Service Strategy

eh direktur mau kita bikin Data Center sendiri nih…

Dalam ITIL, “bikin data center sendiri” disebut new service, karena dari kalimat tersebut service data center sebelumnya belum ada (atau masi shared sama company lain)

Nah, Service Strategy membahas gimana caranya new service ini punya value (berguna) TITIK

Untuk melihat Value, kita harus melihat 2 hal mendasar:

  • Utility: bisa ga kita menyediakan service tsb. (gedungnya, alatnya, dll)
  • Warranty: seberapa baik service ini bisa dilaksanakan (security, availability, dll)

Point2 yg dibahas di bagian ini adalah:

  1. Strategy Management: asessment dari service yang kita tawarkan, kompetitor2 kita, dll
  2. Service Portfolio Management: list services2 yang kita punya (dulu/retired, sekarang/current, nanti/future)
  3. Financial Management: simple…lu punya duit kaga buat funding ini service baru
  4. Business Relationship Management: new service ini “ngelayanin” siapa? Internal? External? Apa shared?
  5. Demand Management: siapa yang akan pake layanan kita?

————————-

Service Design

ok, fix…budget sama demand udah masuk…sekarang gimana caranya biar Data Center ini sesuai dengan apa yang diinginkan stakeholder

Di fase inilah kita menentukan SLA (service level agreement), untuk menentukan kadar kepuasan customer terhadap layanan baru kita yang nanti mau di launching

Apa aja yang dibahas dalam fase design:

  1. Supplier Management: 3rd party vendor, bahas kontrak kerja
  2. Service Level Management: bahas SLA
  3. Service Catalogue Management: list IT services yang kita sedang support dan jalankan (termasuk DaCen yang akan/yang mau kita bangun)
  4. Availability Management: membahas failover gimana, fallover gimana, redundancy-nya gimana, klo downtime gimana
  5. Capacity Management: tiap department dapet storage berapa giga?bandwidthnya?
  6. InfoSec Management: IT Security policy
  7. Design Coordination Management: membahas klo ada perubahan2 desain

————————–

Service Transition

saatnya kita implementasi…versi alpha dulu, apa langsung beta nih?

Di fase ini kita mulai deploy semua yg sudah ada di design, ada bbrp hal yang dibahas:

  1. Transition Planning and Support: mau release bertahap? Apa mau langsung semua?
  2. Change Management: memastikan semua perubahan tercatat dan mencegah agar tidak semua orang bisa melakukan “change”
  3. Knowledge Management: memastikan semua orang “well-informed” terhadap new service kita, siapa yang buat data, siapa atau software apa yang ngolah data, dll…
  4. Service Asset and Configuration: memastikan bahwa service yang baru berjalan dapat memakai aset2/resource yang dibutuhkan
  5. Release and Deployment Management: Service kita harus ada version-nya. versi 1.0, versi 1.1, versi 2.0 biar terus2 menerus di revisi dan dikembangkan
  6. Change Evaluation: klo di tengah2 jalan pas deploy DaCen ada perubahan2 tertentu…masuk-nya kesini (layak ga itu berubah, di modif, di delete, dll)
  7. Service Evaluation and Testing: ya testing, PoC..proof of concept

———————–

Service Operation

ok…saatnya kita maintain DaCen, kita duduk manis dan diam………sambil menunggu ada complain yang datang

Jadi klo ada incident gimana? Klo ada problem gimana? Klo ada request services baru gimana? Semua hal yang terjadi pas kita lagi maintain IT kita

Contoh: gue butuh storage lebih dong, masa cuma dikasi 5 giga, file departemen gue banyak nih…gue butuh bandwidth lebih dong, attachment gue gede2 nih

  1. Event Management: memonitor all services
  2. Incident Management: mencari cara IT services bisa digunakan lagi oleh customer ketika ada incident
  3. Request Fulfilment: membentuk semacam kanal/corong supaya service tersebut bisa di-request
  4. Access Management: authorisasi (identity management)
  5. Problem Management: minimize impact IT down time gara2 incident (lebih parah dari incident)
  6. IT Operation Control: tugas2 rutin, job scheduling, backup/restore, dll
  7. Facilities Management: management fisik, dimana DaCen dibangun, power plantnya gimana, lingkungannya gimana, dll
  8. Application Management: manajemen aplikasi/software
  9. Technical Management: klo error, gw harus ngomong kesiapa? Yg jago ngerjain ini siapa?

———————–

Continual Service Improvement

Data Center kita udah running well, ada lagi ga ya yang bisa kita improve?”

CSI ini di adopsi ITIL dari ISO 20000 (ITSM-nya ISO)

Inti dari CSI adalah:

  1. Service Review: secara berkala, service harus di review
  2. Process Evaluation: evaluasi secara berkala untuk masing2 unit kerja
  3. Definition of CSI Initiatives: menentukan secara spesifik, inisiatif2 apa aja yang perlu
  4. Monitoring of CSI Initiatives: verifikasi inisiatif2 yg sudah dilakukan sesuai dengan rencana apa tidak

————————

Another Terminology

dalam ITIL ada bbrp terminology yang patut kita ketahui (sring disebut2 soalnya)

  • Process: sekumpulan aktifitas yang menghasilkan sesuatu -> Value pastinya
  • Process Owner: orang yang bertanggung jawab atas proses, dan tentunya “accountable”
  • Function: team of people and tools/activities a.k.a job desk
  • RACI Model: responsible, accountable, consult, inform…semacam tabel untuk nge-cek job-role ini di ITIL fungsi-nya apa

contoh: Network Oper. Control-NOC (ini function), kerjanya monitoring, reporting, dan basic troubleshooting (ini process), NOC ini mempekerjakan orang dengan tools yang disediakan (Process Owner)

Contoh dalam RACI:

  • NOC person, ini sifatnya “R” karena dia yang melakukan process
  • IT Manager, ini sifatnya “A” karena klo ada apa2 yang “ditunjuk” (accountable) adalah dia
  • CIO, ini sifat “C” karena sifatnya memberikan arahan dan visi misi IT Strategic
  • BoD, ini sifatnya “I” karena klo ada apa2 mereka cukup dikasih tau aja (ada maintenance server, mereka cukup di inform pake email)

————————

References:

bukunya ITIL, beli (mesen) sendiri ya (1 Service = 1 buku sendiri)

itil

https://www.bitsighttech.com/blog/cobit-vs-itil

http://www3.pinkelephant.com/ressource/pinklink/pdf/itil_v3_concepts_made_easy_part_4.pdf

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

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

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

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

http://www.bmc.com/guides/itil-continual-service-improvement.html

ITIL Service Transition Overview

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. Wisdomwhy 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

Older Entries