Menentukan dan memprioritaskan beban kerja untuk rencana adopsi cloud
Menetapkan prioritas yang jelas dan dapat ditindaklanjuti adalah salah satu rahasia adopsi cloud yang sukses. Godaan alami adalah untuk menginvestasikan waktu yang menentukan semua beban kerja yang dapat terpengaruh selama adopsi cloud. Tapi hal itu kontraproduktif, terutama di awal proses adopsi.
Sebagai gantinya, kami sarankan tim Anda memprioritaskan dan mendandani 10 beban kerja pertama secara menyeluruh. Setelah menerapkan rencana adopsi, tim dapat mempertahankan daftar 10 beban kerja prioritas tertinggi berikut. Pendekatan ini memberikan informasi yang cukup untuk merencanakan beberapa iterasi berikutnya.
Membatasi rencana hingga 10 beban kerja mendorong kelincahan dan penyelarasan prioritas saat kriteria bisnis berubah. Pendekatan ini juga memungkinkan tim adopsi cloud untuk mempelajari dan menyempurnakan perkiraan. Yang paling penting, ini menghapus perencanaan yang luas sebagai penghalang untuk perubahan bisnis yang efektif.
Apa itu beban kerja?
Dalam adopsi cloud, beban kerja adalah kumpulan aset TI (server, VM, aplikasi, data, atau appliance) yang secara kolektif mendukung proses yang ditentukan. Beban kerja dapat mendukung lebih dari satu proses. Beban kerja juga dapat bergantung pada aset bersama lainnya atau platform yang lebih besar. Namun, beban kerja harus memiliki batasan yang telah ditentukan mengenai aset dependen dan proses yang bergantung pada beban kerja. Seringkali, beban kerja dapat divisualisasikan dengan memantau lalu lintas jaringan di antara aset TI.
Prasyarat
Input strategis dari daftar prasyarat membuat penyelesaian tugas berikut jauh lebih mudah dikelola. Untuk bantuan mengumpulkan data yang dibahas dalam artikel ini, tinjau prasyaratnya.
Prioritas beban kerja awal
Selama proses rasionalisasi inkremental, tim Anda harus menyetujui pendekatan Power of 10 yang terdiri dari 10 beban kerja prioritas. Beban kerja ini berfungsi sebagai batas awal untuk perencanaan adopsi.
Misalkan Anda memutuskan bahwa rasionalisasi real estat digital tidak diperlukan. Dalam hal ini, kami menyarankan agar tim adopsi cloud dan tim strategi cloud menyetujui daftar 10 aplikasi untuk berfungsi sebagai fokus awal migrasi. Kami menyarankan agar 10 beban kerja ini berisi campuran beban kerja sederhana (kurang dari 10 aset dalam penyebaran mandiri) dan beban kerja yang lebih kompleks. 10 beban kerja tersebut memulai proses prioritas beban kerja.
Catatan
Pendekatan Power of 10 berfungsi sebagai batas perencanaan awal, memfokuskan energi dan investasi dalam analisis tahap awal. Namun, menganalisis dan mendefinisikan beban kerja kemungkinan menyebabkan perubahan dalam daftar beban kerja prioritas.
Menambahkan beban kerja ke rencana adopsi cloud Anda
Pada artikel sebelumnya, rencana adopsi Cloud dan Azure DevOps, Anda membuat rencana adopsi cloud di Azure DevOps.
Anda sekarang dapat mewakili beban kerja dalam daftar Power of 10 di rencana adopsi cloud Anda. Cara termudah untuk melakukan ini adalah melalui pengeditan massal di Microsoft Excel. Untuk menyiapkan stasiun kerja Anda untuk pengeditan massal, lihat Menambahkan atau memodifikasi item kerja secara massal dengan Microsoft Excel.
Langkah 5 dalam artikel tersebut memberitahu Anda untuk memilih Daftar input. Sebagai gantinya, pilih Daftar kueri. Kemudian, dari daftar menu menurun Pilih Kueri, pilih kueri Templat Beban Kerja. Kueri tersebut memuat semua upaya yang terkait dengan migrasi satu beban kerja ke spreadsheet Anda.
Setelah item kerja untuk templat beban kerja dimuat, ikuti langkah-langkah berikut untuk mulai menambahkan beban kerja baru:
- Salin semua item dengan tag Templat Beban Kerja di kolom paling kanan.
- Tempel baris yang disalin di bawah item baris terakhir dalam tabel.
- Ubah sel judul untuk fitur baru dari Templat Beban Kerja ke nama beban kerja baru Anda.
- Tempel sel nama beban kerja baru ke kolom tag untuk semua baris di bawah fitur baru. Berhati-hatilah untuk tidak mengubah tag atau nama baris yang terkait dengan fitur Templat Beban Kerja yang sebenarnya. Saat Menambahkan beban kerja berikutnya ke rencana adopsi cloud, Anda memerlukan item kerja tersebut.
- Lewati ke langkah 8 dalam instruksi pengeditan massal untuk menerbitkan lembar kerja. Langkah ini membuat semua item kerja yang diperlukan untuk memigrasikan beban kerja Anda.
Ulangi langkah 1 hingga 5 untuk setiap beban kerja dalam daftar Daya 10.
Menentukan beban kerja
Setelah menentukan prioritas awal dan menambahkan beban kerja ke rencana, tentukan setiap beban kerja melalui analisis kualitatif yang lebih dalam. Sebelum menyertakan beban kerja apa pun dalam rencana adopsi cloud, cobalah untuk menyediakan poin data berikut untuk setiap beban kerja.
Input bisnis
| Poin data | Deskripsi | Input |
|---|---|---|
| Nama beban kerja | Disebut apakah beban kerja ini? | |
| Deskripsi beban kerja | Dalam satu kalimat, apa yang dilakukan beban kerja ini? | |
| Motivasi adopsi | Motivasi adopsi cloud mana yang terpengaruh oleh beban kerja ini? | |
| Sponsor utama | Dari para pemangku kepentingan yang terkena dampak, siapa sponsor utama yang meminta motivasi sebelumnya? | |
| Dampak bisnis | Apa dampak bisnis dari beban kerja ini? | |
| Dampak aplikasi | Apa dampak aplikasi ini terhadap proses bisnis? | |
| Dampak data | Apa dampak data terhadap bisnis? | |
| Unit bisnis | Unit bisnis mana yang bertanggung jawab atas biaya beban kerja ini? | |
| Proses bisnis | Proses bisnis mana yang akan terpengaruh oleh perubahan beban kerja? | |
| Tim bisnis | Tim bisnis mana yang akan terpengaruh oleh perubahan? | |
| Pemangku kepentingan bisnis | Apakah ada eksekutif yang bisnisnya akan terpengaruh oleh perubahan? | |
| Hasil bisnis | Bagaimana bisnis akan mengukur keberhasilan upaya ini? | |
| Metrik | Metrik apa yang akan digunakan untuk melacak kesuksesan? | |
| Kepatuhan | Apakah ada persyaratan kepatuhan pihak ketiga untuk beban kerja ini? | |
| Pemilik aplikasi | Siapa yang bertanggung jawab atas dampak bisnis dari setiap aplikasi yang terkait dengan beban kerja ini? | |
| Periode pembekuan bisnis | Apakah ada waktu ketika bisnis tidak akan mengizinkan perubahan? | |
| Geografi | Apakah ada geografi yang terpengaruh oleh beban kerja ini? | |
| Keberlanjutan | Pertimbangan keberlanjutan dan efisiensi cloud apa yang telah diperhitungkan untuk beban kerja ini? |
Input teknis
| Poin data | Deskripsi | Input |
|---|---|---|
| Pendekatan adopsi | Apakah adopsi ini merupakan kandidat untuk migrasi atau inovasi? | |
| Prospek ops aplikasi | Cantumkan pihak-pihak yang bertanggung jawab atas performa dan ketersediaan beban kerja ini. | |
| SLA | Buat daftar perjanjian tingkat layanan (persyaratan RTO / RPO). | |
| Kekritisan | Buat daftar kritikalitas aplikasi saat ini. | |
| Klasifikasi data | Buat daftar klasifikasi sensitivitas data. | |
| Geografi operasi | Buat daftar setiap geografi tempat beban kerja berada atau harus dihosting. | |
| Aplikasi | Tentukan daftar awal atau jumlah setiap aplikasi yang termasuk dalam beban kerja ini. | |
| VM | Tentukan daftar awal atau jumlah setiap VM atau server yang termasuk dalam beban kerja. | |
| Sumber data | Tentukan daftar awal atau jumlah setiap sumber data yang termasuk dalam beban kerja. | |
| Dependensi | Buat daftar setiap dependensi aset yang tidak termasuk dalam beban kerja. | |
| Geografi lalu lintas pengguna | Mencantumkan geografi dengan kumpulan lalu lintas pengguna yang signifikan. |
Konfirmasi prioritas
Berdasarkan data yang dirakit, strategi cloud dan tim adopsi harus dipenuhi untuk mengevaluasi kembali prioritas. Klarifikasi poin data bisnis mungkin mendorong perubahan prioritas. Dependensi atau kompleksitas teknis dapat mengakibatkan perubahan yang terkait dengan alokasi kepegawaian, garis waktu, atau pengurutan upaya teknis.
Setelah peninjauan, kedua tim harus merasa nyaman dengan mengkonfirmasi prioritas yang dihasilkan. Serangkaian prioritas yang terdokumentasi, tervalidasi, dan terkonfirmasi ini adalah backlog adopsi cloud yang diprioritaskan.
Langkah berikutnya
Untuk setiap beban kerja dalam backlog adopsi cloud yang diprioritaskan, tim sekarang siap untuk menyelaraskan aset.
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk