The Next Step from Service Design, Service Transition

“saatnya launching menu baru ke pelanggan…NasGor”

“DaCen kita udah siap dan ready untuk dipake nih”

Inti dari Service Transition adalah bagaimana kita launching IT service kita semulus mungkin

Nah, dalam fase Service Transition ini ada 8 hal yang harus diperhatikan

  • Change Management
  • Change Evaluation
  • Project Management (Transition Planning and Support)
  • Application Development
  • Release and Development Management
  • Service Validation and Testing
  • Service Asset and Configuration Management
  • Knowledge Management

Kita akan bahas satu persatu

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

Change Management

“kata pelanggan, NasGor yang kemaren nasinya lebih enak dari yang sekarang, siapa ini yang ganti jenis beras?”

“kemaren gue akses DaCen mulus2 aja, abis diganti konfig network kok jadi lemot ya?”

Inti dari change management adalah untuk mengontrol perubahan2 atau request terhadap service agar tidak terjadi gangguan kinerja pada service itu sendiri

Request2 yang membutuhkan modifikasi terhadap service disebut Request for Change (RFC)

Ada beberapa hal yang diatur dalam Change Management

  • Change Management Support: bikin dokumen/template klo ada yang request modifikasi service
    • Change Manager (yang bertugas di Change Management) bisa mendapat masukan dari Change Advisory Board (CAB)
  • Assessment of Change Proposals: assessment dari proposal yang dibuat pada Service Strategy phase (service portfolio), layaknya suatu service yang lagi berjalan ini diganti atau di non-aktifkan
  • RFC Logging and Review: filter RFC-RFC mana yang kira2 ga penting
  • Assessment and Implementation of Emergency Changes: klo sewaktu2 service ini harus berubah secara mendadak (emergency), maka perlu perhatian dan penilaian khusus
    • Klo perlu dibentuk juga ECAB (emergency CAB)
  • Change Assessment by the Change Manager: menilai RFC2 mana yang butuh appropriate action, karena change urgency ada 3 tahap
    • Standard Change: pergantian yang ga perlu ada notif ke CAB, contoh: pergantian password secara berkala (standard = procedural)
    • Normal Change: harus ada pre-approval, contoh request penambahan bandwidth
    • Emergency Change: biasanya ini security patches, ASAP (as soon as possible)
  • Change Assessment by the CAB: untuk menilai proposal perubahan yang disodorkan, biasanya Major Changes yang dinilai disini, kek siapa yang ter-autorisasi untuk apa
  • Change Scheduling and Build Authorization: meng-otorisasi perubahan
  • Change Deployment Authorization: untuk ngeliat apakah semua komponen untuk perubahan sudah ready dan di tes
  • Minor Change Deployment: list perubahan apa saja yang ga perlu ada review2an apalagi rapat2an
  • Post Implementation Review: review…apakah perubahan/change tersebut sesuai ekspektasi apa engga, trus ada dokumentasi buat future reference klo2 ada kasus serupa (change record)

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

Change Evaluation

“yuk, launching Menu NasGor di café kita, nanti kita liat bulan depan…animo pelanggan naik apa turun?”

“service DaCen sudah siap di launching nih, kita liat service ini dibulan depan ngefek ga”

Inti dari Change Evaluation adalah untuk menilai Major Changes alias perubahan2 besar pada service itu tetep dilaksanakan apa engga, baik itu new service ataupun modifikasi service lama (bukan yang minor2)

New topic in 2011, hasil dari Change evaluation itu di dokumentasikan di Change Evaluation Report (buat Post Implementation Review)

Ada 4 hal yang dibahas di Change Evaluation:

  • Change Evaluation prior to Planning: membahas perubahan2 major sebelum service ini direncanakan untuk launching

    “eh, kek nya kita butuh variasi NasGor deh, masa jualan NasGor tok…“

  • Change Evaluation prior to Build: membahas perubahan2 major saat mau dibuat (planning sudah selesai)

    “kek nya NasGor yang laku Cuma NasGor Pete sama NasGor special, yang laen ga usah de“

  • Change Evaluation prior to Deployment: membahas perubahan2 major sebelum service berjalan

    “kek nya café sebelah NasGor-nya ada 5 variasi menu de, berarti harus cari variasi NasGor lain selain pete dan spesial“

  • Change Evaluation after Deployment: membahas perubahan2 major pas service sudah sedang berjalan

    “ok, seharian ini, yang request NasGor ada 10 pelanggan yang dateng, cuma 3 yang request NasGor, ada yang perlu ditambahin ga biar banyak yg request nasgor untuk besok2?”

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

Project Management (Transition Planning and Support)

“ok, sekarang panggil koki, siapin alat2 masak, pastikan bumbu2 dapur siap sebelum bikin NasGor…udah mau launching nih”

“make sure network connection is stable, hardware is ready, and everything goes according as planned”

Inti dari Project Management adalah merencanakan dan memastikan semua resources siap untuk melaksanakan service sesuai dengan biaya, waktu, dan kualitas yang diharapkan

Disinilah tim management IT merancang Release Policy (setiap service harus ada “version number”nya)

  • Major Release: kek dari Windows 8 ke Windows 10
  • Minor Release: kek Windows 8.0 ke 8.1 (semacam service pack)
  • Emergency Release: ini kek Windows Update untuk nambalin security hole (security patches)

Release policy ini akan ber-impact di Proses Release and Deployment Management

Ada 4 hal yang dibahas ditahap ini

  • Project Initiation: menentukan siapa aja stakeholder project, responsibilitas-nya, dan resource2 yang dibutuhkan oleh project plus resiko2 yang bisa menghambat project
  • Project Planning and Coordination: membuat guideline biar project ga keluar dari jalur yang sudah dibuat
  • Project Control: monitoring project progress dan konsumsi resource, jadi bisa melakukan tindakan korektif jika diperlukan
  • Project Reporting and Communication: membuat dokumentasi semua project yang sedang dan akan direncanakan ke customer sebagai informasi

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

Application Development

“karena kita udah mau jualan NasGor, kita perlu upgrade list menu dan harga di database komputer”

“applikasi2 mana aja yang server-nya kita pindahin ke DaCen, trus modifikasi/perubahan apa untuk software-nya?”

Inti dari Application Development (and Customization) adalah gimana caranya applikasi punya kita bisa menyesuaikan diri dengan service baru kita…dah gitu aja

Jgn sampe kita jualan NasGor, tapi pas pelanggan mau bayar…eh menu nasgor-nya ga ada di layer komputer kasir (gimana mo bayar? harga menu-nya ga ada)

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

Release and Deployment Management

“kita akan bikin NasGor biasa dulu…klo animo pelanggan naik, baru coba menu2 variatif lain”

“kita akan provide service ke customer untuk storage di DaCen, namanya Cloud Storage Anywhere v1.0”

Inti dari Release and Development Management adalah bikin versi dari menu kita…versi alpha, beta, dll

Release: service2 yang sudah di test dan direview sebelumnya, contoh:

  • Release Package 1: 1GB of storage services
  • Release Pakacge 2: added 100mb free of email storage in different storage
  • Release Package 3: added storage encryption for security purpose
  • Dan seterusnya…

Release Unit: komponen2 dari service yang di lepaskan secara bersamaan (bundled), contoh: Free 100mb email when activating DaCen Storage services, biasanya ada Definitive Media Library (DML) -nya

  • DML: licenses, software configuration, etc. (dibahas di Service Asset dan Configuration)

Release Record: detail2 yang di dokumentasikan saat service ini di planning sampai di release

Release Policy: kesepakatan/aturan2 tentang cara2 yang harus dipenuhi sebelum service ini di release

  1. What is the Release Level of this Service? (Major, Minor, or Emergency Releases)
  2. What Approach to Release this service Deployment

    • Big Bang or Phased: langsung nyebar apa bertahap
    • Push or Pull: server nge-push update ke PC kita atau kita ngambil ke server
    • Automated or Manual: auto update apa manual
  3. What Constrains for release deployment (what type of SLA we want to have, what pre-requisites components before the services can run, TESTING PHASE)

Deployment: aktifitas yang bertanggungjawab untuk perubahan2/pergantian service yang sedang berjalan

Ada beberapa hal yang menjadi sub-topik pada Release and Deployment Management

  • Release Management Support: bikin guideline dan support untuk Service yang akan di release
  • Release Planning: untuk membuat perubahan2 yang ter-otorisasi menjadi Release Package
  • Release Build: memastikan semua release unit/components siap untuk testing phase, contoh: Windows 8.1 build 7000
  • Release Deployment: abis testing phase, siap untuk dilepas ke live production, topik ini juga mengatur bagaimana men-training user untuk bisa memakai service yang akan diluncurkan
  • Early Life Support: untuk mencari solusi/fixing problem pas awal2 service ini di launch (salah satunya klo ada bug/error)
  • Release Closure: memastikan bahwa content yang dibawa service itu up-to-date dan secara formal menutup fase transisi dari service yang sedang uji coba untuk menjadi fase operational (bukan alpha atau beta phase lagi)

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

Service Asset and Configuration Management

“kita butuh inventarisasi apa aja yang bikin NasGor ini berjalan…staff-nya, bumbu-nya, alat masak-nya”

“kita butuh dokumentasi tentang DaCen kita nih, dari hardware-nya, software-nya, sampe konfig2-nya”

Inti dari Service Asset and Configuration Management adalah memaintain seluruh Configuration Item (CI) yang dibutuhkan untuk menjalankan IT service, termasuk hubungan2 antar CI tersebut

Configuration Item (CI): semua hal yang bisa membuat service IT jalan, contoh: policy, project dokumentasi, staff, supplier. CI ini di collect oleh tools yang ITIL sebut CMS (Configuration Management System)

Service Asset: semua resources dan kapabilitas yang service provider miliki

  • Tangible Asset: semua asset yang punya bentuk fisik (duit, hardware, staff, dll)
  • Intangible Asset: lawannya tangible (ilmu, brand recognition, trademark, dll)

CMS (Configuration Management System): tools for collecting, storing, managing, updating, analyzing, and presenting CI, their relationship, and their attribute (contohnya klo buat bandwidth kek solarwind, cacti, dkk. Klo buat database kek Oracle, dkk)

Contoh Relationship between CI

  • “Is a component of“: untuk hak akses VPN ke DaCen maka harus ada 2 hal yang di input: user, password atau PIN
  • “Is associated with“: user A dimasukkan ke Admin Group di ActiveDir, user B dimasukkan ke Operator Group
  • “Uses“: semua akses ke Server menggunakan centralized user management (AAA Server)
  • “Is a new version of“: Desktop OS akan di-upgrade jadi Windows 10
  • “Will be replaced by“: contohnya Windows Hyper-V akan di replace sama ESXi

Attribute: semua informasi yang berkenaan dengan suatu dokumen/file, contoh: version number, HDD Space, cost, dll.

database dari CMS ini disebut CMDB (Configuration Management Database), Bahasa ITIL untuk data warehouses (database staff IT ada sendiri, database ERP ada sendiri, database storage ada sendiri)

CI ini di simpan/di store dan di protect di secure logical library yang disebut DML (ya lu bisa bilang ini bahasa ITIL-nya untuk partisi)

DML ini klo fisik-nya naro dimana? Ya di storage lah, kek DVD, CD, Harddisk, dll

Yang dibahas dalam Asset and Configuration Management adalah

  • Configuration Identification: mengidentifikasikan setiap CI dan relationship antar CI
  • Configuration Control: siapa yang bisa ganti konfig setiap CI
  • Configuration Verification and Audit: regular checking, memastikan semua informasi di CMS

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

Service Validation and Testing

“kita bikin NasGor, diskon 50% dulu yuk untuk 100 pelanggan pertama, kita liat reaksi mereka abis makan NasGor kita”

“kita tes dulu selama 1 bulan service DaCen-nya, kira2 ada problem ga selama sebulan itu”

Inti dari Service Validation and Testing adalah supaya Service yang telah di launching meet customer expectation, plus tim IT bisa support service baru ini ga

Yang termasuk dalam Service Validation and Testing adalah

  • Test Model Definition: membahas detail bagaimana service di test dan quality assurance-nya gimana, SLA-nya gimana
  • Release Component Acquisition: semua komponen2 yang bikin service ini jalan harus dinilai, layak tidakya ini komponen ini masuk kedalamnya
  • Release Test: ya nge-test service
  • Service Acceptance Testing: nge-cek sesuai ga service baru ini dimata customer (SLA acceptance testing)

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

Knowledge Management

“kemaren itu café sebelah bikin NasGor sukses ga sih?, klo kita bikin juga kira2 gimana?”

“tolong cari di perusahaan mana saja DaCen diimplementasi? Apa aja yang dialami?”

Inti dari Knowledge Management adalah menyamakan informasi yang didapat terhadap suatu service yang digunakan, agar bisa menentukan suatu visi dan misi terhadap service yang sedang di launching ini dan juga supaya engga keluar service2 selanjutnya yang serupa, soalnya uda pernah ada sebelumnya

untuk memahami Knowledge Management biasanya dibuatin DIKW Chart seperti ini:

  • Data: semua fakta2 dilapangan
  • Information: semua data2 yang berguna (who, what, whom, where)
  • Knowledge: hasil dari informasi2 yang telah diolah (how)
  • Wisdom: knowledge alias pengetahuan ini dijadikan experience and decisions (why)

Dari DATA, INFORMATION, sampai KNOWLEDGE itu bisa di “generate” pake tools alias software2 (yaitu…CMS)

Tapi tools2 tersebut tidak bisa menggenerate Wisdom, kenapa? Karena ini berkaitan dengan keputusan2 yang diambil, terutama yang berkaitan dengan visi misi

Nah, tempat repository CMS-CMS itu dalam ITIL disebut SKMS (Service Knowledge Management System)…SKMS juga ga harus di satu/single sistem…bisa replikasi/mirroring/federated system/etc.

——–

Next…Service Operation Overview