Organisasi dan komposisi tim

Praktik terbaik untuk organisasi dan komposisi tim

Komposisi tim dalam migrasi besar bervariasi menurut organisasi dan perubahan selama proyek berlangsung. Berikut ini adalah praktik terbaik yang umum untuk semua proyek migrasi besar:

• Identifikasi pemimpin teknis berulir tunggal di tingkat proyek dan hindari silo — Proyek migrasi besar sering kali memiliki banyak alur kerja dan tim, setiap tim memiliki tugas dan hasil yang berbeda. Pemimpin berulir tunggal di tingkat proyek penting karena pemimpin ini memastikan semua alur kerja bekerja sama dan tetap terhubung. Ini membantu mencegah silo dan batas. Misalnya, alur kerja portofolio perlu terus mengirim metadata migrasi ke alur kerja migrasi untuk mendukung aktivitas migrasi. Tanpa pemahaman lengkap tentang metadata migrasi yang diperlukan, output alur kerja portofolio mungkin tidak berfungsi sebagai masukan untuk alur kerja migrasi. Pemimpin single-threaded membantu mengoordinasikan input dan output dari setiap alur kerja untuk membantu migrasi berjalan secara efisien.

• Selaraskan semua hasil tingkat alur kerja dengan hasil bisnis tingkat proyek - Hasil bisnis tingkat proyek harus dikomunikasikan kepada semua pemimpin alur kerja sebelum migrasi dimulai. Setiap pemimpin alur kerja harus memahami peran alur kerja mereka dan merancang proses mereka untuk mendukung hasil bisnis tingkat proyek. Misalnya, jika hasil bisnis tingkat proyek keluar dari pusat data dalam 12 bulan ke depan dan kecepatan adalah faktor yang paling penting, pemimpin alur kerja harus melakukan hal berikut:

  • Semua workstream harus memprioritaskan migrasi rehost, mengurangi jumlah tugas manual, dan menambahkan otomatisasi untuk meningkatkan kecepatan.

  • Alur kerja portofolio harus menentukan pola standar dan membatasi pola yang dapat disesuaikan untuk mengurangi jumlah waktu yang diperlukan untuk merancang lingkungan target.

• Rancang alur kerja berdasarkan ruang lingkup dan tahap proyek - Setiap proyek migrasi berbeda, dan satu ukuran tidak cocok untuk semua. Kami merekomendasikan memiliki empat alur kerja inti untuk semua proyek migrasi besar: alur kerja migrasi, alur kerja portofolio, alur kerja tata kelola proyek, dan alur kerja yayasan. Anda mungkin memutuskan untuk membuat alur kerja tambahan yang mendukung tergantung pada kasus penggunaan Anda. Untuk informasi selengkapnya tentang alur kerja, lihat Aliran kerja dalam migrasi besar. Misalnya, jika Anda belum merancang pagar pembatas keamanan dalam fase mobilisasi, Anda perlu membuat alur kerja keamanan dan kepatuhan yang dapat menentukan persyaratan keamanan dan kepatuhan sebelum Anda mulai bermigrasi. Untuk informasi selengkapnya tentang membangun pagar pembatas keamanan dalam fase mobilisasi, lihat Keamanan, risiko, dan kepatuhan di Memobilisasi organisasi Anda untuk mempercepat migrasi skala besar.

• Libatkan tim aplikasi sebelum migrasi — Migrasi besar bukan hanya proyek infrastruktur TI — migrasi mengubah model operasi untuk bisnis Anda. Melibatkan tim aplikasi lebih awal dan menyematkan pemilik aplikasi ke dalam alur kerja migrasi besar Anda sangat penting untuk keberhasilan proyek migrasi besar. Misalnya, selama penilaian portofolio, jadwalkan pertemuan Anda lebih awal dengan pemilik aplikasi sehingga mereka dapat berpartisipasi dalam penyelaman mendalam dan membantu merancang status target aplikasi merekaAWS.

• Tentukan ukuran tim berdasarkan alur kerja dan hasil bisnis — Hasil bisnis yang diharapkan dan strategi migrasi mendorong ukuran masing-masing tim, yang terdiri dari unit yang lebih kecil yang disebut pod. Di setiap alur kerja, Anda menentukan tim untuk setiap strategi migrasi dan kemudian memisahkan tim tersebut ke dalam pod. Misalnya, jika rehost adalah strategi migrasi utama Anda, maka Anda harus memiliki tim migrasi rehost yang terdiri dari pod yang berisi 3-5 orang. Saat beroperasi pada kecepatan puncak, pod yang terdiri dari 4-5 orang di tim migrasi biasanya dapat meng-host ulang hingga 50 server per minggu. Ini adalah sekitar 200 server per bulan atau 2.500 server per tahun. Jika target Anda adalah meng-host ulang 100 server per minggu, Anda harus membuat dua pod yang terdiri dari 4-5 orang dalam tim migrasi rehost. Jika Anda menargetkan kurang dari 50 per minggu, Anda dapat mengurangi ukuran pod migrasi menjadi 3 orang. Migrasi replatform biasanya lebih mahal daripada rehost, dan pod ukuran yang sama dapat bermigrasi hingga 20 server per minggu. Alur kerja portofolio biasanya setengah dari ukuran alur kerja migrasi. Anda membuat tim dan pod tambahan di setiap alur kerja untuk mendukung setiap strategi migrasi. Rekomendasi ini mengasumsikan bahwa sumber daya migrasi Anda terampil dan tidak memerlukan pelatihan yang signifikan. Tabel berikut adalah contoh bagaimana Anda akan membagi alur kerja migrasi dan portofolio menjadi tim dan pod untuk strategi migrasi rehost dan replatform. Contoh berikut mengasumsikan bahwa Anda perlu memigrasikan 120 server per minggu (100 rehost +20 replatform) atau 6.000 server per tahun. Contoh ini adalah kecepatan maksimum. Kami menyarankan Anda merencanakan sumber daya tambahan untuk membantu mencegah penundaan.

  Alur kerja	Tim	Pod	Sumber daya
  Alur kerja migrasi	Rehost tim migrasi	Pod migrasi rehost 1	4—5 orang
  		Pod migrasi rehost 2	4—5 orang
  	Tim migrasi replatform	Pod migrasi platform ulang	4—5 orang
  Alur kerja portofolio	Tim portofolio	Portofolio pod 1	3—4 orang
  		Portofolio pod 1	3—4 orang

• Bangun model tata kelola pada tahap awal — Migrasi besar biasanya melibatkan banyak orang, termasuk orang-orang dari perusahaan Anda sendiri, vendor perangkat lunak pihak ketiga, integrator sistem, atau konsultan eksternal. Proyek Anda mungkin mencakup perwakilan dariAWS, seperti tim akun Anda, teknisi dukungan, atau pakar dari Layanan AWS Profesional. Model pengiriman Anda bervariasi tergantung pada ruang lingkup proyek Anda dan dengan siapa Anda bekerja untuk mengirimkan proyek. Misalnya, proyek Anda mungkin menyertakan AWS atau integrator sistem, atau Anda mungkin menyertakan keduanya. Penting untuk membangun model tata kelola lebih awal dan membuat matriks RACI yang secara jelas mendefinisikan peran dan tanggung jawab. Sebagai rekomendasi, kami juga merekomendasikan membuat Cloud Enablement Engine (CEE), juga dikenal sebagai Cloud Center of Excellence, di organisasi Anda dan termasuk representasi dari semua pihak. Tujuan utama CEE adalah untuk mengubah organisasi dari model operasi lokal menjadi model operasi cloud. Tim terpusat ini sangat penting untuk keberhasilan migrasi besar karena mengelola hubungan, membuat keputusan kunci, dan menangani eskalasi di seluruh proyek. CEE dibahas secara lebih rinci nanti dalam panduan ini.

Membuat matriks RACI

Proyek migrasi besar biasanya melibatkan banyak orang, jadi membangun model tata kelola penting untuk mengelola proyek. Salah satu komponen kunci dari model tata kelola adalah matriks RACI, yang digunakan untuk menentukan peran dan tanggung jawab semua pihak yang terlibat dalam migrasi besar. Nama matriks RACI berasal dari empat jenis tanggung jawab yang didefinisikan dalam matriks:

• Bertanggung jawab (R) — Peran ini bertanggung jawab untuk melakukan pekerjaan untuk menyelesaikan tugas.

• Akuntabel (A) — Peran ini bertanggung jawab untuk memastikan tugas selesai. Peran ini juga bertanggung jawab untuk memastikan prasyarat terpenuhi dan mendelegasikan tugas kepada mereka yang bertanggung jawab.

