Membuat kasus bisnis terarah - AWS Panduan Preskriptif

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Membuat kasus bisnis terarah

Pemangku kepentingan dari seluruh bisnis harus memahami dan membeli ke dalam kasus bisnis untuk transformasi setiap langkah di sepanjang jalan.

Pada tahap awal, penting untuk dengan cepat menunjukkan nilai potensial yang cukup dari program migrasi, sehingga Anda dapat mengamankan sumber daya yang dibutuhkan untuk merencanakan dan membuat program. Kasus bisnis terarah dirancang untuk memberikan kepercayaan yang masuk akal dalam mencapai nilai bisnis yang menarik dengan data terbatas yang dapat dikumpulkan lebih awal.

Setelah program ditetapkan, kasus bisnis dikembangkan lebih lanjut. Kasus terperinci memberikan akurasi yang lebih besar, gambaran yang lebih lengkap tentang nilai program, dan wawasan tentang prioritas perencanaan. Ini mendefinisikan dan mengukur hasil bisnis yang direncanakan yang dibeli organisasi, dan menetapkan dasar di mana kantor tata kelola program Anda kemudian dapat mengarahkan program dan mengukur pencapaiannya.

Memperbaiki ruang lingkup kasus bisnis terarah

Kasus bisnis terarah biasanya dirakit dengan cepat, dalam 2-4 minggu. Ini perlu menghasilkan kepercayaan diri yang cukup sehingga Anda dapat mengamankan sumber daya untuk membentuk tim inti, melibatkan AWS Mitra jika diperlukan, dan seminimal mungkin, menyelesaikan penilaian aplikasi yang diprioritaskan dan analisis portofolio dan tahap perencanaan migrasi.

Biasanya, kasus bisnis terarah yang mendukung migrasi portofolio dibuat sebagai salah satu dari berikut ini:

  • Perbandingan biaya kepemilikan total (TCO) sederhana antara lanskap infrastruktur apa adanya dan arsitektur layanan pasca-migrasi AWS . Perbandingan menunjukkan perbedaan laju lari yang diharapkan untuk volume beban kerja tertentu.

  • Kasus bisnis yang menunjukkan nilai sekarang bersih (NPV), laba atas investasi (ROI), periode pengembalian modal, tingkat pengembalian internal yang dimodifikasi (MIRR) dan analisis arus kas 3-5 tahun untuk bermigrasi ke AWS inklusif biaya migrasi vs tetap apa adanya.

Lingkup kasus bisnis terarah biasanya terbatas pada salah satu dari berikut ini:

  • Perbandingan biaya teknologi infrastruktur

  • Perbandingan teknologi infrastruktur dan biaya operasi

Secara umum, semakin besar portofolio, semakin kurang berkembang kasusnya. Ini karena asumsi yang lebih luas dapat dibuat tanpa mempengaruhi hasilnya secara signifikan. Untuk portofolio yang lebih kecil, setiap perubahan akan memiliki dampak yang lebih besar, sehingga diperlukan lebih banyak detail.

Mulailah dengan membangun perbandingan biaya infrastruktur dasar. Kemudian putuskan apakah perbandingannya cukup menarik sebelum Anda melanjutkan. Biasanya, portofolio lebih dari 400 server akan menunjukkan kasus bisnis yang positif pada pengurangan biaya infrastruktur saja dalam waktu 3 tahun beroperasi AWS, atau 250 server dalam 5 tahun, meskipun ini dapat bervariasi. Untuk portofolio yang lebih kecil, detail lebih lanjut mungkin diperlukan.

Sebaliknya, jarang berguna untuk memeriksa komponen nilai bisnis lainnya pada tahap ini, seperti nilai yang berasal dari peningkatan ketahanan atau kelincahan bisnis, kecuali total ruang lingkup migrasi kurang dari sekitar 5 beban kerja atau 50 server.

Driver nilai fokus

