Kasus bisnis terperinci

Pada tahap ini, kami merekomendasikan untuk memvalidasi dan memperluas ruang lingkup kasus bisnis untuk memberikan tingkat detail yang lebih besar untuk mendukung program transformasi. Kasus bisnis terarah awal yang dirakit dengan cepat dirancang untuk memberikan kepercayaan yang cukup untuk berinvestasi dalam langkah-langkah dasar dan tingkat perencanaan terperinci berikutnya.

Mengembangkan kasus bisnis terperinci mendukung proses perencanaan ini dengan cara berikut:

• Memberikan analisis keuangan yang menginformasikan keputusan tentang apa yang harus dimigrasikan dan dimodernisasi, opsi mana yang harus dipilih dan bagaimana melakukan fase dan memprioritaskan pekerjaan

• Memvalidasi, menyempurnakan, dan mengembangkan kasus keuangan terarah asli dengan memeriksa ulang secara rinci:

  • Potensi pengurangan biaya infrastruktur

  • Produktivitas TI internal dan efisiensi operasi outsourcing

  • Perkiraan untuk investasi yang diperlukan untuk pengaturan program, migrasi, dan modernisasi

• Mengidentifikasi, memperkirakan skala, dan menyiapkan proses untuk melacak driver nilai lebih lanjut yang dibawa migrasi

Dalam kasus bisnis terperinci, Anda menetapkan yang berikut:

• Dasar obyektif untuk mengamankan mandat dan investasi untuk melaksanakan setidaknya tahap pertama migrasi

• Harapan kinerja keuangan minimum dasar untuk program

• Kejelasan atas dasar keuangan di mana berbagai desain migrasi dan keputusan prioritas dibuat, sehingga ketika keadaan dan orang-orang berubah selama program, kepemimpinan baru dapat membuat pilihan berdasarkan informasi.

• Wawasan tentang area tambahan pengoptimalan biaya yang akan dieksplorasi setelah data penggunaan awal tersedia saat beban kerja dimigrasikan dan mulai beroperasi

• Perkiraan nilai yang dibawa transformasi cloud ke bisnis dari peningkatan ketahanan dan kelincahan

• Terkait KPIs, metrik, dan asumsi yang digunakan untuk memperkirakan pengembalian finansial dari peningkatan ketahanan dan kelincahan, yang kemudian membentuk dasar untuk mendorong realisasi manfaat utama keluar dari program

Tentukan skenario yang diperlukan untuk kasus ini

Ketika membangun kasus bisnis terperinci, biasanya perlu untuk mengembangkan beberapa skenario untuk mendukung berbagai tujuan yang digunakan untuk kasus bisnis.

Skenario perubahan minimum — Untuk menilai ekspektasi kinerja keuangan minimum, siapkan skenario yang mengasumsikan perubahan minimum yang diharapkan pada status quo. Skenario ini, sebagai skenario terburuk, adalah dukungan yang berguna saat mendapatkan mandat untuk berinvestasi dalam migrasi. Skenario ini memodelkan tingkat pertumbuhan kapasitas minimum yang diharapkan dan perubahan minimum untuk quality-of-service kebutuhan lain, seperti ketersediaan dan ketahanan. Perubahan terkecil menciptakan biaya terendah dan inefisiensi sumber daya paling sedikit untuk model operasi saat ini.

Skenario yang paling mungkin — Untuk menginformasikan strategi program dan keputusan prioritas, siapkan skenario yang mencerminkan apa yang diharapkan bisnis terjadi. Skenario ini harus mencakup kemungkinan pertumbuhan atau pengurangan pemanfaatan puncak dan biaya peningkatan untuk memenuhi permintaan akan kualitas layanan tingkat tinggi (terutama ketersediaan dan ketahanan) dari bisnis.

Skenario spesifik lainnya — Di mana masih perlu untuk membuat asumsi yang dapat berdampak besar pada kasus bisnis, kembangkan skenario baik di mana asumsi itu benar dan di mana tidak. Namun, kami sarankan untuk menjaga jumlah skenario alternatif ini seminimal mungkin. Membuat lebih dari tiga hingga empat skenario secara total memperlambat kemajuan, dan menjadi mahal, membingungkan, dan sulit dipertahankan. Jika memungkinkan, lakukan eksperimen dan bekerja untuk menghilangkan asumsi yang lebih besar.

Memvalidasi dan menyempurnakan infrastruktur dan model biaya migrasi

Setelah Anda menyelesaikan analisis portofolio dan menyiapkan desain dan ukuran target Layanan AWS, perbaiki perkiraan biaya operasional untuk model operasi saat ini (COM) dan model operasi future (FOM) AWS untuk setiap skenario. Biasanya perlu untuk menyempurnakan perkiraan untuk hal-hal berikut:

• Biaya infrastruktur COM dari server host hypervisor, server bare-metal, penyimpanan, perangkat jaringan, penyegaran perangkat keras alat keamanan, instalasi, dan pemeliharaan. Hitung ini dengan harga aktual dan tingkat diskon untuk kapasitas yang dibutuhkan untuk skenario tersebut.

• Biaya pusat data COM dan fasilitas kolokasi, termasuk ruang, pendinginan, daya, rak, catu daya tak terputus (UPS), pemasangan kabel, sistem keamanan fisik, ukuran untuk pertumbuhan dan ditentukan untuk memenuhi kapasitas, dan tingkat ketersediaan dan pemulihan bencana (DR) yang tinggi untuk skenario tersebut.

• Biaya layanan jaringan COM, termasuk biaya untuk tautan WAN, jaringan pengiriman konten, dan jaringan pribadi virtual (VPNs), dihitung menggunakan harga kontrak untuk konektivitas, bandwidth, throughput, dan kebutuhan latensi untuk skenario tersebut.

• Biaya aplikasi dan perangkat lunak infrastruktur COM berdasarkan kontrak yang ada untuk memberikan pertumbuhan atau pengurangan penggunaan untuk skenario tersebut.

• Biaya AWS utilitas FOM, termasuk dukungan teknis dan layanan terkelola sesuai kebutuhan, berdasarkan arsitektur layanan yang disempurnakan, ukuran instans, model harga pilihan, penggunaan yang diharapkan, dan volatilitas penggunaan.

• Lisensi aplikasi FOM berdasarkan desain aplikasi akhir, konfigurasi infrastruktur yang menjalankan aplikasi, pertumbuhan dari waktu ke waktu, dan aturan transferabilitas lisensi.

• Perkiraan biaya migrasi dan modernisasi FOM, disempurnakan untuk mencerminkan rencana gelombang migrasi dasar untuk skenario tersebut, dan dirinci untuk menyediakan biaya untuk setiap beban kerja, terutama bagi mereka yang akan direplatform, dibeli kembali, atau difaktorkan ulang.

• Biaya penonaktifan FOM, termasuk perkiraan penghapusan aset dan biaya penghentian awal kontrak, direvisi untuk mencerminkan waktu penonaktifan dalam rencana gelombang migrasi dasar, verifikasi aset apa yang dapat digunakan kembali dan aset apa yang dapat dialihkan untuk meminimalkan penghapusan, dan biaya pembuangan aset fisik dan media.

• Biaya proses paralel migrasi disempurnakan untuk mencerminkan waktu setiap pemotongan migrasi dan setiap penonaktifan layanan yang ada.

Menyempurnakan produktivitas TI dan operasi TI serta mendukung model nilai efisiensi

Seperti halnya kasus bisnis terarah, ada dua pendekatan utama untuk menyempurnakan dan mengembangkan model nilai seputar operasi dan dukungan TI. Pendekatan yang Anda pilih tergantung pada apakah COM dikelola secara internal atau dengan kontraktor atau layanan outsourcing:

Peningkatan produktivitas tim internal

Di mana operasi dan dukungan TI dikelola di rumah, fokus kasus bisnis adalah sebagai berikut:

• Mengidentifikasi dan mengukur keuntungan produktivitas dari migrasi dan otomatisasi operasional apa pun yang termasuk dalam ruang lingkup

• Memvalidasi bahwa waktu yang dibebaskan untuk tim internal dapat dengan mudah dan produktif diterapkan pada kegiatan lain yang biasanya bernilai lebih tinggi, memberikan peluang untuk kemajuan dan penghargaan yang lebih besar kepada tim dan nilai lebih bagi organisasi

Menilai berapa banyak waktu yang dihabiskan setiap anggota dalam setiap peran dalam tim untuk berbagai kegiatan rutin mereka, dan bimbingan tentang pengurangan beban kerja yang diharapkan untuk kegiatan yang berbeda.

Tabel berikut memberikan panduan awal untuk tingkat tipikal pengurangan beban kerja berdasarkan aktivitas untuk tugas-tugas yang menghabiskan sebagian besar operasi TI dan upaya dukungan di berbagai peran dalam tim. Tabel ini mencakup deskripsi tentang bagaimana produktivitas dicapai.

catatan

Kegiatan yang tercantum biasanya dilakukan oleh anggota tim dalam beberapa peran yang berbeda, sehingga penghematan produktivitas untuk setiap tugas harus dinilai di seluruh set lengkap peran dalam tim. Misalnya, dalam tim operasi TI yang diselenggarakan oleh menara infrastruktur (seperti komputasi, penyimpanan, dan jaringan), perencanaan belanja modal dan penganggaran mungkin umum untuk menara lead untuk setiap menara.

Kegiatan operasional dan dukungan	Tingkat tabungan	Penggerak produktivitas
Desain infrastruktur	Sedang	Desain disederhanakan, dengan parameter yang lebih sedikit untuk dipertimbangkan.
Perencanaan dan penganggaran belanja modal	Tinggi	Layanan elastis opex-centric menghapus hampir semua masalah penganggaran dan perencanaan.
Pembelian	Tinggi	Pengadaan sangat disederhanakan setelah Akun AWS ditetapkan.
Perencanaan kapasitas	Menengah-sangat tinggi	Jaringan dan beban kerja manajemen kapasitas komputasi biasanya dihilangkan, dan untuk penyimpanan sangat disederhanakan
Penyetelan	Tinggi-sangat tinggi	Tuning tidak diperlukan untuk layanan terkelola dan hampir tidak diperlukan untuk layanan lain karena instance dapat diubah ukurannya kapan saja.
Mengelola kegagalan perangkat keras	Sangat tinggi	Semua aspek penanganan perangkat keras di cloud ditangani secara transparan oleh. AWS
Memantau ketersediaan dan komunikasi server	Tinggi	Pemantauan dan komunikasi disederhanakan secara ekstensif dengan dukungan AWS alat dan otomatisasi.
Manajemen keamanan	Sedang	Beban kerja berkurang secara signifikan dengan kemampuan AWS keamanan dan dengan AWS memiliki tanggung jawab keamanan untuk AWS Cloud perangkat keras, perangkat lunak, jaringan, dan fasilitas.
Peningkatan jaringan dan penyimpanan, pemeliharaan, dan tambalan.	Sangat tinggi	Semua aspek pemeliharaan jaringan dan penyimpanan di cloud ditangani secara transparan oleh. AWS
Racking dan susun — logistik perangkat keras	Sangat tinggi	Semua aspek pengelolaan perangkat keras di cloud ditangani secara transparan oleh. AWS
Cadangan	Sedang	Backup disederhanakan secara ekstensif dengan AWS alat, sistem penyimpanan yang fleksibel, dan otomatisasi.
Layanan terkelola (seperti Amazon S3, Amazon RDS, AWS Lambda dan) AWS Fargate	Sangat tinggi	Layanan terkelola berjalan di lingkungan yang dikelola sepenuhnya oleh AWS, sehingga tidak memerlukan pemeliharaan, penambalan, pemantauan, atau aktivitas manajemen penyediaan.
Pengaturan dan commissioning perangkat dan layanan	Tinggi-sangat tinggi	Aktivitas untuk pengaturan perangkat keras untuk perkebunan yang dimigrasi ke AWS biasanya dikurangi, kecuali untuk perangkat konektivitas WAN untuk membangun VPNs atau AWS Direct Connect koneksi ke pusat AWS data.
Perlindungan titik akhir dan perlindungan antivirus	Tinggi	Aplikasi dan pemeliharaan perlindungan endpoint dan layanan antivirus biasanya secara ekstensif otomatis sebagai bagian dari desain migrasi.
Ancaman, kerentanan, dan penilaian risiko	Tinggi	AWS memberikan dukungan untuk elemen-elemen ini, berfokus pada platform inti dan mekanisme yang AWS menyediakan untuk mengamankan arsitektur menyederhanakan penilaian.
Manajemen proyek infrastruktur pusat data	Tinggi	Manajemen proyek untuk pekerjaan instalasi untuk perluasan, penyegaran, atau penonaktifan layanan infrastruktur. Sementara beberapa manajemen perangkat lunak dan layanan infrastruktur tetap ada, ini jauh lebih sederhana daripada infrastruktur lokal, dan aktivitas perangkat keras dihilangkan.
Manajemen fasilitas pusat data	Menengah-sangat tinggi	Pekerjaan manajemen fasilitas yang dapat dikaitkan dengan semua server, perangkat penyimpanan, peralatan keamanan, dan rak terkait dihapus untuk semua yang dimigrasikan. Namun, beberapa pekerjaan biasanya tetap untuk menyediakan fasilitas untuk perangkat jaringan tautan WAN dan untuk infrastruktur apa pun yang disimpan di tempat dalam arsitektur hibrida.
Arsitektur aplikasi, pengembangan, manajemen, dan pengujian	Rendah	Penggunaan rantai alat pengembangan tangkas, dikombinasikan dengan otomatisasi instantiasi dan penghancuran tumpukan aplikasi untuk membangun lingkungan pengujian sesuai kebutuhan, mengurangi waktu tunggu pengembangan aplikasi dan menghilangkan banyak langkah pengujian manual.
Menginstal dan mengonfigurasi perangkat lunak aplikasi	Sedang	Instalasi dan konfigurasi tumpukan aplikasi lengkap siap diotomatisasi menggunakan layanan seperti AWS CloudFormation dan disederhanakan melalui penggunaan zona pendaratan, yang dapat dengan mudah dikonfigurasi dengan menggunakan. AWS Control Tower
Dukungan TI	Sedang	Pengurangan dukungan L1 dan L2 dicapai dengan mengurangi masalah kapasitas dan kinerja melalui penggunaan kemampuan Service Catalog untuk penyediaan layanan mandiri, peningkatan penggunaan arsitektur ketersediaan tinggi berbiaya rendah (mengurangi pemadaman dan mengonfigurasi penskalaan otomatis dan komputasi tepi).
Administrasi basis data	Minimal-rendah	Kegiatan ini sebagian besar tetap tidak berubah. Mereka biasanya sumber daya pada tingkat yang AWS sama untuk infrastruktur lokal.
Pengambilan, analisis, dan desain persyaratan infrastruktur dan keamanan	Minimal
Dokumentasi	Minimal
Aplikasi dan pemantauan kinerja	Minimal
Dukungan teknis L3, menjawab pertanyaan, dan pemecahan masalah dan pemecahan masalah	Minimal
Menginstal dan mengonfigurasi perangkat lunak aplikasi	Minimal
Dukungan aplikasi L3 (tidak termasuk penganggaran dan perencanaan kapasitas jangka panjang)	Minimal

Tabel berikut menunjukkan penghematan yang diharapkan untuk setiap tingkat pengurangan beban kerja.

Tingkat	Diharapkan
Sangat tinggi	85% - 100%
Tinggi	60% - 90%
Sedang	30% - 70%
Rendah	10% - 35%
Minimal	0% - 10%

Metrik ini memberikan titik awal untuk menilai peningkatan produktivitas dan memasukkannya ke dalam kasus bisnis terperinci. Keuntungan produktivitas aktual bervariasi berdasarkan situasi tertentu. Ini dapat berguna untuk menghitung penghematan produktivitas di titik tengah dan ujung bawah rentang untuk memperkirakan skenario tipikal dan konservatif.

Seiring kemajuan program, penting untuk menangkap data aktual untuk waktu yang dihabiskan pada setiap aktivitas berdasarkan peran. Data tersebut membangun basis yang lebih baik untuk memperkirakan operasi dan mendukung biaya untuk proyek baru dan perluasan layanan.

Mengalihdayakan operasi TI dan mendukung pengurangan biaya

Di mana operasi dan dukungan TI terutama dialihdayakan atau dikelola dengan kontraktor, alokasi biaya untuk model operasi future (FOM) dapat disiapkan dengan meminta penawaran dari AWS Mitra yang menawarkan solusi layanan terkelola, termasuk Partner-led (AMS). AWSAWS Managed Services Anda juga dapat menghubungi manajer AWS akun Anda dan meminta harga untuk AMS secara langsung, seperti yang dijelaskan dalam ayat tentang Membangun optimalisasi biaya operasional dalam bagian Membuat kasus bisnis terarah.

Untuk kasus bisnis yang terperinci, ganti angka tolok ukur apa pun dengan kutipan berdasarkan tagihan bahan layanan yang direvisi dan konsumsi AWS layanan yang diharapkan, paket AMS dan opsi apa pun yang diperlukan, dan tingkat layanan yang diperlukan. Biaya akan memiliki komponen implementasi satu kali dan run rate berbasis konsumsi.

Sertakan operasi TI yang tersisa, dukungan yang harus dipertahankan untuk layanan apa pun yang tidak akan dimigrasikan AWS, dan biaya satu kali jika ada penalti kontrak (misalnya, untuk penghentian dini).

Mengembangkan model nilai ketahanan

Pada AWS, Anda dapat membangun berbagai ketersediaan tinggi, pemulihan bencana, dan arsitektur toleran kesalahan. Penetapan harga berbasis konsumsi berarti bahwa layanan dibebankan hanya jika digunakan. Bersama-sama, kedua faktor ini memberikan kinerja biaya yang luar biasa untuk ketahanan.

Selain itu, AWS ccustomer telah menggunakan ini untuk meningkatkan ketahanan beban kerja mereka. Survei IDC 2018 memberikan contoh pelanggan yang berpartisipasi mencapai 73 persen lebih sedikit pemadaman per tahun, pengurangan 58 persen dalam mean time to recover (MTTR) dan penurunan 94 persen dalam produktivitas yang hilang. Survei yang sama menunjukkan bahwa manfaat finansial yang diperoleh melalui peningkatan ketahanan adalah 50 persen lebih besar daripada manfaat pengurangan biaya infrastruktur TI.

Selain itu, ketahanan lebih lanjut dicapai melalui modernisasi siklus hidup pengembangan perangkat lunak untuk aplikasi. Di mana pipa CI/CD dengan otomatisasi pengujian diperkenalkan untuk mendukung kelincahan bisnis yang lebih besar, cacat perangkat lunak ditangkap lebih awal dalam siklus pengembangan, sangat mengurangi biaya pemeliharaan perangkat lunak.

Untuk menilai dan memasukkan nilai ini dalam kasus bisnis, pertama-tama bekerja dengan pemilik bisnis aplikasi untuk membangun gambaran peluang manfaat total untuk setiap beban kerja yang akan dimigrasikan.Ini mungkin termasuk sebagai item berikut:

• Jumlah, durasi rata-rata, dan sifat interupsi dalam layanan:

  • Contoh gangguan layanan termasuk pemadaman, perlambatan kinerja, batch terencana dan pemeliharaan jendela overrunning, bug dalam fungsi utama, dan pembatasan akses selama periode puncak.

• Dampak pada pendapatan oleh gangguan layanan yang menghasilkan pendapatan, seperti sistem e-commerce:

  • Kemungkinan jumlah transaksi yang tidak dapat diselesaikan melalui gangguan layanan, berdasarkan waktu interupsi dan tingkat transaksi

  • Nilai rata-rata untuk setiap transaksi yang terkena dampak

• Biaya tambahan waktu insinyur pendukung untuk menyelesaikan cacat dalam sistem produksi dibandingkan dengan biaya untuk menemukannya lebih awal dalam proses pengembangan

• Dampak pada produktivitas pengguna internal dan biaya waktu yang hilang

Kemudian buat penilaian pengurangan waktu yang diharapkan dan lebih konservatif yang hilang karena gangguan layanan yang harus dihasilkan oleh peningkatan ketahanan. Misalnya, pertimbangkan untuk memasukkan item-item berikut:

• Mengurangi jumlah pemadaman dan MTTR menggunakan arsitektur ketersediaan tinggi dan peningkatan tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO)

• Pengurangan perlambatan, penghapusan pelambatan kapasitas dan penghindaran dalam kelebihan pemrosesan batch, menggunakan kemampuan seperti penskalaan otomatis

• Mengurangi jumlah bug aplikasi yang hanya ditemukan dalam produksi, melalui implementasi pipa CI/CD dan pengujian regresi otomatis pada infrastruktur yang diputar dan diputar ke bawah untuk meminimalkan biaya

Satukan ini untuk portofolio aplikasi yang akan dimigrasikan dan dimodernisasi, dan hitung angka nilai bisnis yang diharapkan dan lebih konservatif untuk setiap tahun kasus. Manfaat harus meningkat sejalan dengan jadwal migrasi dan kemudian meningkatkan volume sesuai dengan ekspektasi pertumbuhan penggunaan dari aplikasi yang berkontribusi.

Mengembangkan model nilai kelincahan bisnis

Kelincahan bisnis adalah alasan utama AWS pelanggan bermigrasi. AWSSurvei AWS pelanggan IDC 2018 menunjukkan bahwa bagi mereka, manfaat kelincahan bisnis menyumbang 47 persen dari total manfaat yang diukur dan lebih dari lima kali manfaat yang diperoleh dari pengurangan biaya infrastruktur.

Memprediksi secara akurat semua manfaat kelincahan bisnis yang akan diperoleh dari transformasi apa pun adalah tantangan. Namun, dengan berfokus pada aplikasi yang mendukung sejumlah besar pengguna atau merupakan sumber diferensiasi bisnis, Anda dapat memodelkan dan memasukkan bagian material dari manfaat ini ke dalam kasus bisnis rinci dasar.

Ketika migrasi berlangsung, secara bertahap menyempurnakan dan memperluas model nilai kelincahan bisnis karena lebih banyak manfaat menjadi dapat diukur. Ini membuat kasus bisnis tetap relevan, sehingga dapat digunakan sebagai alat pendukung keputusan utama untuk mengarahkan program.

Untuk membangun model nilai kelincahan bisnis, gunakan panduan berikut:

• Pilih beban kerja yang memiliki kesempatan untuk mendorong peningkatan kinerja bisnis terbesar, seperti:

  • Beban kerja yang menghasilkan pendapatan

  • Beban kerja operasi bisnis dengan ruang lingkup untuk mendorong peningkatan efisiensi dan menghilangkan biaya dari bisnis

  • Alat produktivitas bisnis yang mendukung basis pengguna yang besar

• Untuk beban kerja yang menghasilkan pendapatan dan efisiensi, lakukan hal berikut:

  • Buat penilaian yang realistis dan lebih konservatif terhadap pertumbuhan pendapatan atau efisiensi operasional yang diharapkan dapat didorong oleh peningkatan aplikasi besar dan kecil.

  • Perkirakan peningkatan jumlah rilis mayor dan minor per tahun yang AWS meningkatkan kecepatan pengembangan aplikasi dan mengurangi waktu penyebaran infrastruktur memungkinkan. Beberapa metrik dasar untuk ini disediakan dalam laporan IDC.

  • Hitung ekspektasi manfaat yang realistis dan lebih konservatif. Petakan mereka selama periode kasus bisnis, membuat tunjangan untuk meningkatkan efisiensi penuh beberapa saat setelah beban kerja masing-masing dimigrasikan.

• Untuk alat produktivitas bisnis, lakukan hal berikut:

  • Buat penilaian yang realistis dan lebih konservatif tentang penghematan waktu yang diharapkan dapat didorong oleh peningkatan aplikasi besar dan kecil.

  • Perkirakan biaya rata-rata waktu dan upaya orang di seluruh basis pengguna yang terkena dampak.

  • Gunakan angka untuk meningkatkan frekuensi rilis mayor dan minor, dan hitung manfaatnya selama jangka waktu kasus bisnis.

Karena peningkatan produktivitas pengembang dan pengurangan waktu untuk peluncuran tidak memerlukan sumber daya tambahan, tambahkan garis manfaat bersih untuk setiap beban kerja ke dalam model arus kas kasus bisnis untuk dimasukkan dalam arus kas diskon, NPV, ROI, MIRR, dan perhitungan pengembalian.