Home

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

ITIL Service Transition Overview

September 7, 2015

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