Alur kerja operasional

Alur kerja operasional mendukung fondasi teknis dan alur kerja perjalanan pengguna. Mayoritas kegiatan non-teknis yang penting untuk keberhasilan migrasi secara keseluruhan adalah bagian dari alur kerja ini.

Alur kerja ini melibatkan keputusan yang dapat diubah atau dibalik dengan sedikit usaha atau dampak. Spesifikasi produk yang didasarkan pada bagaimana orang bekerja dan terlibat jarang benar pada kali pertama—ada banyak pemangku kepentingan dan suara yang perlu dipertimbangkan. Penting untuk terlibat lebih awal dan berkonsultasi secara luas dan sering, sehingga pendekatan yang gesit dan berulang masuk akal untuk aliran kerja ini. Anda mulai dengan draf awal model operasi atau materi pelatihan dan berulang sering dan cepat untuk sampai ke produk akhir.

Alur kerja operasional terdiri dari lima fase: tata kelola proyek, penyelarasan, definisi model operasi, pengenalan layanan, dan pelatihan.

Tata kelola program

Kegiatan tata kelola program berjalan di seluruh garis waktu proyek migrasi. Terlepas dari tahap proyek, kegiatan harus teratur (pertemuan berulang yang dijadwalkan), transparan (tim proyek diberi kesempatan untuk meningkatkan risiko dan masalah secara terus terang), dan dengan tata kelola yang terlibat (para pemimpin diberdayakan dan bersedia membuat keputusan atau meningkat sesuai). Ini sangat penting untuk menyoroti dan menyelesaikan masalah dengan cepat dan efektif.

Keselarasan

Ini adalah kegiatan formal pertama dari proyek dan berfokus pada menyelaraskan ruang lingkup proyek dengan hasil bisnis. Alignment memberikan kesempatan untuk memvalidasi dan menyesuaikan rencana dan perkiraan sebelumnya berdasarkan diskusi dengan para pemangku kepentingan.

Tindakan utama selama kegiatan ini meliputi:

• Temukan kasus penggunaan pelanggan tingkat tinggi, masalah teknis dan bisnis saat ini, dan peluang untuk perbaikan.

• Diskusikan dan sepakati hasil bisnis yang diinginkan, tentukan prioritas relatifnya, dan identifikasi kriteria keberhasilan.

• Kembangkan desain solusi tingkat tinggi, yang digunakan untuk menentukan ruang lingkup dan pilihan teknologi pada fase awal ini. Desain tingkat tinggi ini memberikan arahan untuk mempercepat aktivitas desain tingkat rendah di fase selanjutnya.

• Validasi jadwal dan biaya implementasi.

Definisi model operasi

Kegiatan dalam fase ini menentukan siapa yang akan menggunakan solusi pusat kontak dan bagaimana solusi akan dikelola. Model operasi bukan dokumen prosedural, runbook, atau file konfigurasi. Misalnya, seharusnya tidak menjelaskan cara menarik log dan melampirkannya ke tiket dukungan, atau memberikan tangkapan layar dari prosedur ini. Sebaliknya, itu harus mengidentifikasi siapa yang harus menarik log dan antrian atau vendor mana mereka harus dikirim.

Definisi model operasi harus mencakup:

• Matriks yang bertanggung jawab, akuntabel, didukung, dikonsultasikan, dan diinformasikan (RASCI), sehingga setiap tim memahami peran dan tanggung jawabnya, dan bagaimana mereka akan berinteraksi dengan tim lain. Berikut ini memberikan kutipan dari matriks RASCI.

  

• Aliran proses renang yang menentukan end-to-end kegiatan dan siapa yang bertanggung jawab untuk setiap aktivitas. Misalnya, harus ada alur proses untuk melibatkan out-of-hours dukungan sehingga jelas siapa yang mendapat halaman, apa yang terjadi jika mereka tidak dapat dihubungi, siapa yang mencatat tiket dukungan, dan bagaimana kekritisan bisnis dinilai. Contoh lain adalah pesan antrian darurat. Alur proses harus menunjukkan siapa yang memutuskan bahwa itu perlu dimulai, dan data apa yang harus mereka gunakan untuk membuat keputusan itu.

