“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