• Konsultasikan (C) — Peran ini harus dikonsultasikan untuk pendapat atau keahlian tentang tugas tersebut. Tergantung pada tugasnya, jenis tanggung jawab ini mungkin tidak diperlukan.

• Informed (I) — Peran ini harus selalu up to date pada kemajuan tugas dan diberitahu ketika tugas selesai.

Karena kompleksitas migrasi besar, kami tidak menyarankan menggunakan matriks RACI tunggal untuk mendokumentasikan setiap tugas dalam migrasi besar. Matriks RACI multi-layer adalah pendekatan yang jauh lebih mudah diakses. Anda mulai dengan membangun matriks RACI tingkat tinggi, dan kemudian Anda menambahkan lebih banyak detail ke setiap bagian untuk membangun matriks terperinci. Membangun matriks RACI terperinci bukanlah pendekatan satu kali. Anda perlu membuat matriks baru atau menambahkan lebih banyak detail ke yang sudah ada saat Anda maju melalui portofolio dan menemukan lebih banyak strategi dan pola migrasi.

Dalam template playbook foundation, Anda dapat menggunakan template RACI (format Microsoft Excel) sebagai titik awal untuk membangun matriks RACI tingkat tinggi dan terperinci Anda sendiri. Template ini mencakup dua contoh matriks RACI terperinci, satu untuk migrasi rehost dan satu lagi untuk migrasi replatform. Tugas dalam contoh ini disertakan hanya untuk tujuan sampel, dan Anda harus menyesuaikan contoh ini berdasarkan kasus penggunaan Anda.

Bangun matriks RACI tingkat tinggi

Sebelum Anda mulai membangun matriks RACI tingkat tinggi, Anda harus menyiapkan informasi berikut:

• Siapa pihak tingkat tinggi yang terlibat dalam migrasi ini? Identifikasi mitra atau konsultan yang akan terlibat dalam proyek ini, seperti layanan AWS profesional atau integrator sistem. Pertimbangkan apakah ada bagian dari infrastruktur TI Anda saat ini dikelola oleh mitra eksternal. Berikut ini adalah contoh partai tingkat tinggi:

  • Organisasi Anda

  • AWSLayanan Profesional

  • Integrator sistem

• Apa alur kerja dalam migrasi Anda? Untuk informasi selengkapnya, lihat Aliran kerja dalam migrasi besar. Minimal, Anda harus memiliki empat alur kerja inti, dan Anda dapat menambahkan alur kerja dukungan sesuai kebutuhan untuk proyek Anda.

• Apa tugas tingkat tinggi dalam migrasi Anda? Buat daftar tugas tingkat tinggi dalam migrasi Anda. Berikut ini adalah contoh tugas tingkat tinggi:

  • Membangun AWS landing zone

  • Lakukan penilaian portofolio dan kumpulkan metadata migrasi

  • Melakukan rehost, memplatform ulang, atau memindahkan migrasi

  • Lakukan pengujian aplikasi dan cutover

  • Melakukan tugas manajemen proyek dan tata kelola

Lakukan hal berikut untuk membangun matriks RACI tingkat tinggi Anda:

1. Dalam template playbook foundation, buka template RACI (format Microsoft Excel).

2. Pada tab RACI tingkat tinggi, di baris pertama, masukkan nama organisasi Anda dan mitra apa pun yang Anda identifikasi.

3. Di kolom pertama, masukkan tugas dan alur kerja tingkat tinggi yang Anda identifikasi.

4. Dalam matriks, tentukan pihak mana yang bertanggung jawab untuk setiap tugas sebagai berikut:

   • Jika suatu pihak bertanggung jawab untuk menyelesaikan tugas, masukkan R.

   • Jika suatu pihak bertanggung jawab atas tugas tersebut, masukkan A.

   • Jika suatu pihak harus dikonsultasikan tentang tugas tersebut, masukkan C.

   • Jika suatu pihak harus diberi tahu tentang tugas tersebut, masukkan I.

Tabel berikut adalah contoh matriks RACI tingkat tinggi.

Tugas	Organisasi Anda	Mitra A	Mitra B	Mitra C
Membangun AWS landing zone	R/C	A	I	I
Lakukan penilaian portofolio dan perencanaan gelombang	R/C	A	I	I
Lakukan aktivitas migrasi rehost	C	C	R/A	I
Lakukan aktivitas migrasi replatform	C	C	I	R/A
Manajemen dan tata kelola proyek	R/C	A	I	I
Perubahan dan pengujian aplikasi	C	R/A	C	C
Operasi cloud	I	C	R/A	I

