Layanan Dukungan & Operasi

4.1 Ikhtisar

Bagian ini menetapkan kerangka dukungan operasional yang digunakan Provider untuk menyampaikan layanan dukungan harian bagi Platform. Bagian ini menetapkan struktur, proses, dan tanggung jawab untuk manajemen insiden, manajemen siklus hidup tiket, pemeliharaan preventif, eskalasi teknis, dan pengendalian perubahan operasional.

Seluruh proses dukungan selaras dengan pedoman best practice ITIL 4 dan memanfaatkan model dukungan omnichannel milik Provider untuk memastikan penyampaian layanan yang cepat, dapat ditelusuri, dan kaya konteks di seluruh saluran komunikasi.

Layanan dukungan berlaku untuk Production Environment dan, jika secara tegas disepakati dalam Commercial Contract, untuk Staging Environment. Provider harus memelihara prosedur dukungan yang terdokumentasi dan menyediakannya kepada Customer atas permintaan yang wajar. Seluruh aktivitas dukungan dicatat dan dilacak melalui embedded ticketing system milik Platform, memberikan visibilitas menyeluruh bagi Provider dan Customer.

4.2 Provider Service Desk (PSD)

Provider Service Desk (PSD) adalah titik kontak tunggal untuk mencatat, mengelola, dan menyelesaikan seluruh tiket dukungan teknis, termasuk Incident, Service Request, Problem, dan Change Request yang diajukan oleh Customer. PSD menjalankan model dukungan omnichannel yang menyatukan ticketing formal, pesan waktu nyata, dan saluran komunikasi tradisional ke dalam satu alur kerja dukungan yang dapat ditelusuri. PSD berkoordinasi dengan IT liaison yang ditunjuk Customer untuk seluruh layanan dukungan dan pemeliharaan.

4.2.1 Embedded Ticketing System

Platform mencakup sistem ticketing embedded native di dalam aplikasi ProjectVIEW ERP itu sendiri. Kapabilitas ITSM terintegrasi ini memungkinkan Pengguna yang Berwenang untuk membuat, melacak, dan mengelola tiket dukungan secara langsung dari dalam Platform tanpa meninggalkan lingkungan ERP. Sistem ticketing embedded ini menyediakan:

• (a) Pencatatan Tiket di Dalam Aplikasi: Pengguna membuat tiket secara langsung di antarmuka ProjectVIEW ERP, dengan penangkapan otomatis informasi kontekstual termasuk modul aktif, layar, peran pengguna, dan setiap catatan data terkait;
• (b) Pelacakan Status Secara Real-Time: Dasbor terpadu di dalam ERP menampilkan semua tiket yang terbuka, sedang diproses, dan telah diselesaikan dengan visibilitas penuh atas siklus hidup, penghitung mundur SLA, dan indikator prioritas;
• (c) Komunikasi Dua Arah: Percakapan beruntun antara Customer dan engineer dukungan yang ditugaskan berlangsung di dalam tiket itu sendiri, menjaga jejak audit kronologis yang lengkap;
• (d) Pencatatan Lampiran & Bukti: Pengguna melampirkan tangkapan layar, log kesalahan, dokumen, dan rekaman layar langsung ke tiket, sehingga menghilangkan hilangnya konteks saat eskalasi;
• (e) Metrik & Pelaporan SLA: Pelacakan SLA bawaan dengan peringatan otomatis ketika target respons atau penyelesaian mendekati ambang batas, disertai pelaporan real-time atas volume tiket, kategori, dan kinerja penyelesaian;
• (f) Integrasi Basis Pengetahuan: Sistem ticketing terhubung ke basis pengetahuan tertanam milik Provider (wiki), menampilkan artikel yang relevan dan solusi yang sudah dikenal saat pembuatan tiket untuk memungkinkan penyelesaian mandiri;
• (g) Notifikasi Otomatis: Notifikasi email dan di dalam aplikasi dipicu pada setiap transisi status tiket (didaftarkan, diakui, ditugaskan, diperbarui, diselesaikan, ditutup), sehingga semua pemangku kepentingan tetap mendapat informasi.

