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

February 21, 2017

Miftah Rahman Other Stuff , , , , , , , , , , , , , , , , , , , , , , , , , , , 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

Older Entries