Home

ITIL Service Transition Overview

Leave a comment

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

Advertisements

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

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

Termasuk menganalisa value dari assets2 bisnis perusahaan, ancaman2nya, seberapa vulnerable-nya asset2 itu

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/

Older Entries