Model operasi biasanya didefinisikan di paruh kedua proyek, karena Anda harus menyelesaikan desain solusi dan perjalanan pengguna sebelum Anda dapat menentukan proses untuk mengelolanya secara akurat. Namun, kami menyarankan Anda untuk mengatur pemangku kepentingan di awal proses dan memesan waktu mereka untuk fase selanjutnya dari proyek. 

Kumpulkan contoh dokumen serupa dari organisasi Anda yang dapat Anda gunakan sebagai templat. Ini akan memudahkan peninjauan dan penandatanganan oleh pemangku kepentingan karena struktur dokumen akan akrab bagi mereka.

Pastikan bahwa pemangku kepentingan Anda menandatangani model operasi sebelum pusat kontak baru Anda pindah ke produksi, dan menjadikannya persyaratan bagi keputusan Anda untuk ditayangkan. Setiap anggota tim perlu memahami peran mereka dan proses untuk mengoperasikan pusat kontak di lingkungan produksi.

Pengenalan layanan (SI)

Kegiatan SI mengimplementasikan perubahan yang didefinisikan dalam model operasi. Pikirkan definisi model operasi sebagai fase desain dan pembuatan untuk model baru, dan SI sebagai fase penerapan model operasi.

Tim SI sering kali merupakan tim yang berdedikasi di organisasi Anda, dan bekerja secara independen dari tim proyek. Proyek harus lulus kriteria dan daftar periksa tim SI sebelum menerima persetujuan untuk ditayangkan. Misalnya, daftar periksa mencakup hasil pengujian penerimaan pengguna (UAT) dan konfirmasi bahwa peristiwa bentrokan (seperti pembekuan perubahan atau acara go-live terjadwal lainnya) tidak berlangsung pada hari yang sama saat proyek ditayangkan, bahwa pengguna memiliki pelatihan yang diperlukan, dan tim operasi siap untuk melanjutkan.

Jangan tinggalkan kegiatan SI sampai akhir proyek. Libatkan tim SI di awal proyek dan sertakan mereka dalam daftar distribusi Anda untuk dokumentasi desain. Keterlibatan awal memastikan bahwa tim SI dapat membantu dalam persiapan untuk ditayangkan, seperti membantu memilih rencana AWS dukungan yang paling sesuai, memberikan pernyataan dampak untuk permintaan perubahan (CRs), dan mendukung diskusi dewan persetujuan perubahan (CAB).

Pelatihan

Membuat materi pelatihan dan melakukan sesi pelatihan yang dihadiri dengan baik sangat penting untuk migrasi yang sukses. Teknologi dapat bekerja dengan sempurna, tetapi jika pengguna tidak tahu cara menjawab panggilan dan melakukan tugas sehari-hari mereka, migrasi akan dianggap gagal. 

Kegiatan pelatihan mungkin termasuk pelatihan pengguna langsung, pelatihan pelatih, pelatihan untuk supervisor, pelatihan untuk staf pendukung, dan pelatihan untuk administrator sistem atau pemilik produk. Setiap organisasi adalah unik, sehingga beberapa pilihan mungkin cocok budaya yang lebih baik daripada yang lain.

Kami merekomendasikan pendekatan melatih pelatih yang melibatkan staf pelatihan internal organisasi Anda. Staf Anda mengetahui budaya organisasi Anda, serta format dan teknik pelatihan yang paling sesuai dengan pengguna Anda. Anggota tim proyek dapat mengambil peran ahli materi pelajaran (UKM) untuk menyediakan materi teknis (seperti manual pengguna, manual konsol administrator, dan panduan layar) yang dapat digunakan sebagai bahan sumber untuk melatih sesi pelatih. Jika organisasi Anda tidak memiliki tim pelatihan, proyek SMEs harus melatih supervisor dan memimpin staf pendukung, yang kemudian dapat melatih pengguna pusat kontak.

Kami juga menyarankan agar administrator sistem dan pemilik produk mengikuti kursus pelatihan produk formal yang dipimpin instruktur untuk mendapatkan pemahaman yang lebih dalam tentang AWS lingkungan dan konsol Amazon Connect, sehingga mereka dapat menggunakan fitur produk dan memecahkan masalah secara efektif.