Sistem ticketing embedded berfungsi sebagai system of record untuk seluruh interaksi dukungan. Terlepas dari saluran yang digunakan saat masalah pertama kali dilaporkan (telepon, email, WhatsApp, atau di dalam aplikasi), semua tiket harus diformalkan di dalam sistem ticketing embedded untuk memastikan pengukuran SLA, kemampuan audit, dan kepatuhan.

4.2.2 Saluran Dukungan Omnichannel

Provider wajib memberikan Customer akses ke PSD melalui saluran berikut:

4.2.3 Saluran Dukungan WhatsApp Business

Provider membentuk grup WhatsApp Business khusus untuk setiap Customer, yang menghubungkan pengguna kunci yang ditunjuk Customer dengan konsultan yang ditugaskan oleh Provider. Saluran ini berfungsi sebagai lapisan komunikasi informal yang cepat untuk melengkapi sistem ticketing formal. Saluran WhatsApp diatur oleh aturan berikut:

• (a) Ruang Lingkup: Pertanyaan singkat, panduan penggunaan, klarifikasi fungsi, diskusi informal atas potensi permintaan perubahan, dan pelaporan awal isu non-kritis. Saluran WhatsApp bukan pengganti pencatatan tiket formal;
• (b) Aturan Formalisasi: Setiap isu yang disampaikan melalui WhatsApp dan memerlukan pelacakan formal, pengukuran SLA, perubahan kode, modifikasi konfigurasi, atau eskalasi harus dicatat sebagai tiket di sistem ticketing embedded oleh konsultan Provider dalam waktu 4 jam sejak identifikasi. Customer akan diberi tahu referensi tiket;
• (c) Pengecualian SLA: Penghitung waktu respons dan penyelesaian SLA dimulai saat tiket diformalkan di sistem ticketing embedded, bukan saat komunikasi awal di WhatsApp;
• (d) Perlindungan Data: Para peserta tidak boleh membagikan Data Pribadi, kredensial, isi basis data, atau Informasi Rahasia melalui WhatsApp. Provider wajib memberikan pengarahan kepada seluruh peserta mengenai kewajiban penanganan data berdasarkan Undang-Undang Perlindungan Data yang berlaku (lihat Bagian 17);
• (e) Retensi: Pesan WhatsApp disimpan sesuai dengan kebijakan retensi data milik Provider. Demi tujuan auditability, setiap pembahasan teknis substansial atau keputusan yang dibuat melalui WhatsApp harus diringkas dalam catatan tiket yang sesuai;
• (f) Keanggotaan Grup: Keanggotaan grup dikelola bersama. Provider wajib memperbarui keanggotaan grup dalam 2 Hari Kerja setelah perubahan personel apa pun. Customer wajib memberitahukan Provider atas setiap perubahan pada pengguna kunci yang ditunjuk.

4.2.4 Jam Operasional & Ketersediaan PSD

PSD beroperasi 24 jam per hari, 7 hari per minggu, 365 hari per tahun untuk pencatatan tiket di semua saluran. Aktivitas penyelesaian mengikuti jendela operasional yang ditetapkan dalam SLA Response & Resolution Matrix (Bagian 3.6).

Hari libur nasional pemerintah UEA/Yunani/Filipina dikecualikan dari perhitungan Hari Kerja, tetapi insiden P1 tetap ditangani terlepas dari jadwal hari libur nasional.

4.2.5 Tanggung Jawab PSD

PSD wajib:

• (a) Mencatat semua insiden dan permintaan layanan yang dilaporkan Customer ke dalam sistem ticketing embedded, dengan memberikan nomor referensi tiket yang unik disertai penangkapan metadata kontekstual otomatis;
• (b) Menyetujui bersama Customer tingkat prioritas yang akan dialokasikan untuk setiap tiket sesuai dengan Klasifikasi Prioritas Insiden yang ditetapkan pada Bagian 3.5;
• (c) Memberikan konfirmasi penerimaan e-ticket kepada Customer setelah diterima;
• (d) Mengelola semua eskalasi yang diperlukan untuk memulihkan Layanan dalam target Service Level yang berlaku;
• (e) Memberikan kepada Customer pembaruan kemajuan secara berkala melalui sistem ticketing, telepon, email, atau WhatsApp pada interval yang disepakati bersama;
• (f) Memberi tahu Customer saat ticket diselesaikan, termasuk deskripsi singkat tentang akar penyebab, tindakan korektif yang dilakukan, serta apakah ticket akan ditutup atau memerlukan tindakan lebih lanjut;
• (g) Jika memungkinkan, terlebih dahulu mencoba menyelesaikan ticket secara jarak jauh. Jika penyelesaian jarak jauh tidak memungkinkan, Provider harus menugaskan engineer yang memenuhi syarat ke lokasi Customer sesuai kebutuhan;
• (h) Meresmikan setiap isu yang pada awalnya disampaikan melalui WhatsApp atau telepon ke dalam sistem ticketing tertanam dalam waktu 4 jam;
• (i) Menjaga jejak audit yang lengkap atas seluruh interaksi ticket, perubahan status, dan aktivitas penyelesaian dalam sistem ticketing tertanam.

4.3 Manajemen Siklus Hidup Tiket

Seluruh interaksi dukungan mengikuti siklus hidup tiket yang terstruktur dan dikelola melalui sistem ticketing embedded Platform untuk memastikan ketertelusuran, akuntabilitas, dan kepatuhan terhadap target SLA.

Siklus hidup ini berlaku untuk semua jenis tiket: Insiden, Permintaan Layanan, Problem, dan Permintaan Perubahan, terlepas dari saluran tempat isu tersebut pertama kali dilaporkan.

4.3.1 Pencatatan Tiket

Saat tiket dicatat oleh Customer, informasi minimum berikut wajib diberikan kepada PSD:

• (a) Nama Customer dan referensi kontrak ( terisi otomatis saat ticket dibuat melalui sistem ticketing tertanam);
• (b) Nama dan detail kontak orang yang melaporkan isu;
• (c) Uraian yang jelas tentang isu tersebut, termasuk langkah-langkah untuk mereproduksi (untuk insiden) atau sifat permintaan (untuk permintaan layanan);
• (d) Modul yang terdampak dan jumlah Authorised Users yang terpengaruh;
• (e) Setiap diagnostik, tangkapan layar, atau pesan error yang diperoleh Customer;
• (f) tingkat prioritas yang diusulkan oleh Customer untuk ticket tersebut.

4.3.2 Alur Kerja Pemrosesan Tiket

Prosedur berikut mendefinisikan metode pemrosesan tiket mulai dari pencatatan awal hingga penutupan:

Pembukaan Kembali Tiket: Jika Customer melaporkan bahwa isu yang sama berulang dalam 5 Hari Kerja setelah penutupan tiket, tiket asli harus dibuka kembali dengan klasifikasi prioritas yang sama di dalam sistem ticketing embedded. Tiket yang dibuka kembali dihitung sebagai satu insiden untuk tujuan pengukuran SLA.

4.3.3 Klasifikasi Tiket

Tiket diklasifikasikan ke dalam kategori berikut:

4.4 Eskalasi Teknis

Provider memelihara matriks eskalasi teknis yang terstruktur untuk memastikan bahwa tiket diekskalasi ke tingkat keahlian dan otoritas manajemen yang tepat apabila penyelesaian tidak tercapai dalam target Service Level yang berlaku atau apabila tingkat keparahan isu memerlukan intervensi pimpinan.

4.4.1 Tingkat Eskalasi

4.4.2 Eskalasi yang Diinisiasi Customer