Perbandingan TCO teknologi infrastruktur membandingkan model biaya infrastruktur apa adanya dengan model dasar tagihan AWS layanan bahan yang dibutuhkan untuk menjalankan beban kerja Anda dengan kinerja dan ketersediaan yang setara. Banyak optimasi dapat dilakukan. Pada tahap ini, bagaimanapun, fokusnya adalah pada daftar berikut karena mereka lebih mudah untuk menilai dan biasanya menghasilkan sekitar 30 persen penghematan TCO, yang cukup untuk bergerak maju:

  • Compute elastisitas — Server peta yang penggunaannya tidak 100 persen, seperti server pengembangan atau UAT yang menjalankan 8x5 (penggunaan 24 persen), 10x5 (30 persen), atau 10x6 (36 persen), dan server pemulihan bencana (DR) yang berjalan pada 2 persen, untuk layanan sesuai permintaan yang hanya ditagih saat digunakan.

  • Pengadaan dengan rencana penghematan - Rencanakan untuk mendapatkan server produksi dan server lain dengan penggunaan tinggi (lebih dari 36 persen) dengan rencana penghematan yang sesuai untuk mengurangi biaya hingga 75 persen. Opsi termasuk komitmen 1 tahun dan 3 tahun, dengan tingkat pembayaran di muka yang berbeda untuk mendapatkan diskon yang lebih besar.

  • Hapus zombie — Identifikasi server dengan pemanfaatan CPU kurang dari 2 persen yang dapat Anda konfirmasi tidak lagi diperlukan, dan hapus dari analisis biaya.

  • Hitung ukuran kanan — Gunakan data deret waktu pemanfaatan CPU dan memori untuk menilai setiap server daya komputasi dan memori yang dibutuhkan. Kemudian pilih instans Amazon Elastic Compute Cloud (Amazon EC2) agar sesuai.

  • Sistem manajemen basis data relasional (RDBMS) lisensi ukuran kanan - Menilai kembali kebutuhan lisensi RDBMS Anda setelah menghitung ukuran kanan pada server database Anda, bandingkan Bring Your Own License (BYOL) dan lisensi Pengadaan dari, dan jelajahi AWS potensi Amazon Relational Database Service (Amazon RDS) untuk meningkatkan penghematan.

  • Penyimpanan — Ukuran yang tepat total volume penyimpanan yang dibutuhkan, dan mengidentifikasi kebutuhan operasi input/output per detik (IOPS) di seluruh portofolio. Tentukan berapa banyak yang dapat dipindahkan ke penyimpanan objek dengan SLA dan biaya yang berbeda.

Kebutuhan data

Tabel dalam Memahami persyaratan data penilaian awal menunjukkan data yang diperlukan untuk membangun setiap bagian dari kasus bisnis terarah, dan apakah itu wajib atau opsional.

Untuk membangun kasus ini, Anda memerlukan subset infrastruktur dari data perencanaan awal ditambah data biaya. Menentukan cara mengidentifikasi infrastruktur yang akan disertakan tergantung pada tujuan bisnis Anda:

  • Jika tujuan program adalah untuk memigrasi dan memodernisasi aplikasi tertentu, bangun portofolio infrastruktur berdasarkan apa yang dibutuhkan aplikasi, dengan mempertimbangkan infrastruktur yang dibagikan.

  • Jika tujuan program adalah infrastruktur-sentris, seperti migrasi keluar dari pusat data yang sewa akan kedaluwarsa, pemetaan aplikasi tidak diperlukan untuk perbandingan TCO infrastruktur.

Data yang ditandai sebagai opsional (seperti CPU dan pemanfaatan puncak memori untuk server) biasanya dapat diganti dengan nilai benchmark standar. Anda dapat mendiskusikan hal ini dengan AWS Mitra atau Layanan AWS Profesional. Atau Anda dapat memperkirakan nilai dari titik data yang tersedia di bagian portofolio Anda (seperti data yang dikumpulkan oleh hypervisor). Semakin besar portofolio, semakin akurat ini.

Membangun infrastruktur perbandingan TCO

Alat sangat penting untuk membangun perbandingan TCO infrastruktur. AWS Layanan Profesional atau AWS Mitra dapat memberikan bantuan dengan semua jenis kasus terarah, terutama jika Anda berencana untuk melibatkan mereka untuk membantu dalam proses migrasi yang lebih luas.

Ada alat yang tersedia untuk melakukan hal berikut:

  • Kumpulkan data inventaris.

  • Kumpulkan data pemanfaatan.

  • Menyediakan data benchmarking biaya infrastruktur yang akurat.

  • Identifikasi dan hapus zombie.

  • Buat penilaian ukuran yang tepat.

  • Merekomendasikan opsi pembelian.

  • Bandingkan opsi lisensi perangkat lunak.

  • Menghasilkan analisis arus kas grafis sederhana.