Bangun matriks RACI terperinci

Setelah membuat matriks RACI tingkat tinggi, langkah selanjutnya adalah membuat RACI terperinci untuk setiap tugas tingkat tinggi dan selanjutnya menyempurnakan tugas, pesta, dan kepemilikan. Sebelum Anda mulai membangun matriks terperinci, Anda harus menyiapkan informasi berikut:

• Apa tugas terperinci dalam migrasi Anda? Setelah Anda menyiapkan runbook dan daftar tugas untuk proyek migrasi besar Anda, proses dan detail dalam runbook ini membentuk lapisan terperinci dari matriks RACI Anda. Misalnya, untuk migrasi rehost, tugas terperinci mungkin termasuk menginstal agen replikasi, memverifikasi replikasi, dan meluncurkan instance pengujian untuk pengujian boot-up. Jika Anda belum melakukannya, ikuti petunjuk di buku pedoman berikut untuk membuat dokumen-dokumen ini:

  • Buku pedoman portofolio untuk migrasi AWS besar

  • Buku pedoman migrasi untuk migrasi AWS besar

• Tim kecil apa yang membentuk setiap alur kerja dan setiap partai tingkat tinggi? Misalnya, tim di organisasi Anda mungkin menyertakan tim aplikasi, tim infrastruktur, tim operasi, tim jaringan, atau kantor manajemen proyek.

Lakukan hal berikut untuk membangun matriks RACI terperinci:

1. Buka matriks RACI tingkat tinggi Anda.

2. Buat salinan spreadsheet RACI (template) Detail.

3. Beri nama spreadsheet yang disalin untuk tugas tingkat tinggi yang Anda identifikasi. Bangun matriks RACI tingkat tinggi

4. Di baris pertama, masukkan nama-nama tim yang terlibat dalam tugas tingkat tinggi ini.

5. Di kolom pertama, masukkan tugas terperinci yang Anda identifikasi untuk tugas tingkat tinggi ini. Anda dapat mengelompokkan tugas terperinci ke dalam grup sekuensial logis, yang membantu pembaca menavigasi matriks.

6. Dalam matriks, tentukan tim mana yang bertanggung jawab untuk setiap tugas sebagai berikut:

   • Jika tim bertanggung jawab untuk menyelesaikan tugas, masukkan R.

   • Jika tim bertanggung jawab untuk menyelesaikan tugas, masukkan A.

   • Jika tim harus dikonsultasikan tentang tugas tersebut, masukkan C.

   • Jika tim harus diberi tahu tentang tugas tersebut, masukkan I.

7. Untuk setiap tugas terperinci, konfirmasikan bahwa hanya satu tim yang bertanggung jawab dan hanya satu tim yang bertanggung jawab. Jika beberapa tim bertanggung jawab atau bertanggung jawab, ini dapat menunjukkan bahwa tugas tersebut tidak didefinisikan dengan jelas atau tidak memiliki kepemilikan yang jelas.

8. Bagikan matriks RACI terperinci dengan tim yang diidentifikasi dan konfirmasikan bahwa semua tim terbiasa dengan peran dan tanggung jawab mereka.

9. Ulangi proses ini untuk setiap tugas tingkat tinggi yang Anda identifikasi. Bangun matriks RACI tingkat tinggi

Untuk contoh matriks RACI terperinci, lihat spreadsheet Rehost RACI dan Replatform RACIdi template RACI, tersedia di lampiran buku pedoman dasar.

Mesin Pengaktifan Cloud (CEE)

Praktik terbaik untuk menggunakan CEE

Tujuan CEE adalah mengubah organisasi TI dari model operasi lokal menjadi model operasi cloud, dan bertanggung jawab untuk memandu organisasi melalui perubahan organisasi dan budaya. Sebagai praktik terbaik, Anda disarankan untuk membuat CEE untuk migrasi besar Anda. Proses dasar dan rel penjaga CEE yang terdefinisi dengan baik dapat membantu Anda mencapai skala dan kecepatan yang diperlukan untuk migrasi besar. Untuk informasi tentang menyiapkan CEE, lihat Cloud Enablement Engine: Panduan Praktis. Berikut ini adalah rekomendasi tambahan dan praktik terbaik untuk mendirikan CEE untuk proyek migrasi besar:

• Tim CEE harus terdiri dari pemimpin lintas fungsi dengan kualitas berikut:

  • Memiliki pengetahuan kelembagaan yang mendalam

  • Memiliki hubungan internal yang kuat dan lama

  • Memiliki kepentingan pribadi dalam kemajuan dan keberhasilan dalam migrasi besar

  • Penasaran dan ingin belajar

  • Terutama atau semata-mata berfokus pada migrasi

• Tim CEE harus merupakan campuran dari orang-orang yang telah bekerja sama sebelumnya dan pendatang baru yang dapat memberikan wawasan baru.

• Tim CEE harus memiliki dukungan eksekutif yang kuat dan keselarasan pada tujuan migrasi.

• Pastikan tujuan tim CEE spesifik untuk migrasi besar.

• Lakukan rapat rutin dan terbuka yang memberikan peluang untuk pertanyaan dan jawaban, mendemonstrasikan layanan dan arsitektur cloud, dan berbagi pembaruan tentang migrasi yang berhasil dan kemenangan lainnya.

• Tim CEE harus diberdayakan untuk membuat keputusan penting tentang proyek migrasi besar.

Peran dan tanggung jawab CEE yang khas untuk migrasi besar

Tabel berikut memberikan peran dalam tim CEE migrasi besar, dan ini menjelaskan tugas dan tanggung jawab khas untuk setiap peran. Komposisi aktual tim Anda dan tanggung jawab mereka dapat bervariasi berdasarkan kasus penggunaan, ruang lingkup, dan tujuan bisnis Anda.

Peran	Tugas dan tanggung jawab
Sponsor eksekutif	Mengelola eskalasi Menyelaraskan organisasi dengan erat di sekitar tujuan dan kekritisan migrasi. Melayani sebagai suara otoritas
Arsitek perusahaan atau pemimpin teknis tingkat proyek	Mengidentifikasi dan mendokumentasikan arsitektur referensi untuk jenis beban kerja yang diketahui Merancang dan membangun proses migrasi untuk seluruh proyek, di semua alur kerja Melayani sebagai pemimpin teknis berulir tunggal yang memastikan semua alur kerja berkolaborasi dan bekerja untuk mencapai tujuan tingkat bisnis yang sama Pengetahuan kelembagaan yang kuat tentang aplikasi utama dan arsitektur umum
Pimpinan kantor manajemen proyek	Mengelola jadwal, orientasi, pelatihan, dokumentasi, pelaporan, komunikasi, dan tata kelola sumber daya Mengelola sumber daya dan pelatihan Mengelola balai kota terkait migrasi
Pimpin migrasi	Merancang proses dan alat migrasi Merancang strategi migrasi dan otomatisasi Mengawasi pemotongan migrasi dan mencapai kecepatan target
Pimpinan portofolio	Merancang penilaian portofolio dan proses dan alat perencanaan gelombang Merancang penemuan portofolio dan proses pengumpulan data Mengawasi pasokan metadata migrasi dan rencana gelombang yang berkelanjutan
Pemimpin operasi cloud	Merancang model operasi untuk menjalankan beban kerja AWS Merancang strategi untuk pemantauan, respons insiden, penandaan, kelangsungan bisnis, dan strategi pemulihan bencana
Pemimpin tim aplikasi	Mengelola hubungan dengan pemilik aplikasi individu Mengelola perencanaan migrasi dan pemotongan untuk aplikasi mereka Mengelola perubahan aplikasi, pengujian, dan persetujuan
Jaringan dan infrastruktur memimpin	Merancang AWS landing zone untuk akun target Merancang konektivitas dan infrastruktur jaringan Merancang dan menyebarkan kelompok keamanan Mengelola perubahan infrastruktur dan jaringan untuk mendukung migrasi besar
Memimpin perizinan	Mengidentifikasi semua aplikasi komersial off-the-shelf (COTS) dan perusahaan dan bekerja dengan tim migrasi dan tim aplikasi untuk merencanakan strategi migrasi seputar perizinan
Memimpin keamanan dan kepatuhan	Merancang otentikasi dan otorisasi untuk migrasi besar, termasuk Active Directory, single sign-on, dan kebijakan IAM Merancang keamanan jaringan, termasuk firewall lokal, dan mengelola kerentanan Merancang persyaratan kepatuhan untuk beban kerja dalam ruang lingkup