Customer dapat mengekskalasi tiket kapan saja dengan menghubungi PSD dan meminta eskalasi. Provider wajib memperbarui Matriks Kontak Eskalasi setidaknya setahun sekali atau setiap kali terjadi perubahan personel, dan wajib memberikan matriks terkini kepada Customer dalam waktu 5 Hari Kerja sejak pembaruan apa pun. Matriks Kontak Eskalasi harus mencakup nama, jabatan, nomor kontak langsung, dan alamat email untuk setiap tingkat eskalasi.

Untuk insiden P1 (Kritis), Provider wajib secara otomatis mengekskalasi ke Level 2 dalam 30 menit jika respons awal belum mengidentifikasi jalur penyelesaian, dan ke Level 3 dalam 2 jam jika insiden masih belum terselesaikan. Penghubung IT yang ditunjuk Customer dan Service Delivery Manager wajib diberi tahu secara real time atas seluruh eskalasi P1.

4.5 Pemeliharaan Preventif

Provider wajib melakukan pemeliharaan preventif bulanan pada seluruh komponen Platform di dalam lingkungan private sovereign khusus milik Customer. Pemeliharaan preventif dilakukan secara proaktif untuk mengidentifikasi dan memperbaiki potensi masalah sebelum berdampak pada ketersediaan atau kinerja layanan.

4.5.1 Ruang Lingkup Pemeliharaan Preventif

Pemeliharaan preventif bulanan mencakup, namun tidak terbatas pada:

• (a) Pemeriksaan Kesehatan Infrastruktur: Pemantauan performa virtual machine, utilisasi disk, alokasi memori, analisis beban CPU, dan penilaian latensi jaringan;
• (b) Pemeliharaan Basis Data: Pembangunan ulang indeks, pembaruan statistik, pengelolaan transaction log, pemeriksaan integritas (DBCC CHECKDB), dan optimasi penyimpanan;
• (c) Patching Keamanan: Peninjauan dan penerapan patch keamanan sistem operasi, middleware, dan basis data sesuai kebijakan manajemen patch Provider (lihat Bagian 3.1.3 untuk maintenance window);
• (d) Verifikasi Backup: Validasi penyelesaian pekerjaan backup, pengujian integritas backup, dan pelaksanaan drill restore (triwulanan);
• (e) Kesehatan Aplikasi: Pemeriksaan fungsional tingkat modul, validasi endpoint API, pemantauan integrasi, dan peninjauan error log di seluruh modul ProjectVIEW ERP yang aktif;
• (f) Manajemen Sertifikat SSL/TLS: Pemantauan masa kedaluwarsa sertifikat, pembaruan, dan rotasi;
• (g) Tinjauan Kapasitas: Penilaian penggunaan sumber daya saat ini terhadap kapasitas yang disediakan, dengan rekomendasi scaling secara proaktif apabila utilisasi melebihi ambang 75%.

4.5.2 Pelaporan Pemeliharaan Preventif

Setelah setiap siklus pemeliharaan preventif selesai, engineer pemeliharaan milik Provider wajib menyerahkan Laporan Pemeliharaan Preventif kepada Customer dalam waktu 3 Hari Kerja. Laporan tersebut harus mencakup:

• Tanggal dan durasi aktivitas pemeliharaan;
  • Komponen yang diperiksa dan tindakan yang dilakukan;
  • Risiko atau anomali yang teridentifikasi beserta remediasi yang direkomendasikan;
  • Metrik utilisasi sumber daya saat ini dibandingkan dengan yang disediakan;
  • Jadwal patch dan pembaruan yang akan datang;
  • Konfirmasi hasil verifikasi backup.

4.6 Manajemen Perubahan

Semua modifikasi pada konfigurasi, fungsi, atau infrastruktur Platform diatur melalui proses formal Manajemen Perubahan yang dirancang untuk meminimalkan risiko terhadap Production Environment. Perubahan diklasifikasikan dan dikelola sesuai dengan praktik terbaik ITIL Change Management.

4.6.1 Klasifikasi Perubahan

4.6.2 Alur Kerja Manajemen Perubahan

Semua perubahan Normal dan Emergency mengikuti alur kerja ini:

• (a) Permintaan: Customer atau Provider mengajukan Change Request melalui PSD dengan deskripsi, justifikasi bisnis, modul yang terdampak, dan tanggal implementasi yang diminta;
• (b) Penilaian: Provider melakukan penilaian dampak yang mencakup: risiko teknis, pengguna yang terdampak, rencana rollback, perkiraan upaya, dan dependensi;
• (c) Persetujuan: Change Advisory Board (atau Service Delivery Manager untuk perubahan darurat) meninjau dan menyetujui atau menolak perubahan;
• (d) Implementasi: Perubahan dikembangkan dan diterapkan ke Staging Environment;
• (e) UAT: Customer melakukan Universal User Acceptance Testing di Staging Environment. Minimal 5 Business Days diberikan untuk UAT. Persetujuan tertulis diperlukan (lihat Bagian 3.2.1);
• (f) Penerapan: Setelah Customer menyetujui UAT, perubahan diterapkan ke Production selama maintenance window yang disepakati;
• (g) Tinjauan Pasca-Implementasi: Provider memantau perubahan selama 5 Business Days setelah penerapan dan memberikan laporan penutupan kepada Customer.

Rollback: Setiap perubahan Normal dan Emergency wajib mencakup rencana rollback yang terdokumentasi. Jika perubahan menyebabkan penurunan layanan yang tidak direncanakan, Provider wajib menjalankan rollback dalam 2 jam sejak mengidentifikasi isu dan segera memberi tahu Customer.

4.6.3 Auditabilitas Perubahan

Semua perubahan pada konfigurasi, basis kode, dan infrastruktur Platform dicatat dalam Sistem Manajemen Perubahan milik Provider. Setiap catatan perubahan mencakup: pihak yang meminta, deskripsi, penilaian risiko, rantai persetujuan, tanggal implementasi, engineer pelaksana, hasil pengujian, dan status pasca-implementasi. Log perubahan tersedia bagi Customer atas permintaan dan disertakan dalam Quarterly Service Review (lihat Bagian 3.9.2).

4.7 Manajemen Rilis Perangkat Lunak

Provider mengelola seluruh pengiriman perangkat lunak melalui proses manajemen rilis yang terkendali, yang membedakan dua jenis pengiriman yang secara fundamental berbeda: Releases/Updates (bertahap, spesifik per klien, sering) dan Upgrades (versi mayor, untuk seluruh produk, tahunan). Pembedaan ini memastikan bahwa pengiriman agile harian untuk Customer tidak berbenturan dengan roadmap produk Provider yang lebih luas.

4.7.1 Releases & Updates (Incremental – mis. v11.xx)

Releases dan updates adalah pengiriman bertahap dalam versi mayor Platform saat ini (misalnya v11.01, v11.02, v11.15). Ini menangani permintaan perubahan, perbaikan bug, penyesuaian konfigurasi, dan peningkatan fungsional kecil yang spesifik untuk implementasi Customer. Releases dikirim menggunakan metodologi pelaksanaan Agile yang disesuaikan dengan ritme operasional Customer.

Metodologi Sprint Agile: Provider beroperasi dalam sprint siklus pendek rata-rata 3 Hari Kerja per sprint. Setiap sprint menghasilkan serangkaian permintaan perubahan, perbaikan bug, atau perubahan konfigurasi yang telah disepakati dengan Customer pada perencanaan sprint. Siklus sprint adalah sebagai berikut:

Penomoran Rilis: Setiap rilis inkremental diberi nomor versi semantik dalam versi mayor saat ini (misalnya, v11.01, v11.02… v11.xx). Nomor versi bertambah secara berurutan pada setiap pengiriman sprint. Provider memelihara log rilis yang dapat diakses oleh Customer melalui Platform.

4.7.2 Peningkatan Versi (Versi Utama – misalnya v11 → v12)