Migration Evaluator dari AWS adalah salah satu pilihan. Ini menyediakan semua kemampuan ini sebagai layanan terkelola gratis. Anda dapat meminta Penilai Migrasi melalui manajer AWS akun atau Mitra Kompetensi AWS Migrasi atau dengan mengirimkan permintaan secara online. Migration Evaluator telah dirancang khusus sebagai solusi titik untuk menghasilkan perbandingan TCO teknologi infrastruktur dan cepat.

Keuntungan utama:

  • Bebas biaya

  • Penemuan tanpa agen atau konfigurasi manual data inventaris di mana penemuan berbasis alat dibatasi

  • Dukungan khusus untuk membantu penyebaran, konfigurasi, pengumpulan data, dan membangun kasus dasar, atau kasus bisnis terarah

  • Kenyamanan operasi SaaS, tetapi dapat menjalankan pengumpulan data sepenuhnya dalam jaringan pelanggan untuk mendukung scrubbing sebelum memuat ke mesin analitik

  • Dukungan kuat untuk ukuran kanan lisensi Microsoft

  • Kemampuan ekspor data lengkap

Keterbatasan utama:

  • Menilai hanya server arsitektur x86 (Windows dan Linux)

  • Opsi terbatas untuk mengonfigurasi atau mengkalibrasi data biaya apa adanya benchmark

  • Tidak ada dukungan untuk pengoptimalan biaya operasi pemodelan

  • Tidak ada dukungan untuk pemodelan biaya migrasi

  • Tidak ada dukungan langsung untuk membangun kasus bisnis di luar perbandingan TCO

Jika Anda memutuskan untuk menggunakan alat penemuan komersial untuk penemuan portofolio dan kemampuan analisis seperti tumpukan aplikasi dan penemuan interdependensi, biasanya akan memberikan perbandingan TCO infrastruktur juga. Untuk panduan tentang penggunaan alat untuk penemuan dan penilaian portofolio, lihat Mengevaluasi kebutuhan alat penemuan.

Membangun optimalisasi biaya operasional

Peningkatan produktivitas operasi TI seringkali merupakan kontributor nilai yang signifikan untuk migrasi. Rata-rata, setelah migrasi ke AWS, produktivitas staf operasional TI meningkat sebesar 62 persen melalui migrasi, menurut whitepaper International Data Corporation (IDC) Fostering Business and Organizational Transformation to Generate Business Value with Amazon Web Services. Namun, ada dua tantangan dengan ukuran dan termasuk manfaat ini dalam kasus terarah.

Pertama, menilai berbagai keuntungan produktivitas membutuhkan pengumpulan data yang ekstensif dan lebih tepat untuk kasus bisnis yang terperinci. Tantangan ini dapat diatasi dengan berfokus pada beberapa elemen yang lebih mudah dinilai dan diukur dengan data benchmark sederhana tetapi masih menunjukkan keuntungan yang signifikan.

Kedua, berfokus pada produktivitas sebagai sumber pengurangan biaya dapat menimbulkan kekhawatiran dan negativitas di antara pemangku kepentingan pelanggan utama dan anggota program. Pastikan bahwa Anda memberikan kejelasan tentang bagaimana manfaat akan direalisasikan dan apa artinya bagi orang-orang yang terkena dampak. Masalah seperti itu dapat dihindari dengan mengklarifikasi bahwa ini hanya akan meningkatkan peran tim:

  • Program migrasi mencakup jalur untuk mengembangkan dan memindahkan staf operasi internal ke peran baru, seperti bergabung dengan DevSecOps tim yang membangun infrastruktur sebagai otomatisasi kode dan otomatisasi pengujian yang akan mendorong pertumbuhan tim.

  • Manfaat dapat direalisasikan dengan mengubah dan mengubah ukuran kontrak outsourcing operasi, sehingga staf internal dapat meningkatkan fokus mereka pada kegiatan yang bernilai lebih tinggi

Pendekatan membangun elemen kasus bisnis ini berdasarkan transformasi operasi apa yang ingin Anda pertimbangkan:

  • Jika Anda memiliki tim operasi internal yang ada, tingkatkan keterampilan anggota tim, dan tunjukkan peningkatan produktivitas yang diharapkan.

  • Atau, bermigrasi dari solusi operasi Anda saat ini ke AWS Managed Services (AMS) atau ke penawaran layanan terkelola alternatif dari AWS Partner.

Untuk transformasi pertama, untuk mendapatkan perkiraan keuangan konservatif dari peningkatan produktivitas yang dapat dimasukkan dalam kasus ini, kami merekomendasikan yang berikut:

  1. Fokus pada produktivitas operasi manajemen server secara khusus. Ini cenderung menjadi proporsi yang signifikan dari upaya operasi, dapat lebih mudah dinilai, dan lebih mudah diverifikasi nanti.

  2. Hitung kepegawaian yang dibutuhkan berdasarkan tolok ukur jumlah server yang dapat dikelola oleh setiap karyawan full-time equivalent (FTE). Di tempat, jumlah itu sekitar 150 severs. Pada AWS, itu sekitar 400 server.

  3. Terapkan metrik ini ke jumlah server lokal dibandingkan dengan jumlah instans EC2.

  4. Lipat gandakan waktu yang dihemat dengan tingkat biaya campuran untuk seluruh tim operasi.

Anda kemudian dapat memeriksa hasil Anda dengan salah satu pendekatan dengan memverifikasi hasilnya tidak jauh melebihi perolehan produktivitas rata-rata berdasarkan peran yang disediakan dalam tabel berikut (data yang bersumber dari whitepaper IDC Mendorong Bisnis dan Transformasi Organisasi untuk Menghasilkan Nilai Bisnis dengan Amazon Web Services.

Peran

Keuntungan Efisiensi

Manajemen infrastruktur TI

62%

Dukungan TI

59%

Manajemen aplikasi

43%

Pengelolaan basis data

19%

Pengembangan aplikasi

25%

Untuk transformasi kedua, Anda dapat menambahkan penghematan biaya operasional dengan langsung membandingkan total operasi saat ini dan biaya dukungan untuk portofolio dalam ruang lingkup dengan biaya layanan terkelola yang dipertimbangkan.

Untuk mendapatkan biaya layanan terkelola, berikan kepada manajer AWS akun atau AWS Managed Services Mitra Anda dengan AWS Bill of Material yang Anda usulkan, pilihan tingkat layanan Anda (Plus atau Premium), dan paket AMS Anda (AMS Accelerate atau AMS Advanced). Ini akan memberi Anda total biaya layanan terkelola untuk komponen AWS layanan dari solusi yang diubah. Demikian pula, Anda dapat memperoleh harga dari AWS Mitra yang menawarkan paket layanan terkelola sendiri berdasarkan parameternya sendiri.

Memperluas ke kasus bisnis terarah penuh

Secara umum, untuk merakit kasus bisnis terarah penuh, membangun perbandingan TCO, dengan atau tanpa elemen produktivitas TI, dan perkirakan semua biaya migrasi dan modernisasi. Kemudian buat arus kas yang mencakup pasangan t-migrate-and-modernize skenario migrate-and-modernize dan jangan.

Kasus yang paling mendasar adalah persiapan sepasang skenario, di mana t-migrate-and-modernize skenario jangan adalah situasi Anda saat ini dan migrate-and-modernize skenario memiliki karakteristik sebagai berikut:

  • Tidak ada pertumbuhan atau penyusutan volume transaksional, komputasi, atau kapasitas jaringan

  • Pertumbuhan volume rendah yang stabil dalam persyaratan penyimpanan

  • uality-of-service Kemampuan Q (seperti ketersediaan, daya tahan, throughput, dan kinerja) yang sesuai dengan kemampuan sistem yang ada

Untuk semua kecuali portofolio yang sangat kecil, ini sesuai dengan tujuan membangun kasus terarah dengan baik. Ini menunjukkan nilai yang cukup cepat untuk mendapatkan mandat untuk bergerak maju.

Untuk portofolio yang lebih kecil, akan bermanfaat untuk menambahkan pasangan t-migrate-and-modernize skenario migrate-and-modernize dan jangan yang menunjukkan aspek lain dari peningkatan nilai migrasi cloud, seperti:

  • Campuran persyaratan pertumbuhan kapasitas sedang dan tinggi di seluruh beban kerja di mana pertumbuhan itu diharapkan

  • Dimasukkannya ketahanan yang ditingkatkan, seperti ketersediaan tinggi, DR, dan toleransi kesalahan

  • Peningkatan kinerja global dengan komputasi tepi, jaringan pengiriman konten (CDN), replikasi database multi-wilayah.

  • Kualitas layanan spesifik lainnya yang telah Anda jadikan prioritas bisnis untuk program ini

Untuk skenario ini, pastikan bahwa biaya dan implikasi arus kas dari peningkatan arsitektur infrastruktur non-cloud saat ini agar sesuai dengan spesifikasi baru diperkirakan secara akurat. Cara paling langsung untuk mendapatkan perkiraan ini dapat meminta kutipan dari integrator sistem, terutama jika mereka juga merupakan Mitra AWS Konsultasi dengan Kompetensi Migrasi, yang dapat mendukung Anda dengan skenario migrate-and-modernize dan tidak. t-migrate-and-modernize

Untuk setiap pasangan skenario, kumpulkan kasus yang terdiri dari hal-hal berikut:

  • Biaya t-migrate-and-modernize skenario don '. Dalam kasus yang paling mendasar, ini termasuk:

    • Total biaya kepemilikan selama jangka waktu kasus bisnis untuk konfigurasi infrastruktur saat ini

    • Peningkatan berkala dalam komputasi, penyimpanan, dan konsumsi lalu lintas jaringan

  • Biaya skenario migrate-and-modernize;, termasuk:

    • Menyiapkan program, yang mencakup penemuan terperinci, perencanaan migrasi, pengembangan kasus bisnis terperinci, pembentukan tim inti dan peningkatan keterampilan mereka, membangun landing zone jika belum ada, dan membangun manajemen keamanan dan integrasi operasi untuk beban kerja yang bermigrasi

    • Biaya migrasi dan modernisasi beban kerja

    • Biaya infrastruktur migrasi, termasuk koneksi jaringan, layanan migrasi data seperti AWS Snowball dan AWS DataSync, dan biaya AWS utilitas untuk arsitektur yang diperlukan selama proses migrasi itu sendiri (misalnya, untuk pengujian)

    • Peningkatan biaya AWS utilitas selama migrasi saat gelombang ditayangkan, dan menurunnya biaya infrastruktur yang ada karena digantikan oleh layanan AWS berbasis dan dinonaktifkan

Biaya penonaktifan dan penghapusan untuk setiap aset yang terdampar

Memperkirakan pengaturan program migrasi dan modernisasi

Untuk menyiapkan program untuk sukses, Anda mungkin perlu menjalankan serangkaian kegiatan dasar untuk membangun kemampuan dasar dan rencana terperinci jika ini belum dilakukan sebelumnya. Kegiatan dasar ini meliputi:

  1. Melakukan penemuan portofolio terperinci, perencanaan migrasi, dan pengembangan kasus bisnis terperinci, seperti yang dijelaskan di bagian Analisis portofolio dan perencanaan migrasi, ditambah pendokumentasian biaya alat penemuan apa pun yang digunakan.

  2. Membangun bisnis cloud dan tim inti teknis dan mengembangkan keterampilan internal melalui pelatihan dan perekrutan. Identifikasi anggota organisasi TI yang akan membutuhkan pelatihan, dan alokasikan anggaran pelatihan untuk setiap orang.

  3. Menetapkan landing zone dan mengonfigurasinya untuk mendukung kemampuan tata kelola biaya, operasional, dan keamanan yang Anda perlukan.

AWS Mitra Konsultasi dapat membantu memberikan perkiraan untuk item 1 dan 3.

Memperkirakan biaya migrasi dan modernisasi

Untuk memenuhi tujuan kasus bisnis terarah dan menunjukkan potensi komersial yang cukup untuk melanjutkan ke fase berikutnya, pertahankan estimasi biaya migrasi dan modernisasi sedasar mungkin.

Untuk tujuan ini, kami menyarankan Anda menyiapkan kasus bisnis terarah dengan berfokus pada aplikasi yang termasuk dalam strategi migrasi berikut:

  • Pensiun

  • Mempertahankan

  • Pindah

  • Rehost

  • Platform Ulang

  • Pembelian kembali

Biasanya, sekitar 70 persen beban kerja dapat direhost, dipindahkan atau direplatform, dan 5 persen lainnya dapat dihentikan. Menilai aplikasi dengan strategi migrasi biasanya membahas inti dari kasus pengurangan biaya.

Memperkirakan biaya untuk refactoring, atau re-architecting, bisa jadi rumit. Hal ini tidak praktis untuk mencoba ini dalam jangka waktu yang diberikan untuk mempersiapkan kasus bisnis terarah. Seperti yang dibahas sebelumnya dalam Menentukan tipe R untuk migrasi, pertimbangkan untuk menggunakan strategi rehost, relokasi, atau replatform untuk fase pertama migrasi dan modernisasi Anda. Strategi R ini kemungkinan akan mempercepat pengembalian awal, mengurangi risiko implementasi, dan meningkatkan kasus bisnis dalam jangka pendek. Hal ini juga secara material lebih mudah bagi tim aplikasi Anda untuk memodernisasi aplikasi yang berjalan dalam AWS lingkungan daripada yang tidak. Perkiraan untuk refactoring (re-architecting) aplikasi spesifik paling baik ditambahkan ketika kasus bisnis terperinci disiapkan.

Memperkirakan upaya migrasi dengan strategi

Setiap migrasi berbeda. Sebelum melakukan anggaran atau rencana apa pun, perkiraan beban kerja benih untuk aktivitas migrasi dari tim yang akan bertanggung jawab atas proyek, apakah itu tim aplikasi internal Anda, Layanan AWS Profesional, atau organisasi Mitra. AWS

Untuk membantu membangun kasus terarah, tabel berikut memberikan rentang upaya indikatif untuk perawatan yang berbeda. Rentang ini mengasumsikan bahwa medium-to-large portofolio sedang dimigrasikan dan tim migrasi dilatih dan berpengalaman. Untuk portofolio kecil, yang terbaik adalah meminta tim yang bertanggung jawab atas migrasi menyiapkan perkiraan bahkan untuk kasus terarah.

Strategi migrasi Proses estimasi Elemen Jam orang Jam orang
Mempertahankan Jangan melakukan apa-apa, tanpa biaya, tanpa manfaat, dan tidak ada pengurangan hutang teknologi.

Pensiun Perkirakan penonaktifan peralatan perangkat keras yang digunakan, jika ada.

Pindah Perkirakan menyalin beban kerja dalam VMware menggunakan alat VMware. Ini termasuk menyalin data, pengujian asap untuk memverifikasi, dan penonaktifan perangkat keras apa pun. Upaya untuk merelokasi VM biasanya kurang dari pola rehost dengan kompleksitas rendah.

Rehost Perkirakan penyalinan beban kerja dan data dengan salinan gambar, pengujian asap, pengujian ketersediaan tinggi (HA) dan pemulihan bencana (DR) jika sesuai untuk server produksi, dan penonaktifan perangkat keras apa pun. Praktik terbaik adalah menggunakan alat seperti Layanan Migrasi AWS Aplikasi. Bagilah beban kerja menjadi kompleksitas rendah, sedang, dan tinggi, berdasarkan faktor-faktor seperti apakah database atau perangkat lunak infrastruktur lainnya berjalan, kompleksitas basis data, apakah dikelompokkan, kompleksitas integrasi, dan volume data. Upaya per aplikasi per server Migrasi: Tes HA/DR
Rendah 10—14 3—5
Sedang 16—24 4—6
Tinggi 26—38 8—12
Platform Ulang Untuk migrasi replatform yang mencakup peningkatan ke sistem operasi atau versi RDBMS, ambil perkiraan untuk rehost, dan tambahkan waktu untuk menjalankan uji pembangunan kembali dan asap pada platform baru. Jika replatform termasuk mengubah teknologi platform, perkirakan waktu tambahan untuk penggunaan alat konversi, seperti dan, dan pengujian aplikasi yang lebih lengkap. AWS Schema Conversion ToolAWS Database Migration Service Contoh perubahan teknologi adalah bermigrasi dari database komersial berpemilik ke pengganti open source. Upaya per aplikasi per server Versi naik Perubahan teknologi
Rendah Tambahkan 1-3 Tambahkan 10—15
Sedang Tambahkan 2—5 Tambahkan 20—30
Tinggi Tambahkan 4-8 Tambahkan 40-60
Pembelian kembali Perkirakan ekstraksi data, transformasi, dan pengunggahan ke dalam penggantian layanan SaaS yang baru dibeli, dan penonaktifan perangkat keras apa pun.

Memperkirakan biaya infrastruktur migrasi

Sertakan perkiraan untuk infrastruktur yang akan Anda gunakan selama migrasi. Biasanya, perkiraan ini terdiri dari:

  • Anggaran untuk konektivitas dan layanan pertukaran data untuk beban kerja dan migrasi data dari lingkungan saat ini ke AWS

  • Anggaran untuk AWS layanan (terutama komputasi dan penyimpanan) yang diperlukan untuk menghosting beban kerja yang dimigrasi selama proses migrasi, pengujian, dan pemotongan

  • Peningkatan biaya AWS utilitas karena setiap gelombang migrasi selesai

  • Biaya penonaktifan infrastruktur yang ada yang tidak akan lagi menjalankan beban kerja yang dimigrasi

Untuk pertukaran data, periksa total volume data Anda dan nilai kelayakan menggunakan jaringan. Jika Anda telah menyediakan AWS Direct Connecttautan atau AWS VPNdari AWS satu titik di WAN Anda sebelumnya untuk penggunaan operasional setelah migrasi, Anda dapat menggunakan sumber daya tersebut hingga kuota layanannya.

Jika kapasitas jaringan Anda tidak mencukupi, peningkatan bandwidth internet jangka pendek dengan jaringan pribadi virtual (VPN) seringkali merupakan solusi yang sangat hemat biaya. Jika tidak, perangkat pertukaran AWS media seperti AWS Snowball dan AWS Snowcone menawarkan solusi di sebagian besar Wilayah. AWS Juga, untuk migrasi data volume sangat tinggi, pertimbangkan untuk memasukkan anggaran untuk AWS DataSync, yang meningkatkan keandalan dan dapat mempercepat transfer terlepas dari media yang digunakan.

Memodelkan peningkatan AWS layanan dan menuruni infrastruktur yang ada penting untuk elemen analisis arus kas dari kasus bisnis. Pada tahap ini, Anda tidak mungkin memiliki rencana gelombang untuk menentukan dengan tepat kapan biaya akan dikeluarkan. Sebaiknya lakukan hal berikut:

  • Meningkatkan biaya untuk AWS pada tingkat konstan selama migrasi.

  • Mengurangi biaya untuk infrastruktur yang ada yang Anda rencanakan untuk dinonaktifkan pada tingkat konstan selama durasi yang sama.

Memulai kenaikan AWS biaya 1-2 bulan sebelum infrastruktur yang ada turun. Ini menyediakan 1 bulan penggunaan AWS utilitas untuk melakukan migrasi untuk setiap gelombang. Ini termasuk waktu untuk pengujian, dan waktu tambahan untuk menyelesaikan pekerjaan penonaktifan yang diperlukan untuk menghentikan biaya pada infrastruktur yang diganti.

Memperkirakan biaya penonaktifan

Menonaktifkan peralatan yang tidak dapat dipindahkan, dan membuangnya dengan cara yang legal dan ramah lingkungan, dapat menimbulkan biaya kecil. Namun, untuk kasus bisnis terarah, biasanya satu-satunya jumlah material yang berpotensi adalah biaya penghapusan nilai buku yang tersisa dari aset yang diganti.

Untuk kasus bisnis terarah, kami sarankan Anda melakukan hal berikut:

  • Tinjau daftar aset Anda.

  • Identifikasi mereka yang akan dinonaktifkan.

  • Untuk mengurangi penghapusan, periksa peluang untuk beralih perangkat sehingga perangkat yang lebih baru dalam daftar dapat digunakan untuk menggantikan aset yang lebih tua dan lebih terdepresiasi sepenuhnya.

  • Buat penilaian nilai buku future dari aset yang akan dinonaktifkan pada saat itu.

  • Sertakan ini sebagai biaya migrasi penonaktifan.

Merakit dan menyesuaikan kasus bisnis terarah penuh

Setelah Anda menyiapkan set lengkap biaya untuk setiap pasangan skenario, buatlah laporan arus kas diskon untuk masing-masing dan buat grafik. Kami merekomendasikan untuk membangun kasus bisnis terarah selama periode yang sama dengan siklus penyegaran perangkat keras. Ini biasanya 5 tahun untuk server, penyimpanan, dan perangkat jaringan. Saat Anda menggunakan periode yang sama dengan siklus penyegaran perangkat keras, biaya tepat satu penyegaran disertakan dalam biaya apa adanya untuk setiap skenario.

Kemudian hitung metrik keuangan utama yang Anda butuhkan untuk mendapatkan persetujuan untuk pindah ke fase berikutnya dari program. Kami biasanya menyertakan yang berikut:

  • Net present value (NPV) untuk mengukur nilai absolut dari pengurangan biaya dan keuntungan produktivitas yang dinilai

  • Periode pengembalian modal dalam beberapa bulan untuk memverifikasi bahwa pengembalian cukup cepat

  • Perbandingan run-rate akhir untuk memverifikasi apakah proses tersebut mengeluarkan biaya yang cukup selama jangka waktu tersebut

  • Pengembalian investasi (ROI) dan tingkat pengembalian investasi yang dimodifikasi (MIRR) untuk menilai kinerja keuangan relatif program di atas tuntutan modal lain yang mungkin diprioritaskan organisasi Anda.

Gunakan iterasi pertama kasus untuk menentukan apakah kinerja keuangan yang diharapkan berarti bahwa penyempurnaan harus dilakukan, seperti dalam contoh berikut:

  • Jika pengembalian dana terlalu lambat, pertimbangkan opsi untuk mempercepat dan mengurangi biaya migrasi, seperti berikut ini:

    • Gunakan AWS Mitra atau Layanan AWS Profesional untuk memperluas sumber daya yang tersedia dan selanjutnya memparalelkan beban kerja migrasi dengan pola yang lebih mendasar.

    • Untuk beban kerja yang berjalan di VMware, bandingkan strategi relokasi dengan strategi rehost atau replatform, setidaknya untuk fase awal. Menggunakan strategi relokasi dapat mengurangi biaya migrasi dan meningkatkan kecepatan migrasi.

    • Jika secara teknis layak, dorong beban kerja yang membutuhkan strategi replatform atau refactor (re-architect) yang lebih kompleks ke fase future, di luar lingkup kasus bisnis awal.

  • Jika ROI dan MIRR terlalu rendah, pertimbangkan hal berikut:

    • Apakah skenario yang Anda anggap terlalu konservatif? Apakah Anda memiliki skenario yang mencerminkan pertumbuhan kapasitas dan kebutuhan elastisitas yang paling mungkin? Apakah Anda memiliki skenario yang membandingkan biaya termasuk peningkatan kualitas layanan dalam tujuan Anda?

    • Dapatkah Anda menyempurnakan cakupan portofolio aplikasi yang akan dimigrasikan pada tahap pertama untuk fokus pada beban kerja yang akan menghasilkan pengembalian yang lebih kuat, seperti yang memiliki pemanfaatan arus yang lebih rendah atau kebutuhan pemulihan bencana (DR) yang mahal?

    • Dapatkah menyempurnakan ruang lingkup portofolio aplikasi untuk awalnya mengecualikan beban kerja tertentu yang mencapai kurang komersial? Misalnya, dapatkah Anda menunda beban kerja yang lisensi perangkat lunak pihak ketiga menjadi lebih mahal karena persyaratan yang berbeda untuk penyebaran di infrastruktur cloud publik?

  • Jika perbandingan run-rate akhir tidak memenuhi target yang diharapkan, jelajahi hal berikut:

    • Pertama, konfirmasikan bahwa metrik lainnya memenuhi harapan. Kasus bisnis terarah terutama untuk menunjukkan bahwa ada peluang keuangan yang cukup untuk membenarkan memulai fase persiapan migrasi berikutnya.

    • Identifikasi daftar peluang untuk terus meningkatkan kinerja biaya AWS setelah fase awal migrasi.

Sertakan penilaian daftar peluang saat menyiapkan kasus bisnis terperinci. Selain itu, sertakan penilaian peluang dalam pemeliharaan kasus yang sedang berlangsung dan proses month-to-month pengoptimalan biaya setelah migrasi selesai.