Peningkatan merupakan versi mayor baru dari Platform (misalnya, v11 → v12, v12 → v13). Peningkatan adalah rilis untuk seluruh produk yang mencakup peningkatan fungsional yang signifikan, modul baru, redesain UI/UX, API/SDK baru, perbaikan arsitektur, dan peningkatan versi COTS mayor (misalnya, .NET framework, mesin SQL Server). Peningkatan dirilis kira-kira sekali per tahun dan merepresentasikan nomor versi perangkat lunak baru.

Peningkatan Mayor biasanya mencakup:

• Peningkatan Fungsional Baru: Penambahan fitur, kemampuan modul baru, dan perbaikan alur kerja yang didorong oleh roadmap produk Provider dan masukan Customer Advisory Board;
• Peningkatan UI/UX: Redesain antarmuka, peningkatan kemudahan penggunaan, peningkatan aksesibilitas, dan pembaruan desain responsif;
• Ekstensi API & SDK: Endpoint integrasi baru, peningkatan kapabilitas Web API, dan pembaruan Software Development Kits;
• Peningkatan Platform COTS: Migrasi ke versi baru teknologi dasar (.NET, SQL Server, IIS) sebagai bagian dari komitmen Provider terhadap kekinian teknologi;
• Peningkatan Keamanan: Penerapan standar keamanan baru, peningkatan enkripsi, dan kepatuhan terhadap persyaratan regulasi yang berkembang.

4.7.3 Proses Manajemen Rilis & Deployment Terintegrasi

Semua rilis (inkremental) dan peningkatan (versi mayor) dikelola melalui Platform Release Centre, yang berfungsi sebagai platform pusat manajemen dan distribusi rilis. Platform menyediakan kapabilitas berikut:

• (h) Katalog Rilis: Katalog lengkap semua rilis yang tersedia untuk setiap Customer, disusun berdasarkan aplikasi dan versi. Setiap entri rilis mencakup tanggal rilis, nomor versi, dan catatan rilis terperinci yang menjelaskan fitur baru, perbaikan, dan isu yang diketahui;
• (i) Akses Berbasis Kredensial: Akses ke Platform diamankan melalui kredensial unik yang ditetapkan kepada administrator yang ditunjuk oleh Customer. Hak akses menentukan visibilitas rilis yang berlaku untuk modul berlisensi Customer;
• (j) Catatan Rilis & Log Perubahan: Setiap rilis disertai komentar semantik dan kontekstual yang menjelaskan fitur, fungsionalitas, dan perbaikan bug terbaru, ditinjau dan disetujui oleh Reviewer Provider sebelum publikasi;
• (k) Ketersediaan Sesuai Permintaan: Rilis tersedia untuk diunduh sesuai permintaan, dengan tunduk pada penerimaan administrator Customer. Provider memberi pemberitahuan kepada Customer ketika rilis baru tersedia;
• (l) Jejak Audit: Platform menyimpan catatan lengkap mengenai rilis mana yang telah disediakan, diunduh, dan diterapkan untuk setiap lingkungan Customer. Model Deployment SaaS: Dalam model delivery SaaS, Provider mengelola seluruh deployment ke lingkungan sovereign khusus Customer. Customer tidak melakukan self-install rilis. Proses deployment adalah sebagai berikut:

4.7.4 End-of-Life & Transisi Versi

Kebijakan End-of-Life (EOL) Provider, siklus hidup transisi versi, layanan migrasi, program pelatihan ulang, prosedur pengembalian data, dan proses penghentian langganan diatur secara komprehensif dalam Bab 10 — End-of-Life, Version Transition & Subscription Cessation. Bab 10 mengatur seluruh aspek manajemen siklus hidup versi mulai dari General Availability (GA) hingga EOL Announcement, End of Engineering (EOE), End of Life, dan Extended Support opsional.

Untuk keperluan Bab ini, ringkasan berikut berlaku: Provider wajib memberikan pemberitahuan tertulis kepada Customer minimal dua belas (12) bulan sebelum versi mayor mencapai End of Life. Bantuan upgrade, termasuk perencanaan migrasi, migrasi data, adopsi integrasi, pelatihan ulang, dan dukungan UAT, termasuk dalam Subscription Term tanpa biaya tambahan. Ketentuan, jadwal, dan prosedur lengkap diatur dalam Bagian 10.1 hingga 10.14.

4.7.5 Pengendalian Versi & Escrow Kode Sumber

Provider memelihara seluruh kode sumber dalam sistem kontrol versi berbasis Git yang mencakup:

• Master Branch: Aplikasi standar DANAOS ("Vanilla Version") yang merepresentasikan rilis yang saat ini tersedia secara umum;
• Client Branches: Konfigurasi dan kustomisasi khusus Customer yang dipelihara sebagai branch khusus. Rilis sprint dikembangkan pada client branch;
• Working Clones: Salinan kerja developer yang digabungkan dalam kondisi stabil untuk menggabungkan fungsionalitas baru ke Master dan Client branches. Semua perubahan kode tunduk pada peer review melalui Pull Request, pengujian otomatis, dan kepatuhan terhadap Programming Guidelines Provider yang mencakup standar terbaik kualitas kode, logika bisnis, dan keamanan. Setelah Commit dan Push, serta setelah peninjauan Pull Request apa pun, versi aplikasi dijustifikasi secara lengkap oleh programmer yang bertanggung jawab (atau Agile Team) dengan komentar semantik dan kontekstual. Reviewer menerima atau menolak perubahan berdasarkan Programming Guidelines Provider. Logika bisnis juga diverifikasi oleh DANAOS Support Engineers yang merupakan subject-matter experts dalam domainnya.

Provider menerapkan Continuous Integration / Continuous Delivery (CI/CD) untuk deployment perangkat lunak bila sesuai. Pipeline CI/CD mengotomatiskan tahap build, test, dan deployment dari repositori Git hingga ke Staging Environment, memastikan konsistensi dan mengurangi kesalahan deployment manual.

Penyedia wajib mempertahankan pengaturan Source Code Escrow dengan Escrow Agent pihak ketiga independen. Ketentuan lengkap yang mengatur isi setoran escrow, frekuensi pembaruan, verifikasi tahunan, kondisi pelepasan, dan hak Pelanggan setelah pelepasan ditetapkan dalam Section 9.14 (Source Code Escrow). Biaya pengaturan escrow, termasuk biaya Escrow Agent, ditanggung oleh Pelanggan (lihat § 9.14.4).

4.8 Layanan IMAC/RD

Provider menyediakan layanan Install, Move, Add, Change, Remove, and Dispose (IMAC/RD) untuk Platform sebagai bagian dari dukungan operasional berkelanjutan. Aktivitas IMAC/RD dikelola sebagai perubahan Standard atau Normal (lihat Bagian 4.6.1) dan tunduk pada cakupan berikut:

Aktivitas IMAC/RD yang berada di luar cakupan Subscription Term akan dikutip terpisah berdasarkan tarif per manday, yang disepakati secara tertulis antara para pihak sebelum pekerjaan dimulai.

4.9 Panduan Arsitektur Enterprise

Provider wajib memberi advis kepada Customer mengenai hal-hal arsitektur enterprise yang berkaitan dengan Platform, termasuk integrasi sistem, desain aliran data, dan penyelarasan teknologi. Ini mencakup:

• (a) Arsitektur Integrasi: Panduan untuk menghubungkan ProjectVIEW ERP dengan sistem enterprise Customer yang sudah ada (misalnya SAP, Oracle, platform perbankan, sistem HR) melalui Web API native Platform (lihat Bagian 2.5);
• (b) Arsitektur Data: Saran mengenai aliran data, perencanaan migrasi data, manajemen master data, dan arsitektur pelaporan dalam lingkungan sovereign khusus Customer;
• (c) Arsitektur Keamanan: Panduan mengenai keamanan jaringan, kebijakan kontrol akses, standar enkripsi, dan keselarasan dengan kerangka keamanan yang diuraikan dalam Bagian B dari Framework ini;
• (d) Perencanaan Skalabilitas: Rekomendasi proaktif untuk penskalaan environment berdasarkan proyeksi pertumbuhan pengguna, tren volume data, dan rencana aktivasi modul. Panduan arsitektur enterprise diberikan sebagai layanan advisori dan tidak mencakup desain, pengembangan, atau dukungan sistem pihak ketiga. Implementasi rekomendasi arsitektural tunduk pada scoping dan costing terpisah yang disepakati antara para pihak.

4.10 Continual Service Improvement (CSI)

Provider menjalankan program Continual Service Improvement (CSI) yang selaras dengan praktik ITIL 4 dan metodologi AIOps kontemporer untuk mendorong peningkatan berkelanjutan dalam kualitas layanan, efisiensi operasional, dan kepuasan Customer. Program CSI mencakup:

• Analisis Tren Berbantuan AI: Analisis bulanan atas volume insiden, kategori, isu berulang, dan waktu penyelesaian menggunakan pengenalan pola dan deteksi anomali untuk mengidentifikasi perbaikan sistemik secara proaktif;
• Eliminasi Akar Masalah: Aktivitas Problem Management yang menargetkan penghapusan insiden berulang melalui perbaikan permanen, berdasarkan analisis korelasi lintas tiket;
• Optimasi Proses: Tinjauan rutin atas proses dukungan, workflow tiket, prosedur eskalasi, dan efektivitas dukungan omnichannel untuk mengurangi waktu penyelesaian dan meningkatkan pengalaman Customer;
• Umpan Balik & Manajemen Pengalaman Customer: Integrasi hasil survei kepuasan Customer, masukan Quarterly Service Review, dan metrik efektivitas channel WhatsApp ke dalam register CSI;
• Pembaruan Teknologi: Identifikasi proaktif atas pembaruan COTS, peningkatan keamanan, dan optimasi platform yang memberikan manfaat bagi Customer;
• Manajemen Pengetahuan: Pengayaan berkelanjutan knowledge base tersemat dengan solusi dari tiket yang telah diselesaikan, sehingga memungkinkan tingkat penyelesaian self-service yang lebih tinggi dan mengurangi volume insiden berulang. Register CSI dikelola oleh Service Delivery Manager dan ditinjau pada setiap Quarterly Service Review (lihat Bagian 3.9.2). Semua inisiatif CSI dilacak dari identifikasi hingga implementasi dengan hasil yang terukur. Apabila Provider mengadopsi alat berbantuan AI dalam operasi dukungan, penggunaannya wajib mematuhi kerangka tata kelola yang berlaku termasuk EU AI Act dan NIST AI Risk Management Framework (AI RMF 1.0).

URL Referensi:

ITIL 4 Foundation – PeopleCert / Axelos ProjectVIEW ERP Ticketing System – DANAOS Projects WhatsApp Business Platform – Meta Azure Service Health – Microsoft NIST SP 800-88 Media Sanitization Guidelines NIST AI Risk Management Framework (AI RMF 1.0) EU AI Act – European Commission

4.11 Register Proses

Tabel berikut merangkum proses dukungan layanan dan operasional yang ditetapkan dalam Bab ini, termasuk peran yang bertanggung jawab, hasil yang diharapkan, dan referensi silang ke proses terkait dalam Bab lain.

Legenda Peran: P = Provider | C = Customer | PSD = Provider Service Desk | SDM = Service Delivery Manager | CAB = Change

Advisory Board | SC = Steering Committee

4.11.1 Register Proses

4.11.2 Matriks RACI

R = Responsible (melaksanakan) | A = Accountable (persetujuan) | C = Consulted | I = Informed | — = Tidak Terlibat

4.11.3 Alur Proses — Siklus Hidup Dukungan & Operasional