Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Perjalanan Model Operasi Cloud
Dokumen Visi telah mengklarifikasi status target Anda, tetapi Anda harus memahami di mana Anda berada dalam perjalanan adopsi cloud Anda untuk menghubungkan visi dengan kemampuan Anda saat ini, dan kemudian memahami langkah selanjutnya. Kami telah menemukan bahwa banyak pelanggan fokus pada ke mana mereka ingin pergi, tetapi mungkin sulit untuk melihat apa langkah pertama yang harus dilakukan dalam perjalanan itu.
Setelah tahap **Envision**, AWS CAF mendefinisikan tiga fase lagi:
+ **Align**: Fokus adalah mengidentifikasi kesenjangan kemampuan di enam perspektif AWS CAF (bisnis, orang, tata kelola, platform, keamanan, dan operasi), mengidentifikasi ketergantungan lintas organisasi, dan memunculkan kekhawatiran dan tantangan pemangku kepentingan.
+ **Peluncuran**: Fokus adalah memberikan inisiatif percontohan dalam produksi dan menunjukkan nilai bisnis tambahan. Pilot harus sangat berdampak. Jika dan ketika mereka berhasil, mereka akan membantu mempengaruhi arah masa depan.
+ **Skala**: Fokus adalah memperluas pilot produksi dan nilai bisnis ke skala yang diinginkan dan memastikan bahwa manfaat bisnis yang terkait dengan investasi cloud Anda terwujud dan berkelanjutan.
Karena tujuan AWS CAF adalah untuk meningkatkan kesiapan cloud Anda, kami akan menambahkan fase lain setelah fase **Skala**:
+ **Optimalkan**: Fokus adalah terus meninjau kembali dan meningkatkan solusi akhir untuk memberikan manfaat bisnis tambahan.
Menggunakan tahap-tahap ini bersama dengan AWS COM Framework membantu Anda mengidentifikasi kemampuan yang penting bagi Anda di setiap titik waktu. **Misalnya, jika Anda berada dalam fase **Peluncuran**, Anda mungkin lebih tertarik pada kemampuan *Arsitektur dan Pola* daripada kemampuan *Manajemen Sumber Daya/Perkebunan*, yang lebih relevan selama fase Skala.**
Anda melakukan kegiatan tertentu di setiap tahap. Misalnya, dalam fase **Align**, Anda mengidentifikasi kemampuan yang Anda miliki saat ini dan tingkat kematangan, kemudian menentukan kemampuan mana yang perlu Anda fokuskan terlebih dahulu. Jika Anda berada dalam fase **Peluncuran**, mengidentifikasi tim percontohan untuk mengembangkan tingkat kedewasaan berikutnya akan menjadi penting. Ini membutuhkan perencanaan, jadi kami sarankan Anda menentukan peta jalan.
# Tentukan peta jalan
Anda mungkin telah melihat kutipan berikut dari Werner Vogels, VP dan CTO di Amazon: "*Anda membangunnya, Anda menjalankannya*. “
Ini dari wawancara 2006 [Percakapan dengan Werner Vogels: Belajar dari platform teknologi Amazon](https://queue.acm.org/detail.cfm?id=1142065) (*ACM Queue*, Vol. 4, Edisi 4, 30 Juni 2006). Werner berbicara tentang bagaimana tim di Amazon berfungsi (model operasi) dan menjelaskan perusakan dinding antara pengembangan dan operasi. Membangun tim lintas fungsi yang memiliki semua kemampuan yang diperlukan untuk membangun, memberikan, dan mendukung produk mereka telah menjadi persyaratan untuk transformasi digital sejati.
Namun, transformasi digital itu, yang didukung oleh Model Operasi Cloud Anda, sering dipandang sebagai terlalu banyak perubahan untuk dikelola pada satu waktu. Sebaliknya, kami menganggap analogi perjalanan dengan peta jalan yang membawa Anda ke *“Anda membangunnya, Anda menjalankannya”* sebagai tujuan. Setiap peningkatan kematangan kemampuan Anda membuat Anda lebih dekat ke tujuan Anda. Pada saat Anda telah mencapai tujuan Anda, organisasi Anda akan mengembangkan cara untuk terus memperbarui Model Operasi Cloud agar sesuai dengan hasil bisnis yang berubah, dan peta jalan diperbarui dengan tujuan berikutnya.
Untuk mendukung pendekatan inkremental ini, kami menyarankan Anda mengembangkan peta jalan yang secara langsung berkaitan dengan visi organisasi Anda (misi dan pendorong) dan mendefinisikan langkah-langkah (peningkatan kedewasaan, dipandu oleh prinsip) yang diperlukan untuk mencapai tujuan (hasil).
# Menerapkan peta jalan
Ketika Anda telah membuat peta jalan, Anda perlu menerapkannya. Kami telah menemukan bahwa di sinilah pelanggan menghadapi tantangan berikutnya: mereka telah menghabiskan waktu untuk *berpikir*, dan sekarang harus bergerak untuk *melakukan*. Untuk menghubungkan strategi Anda ke implementasi, kami merekomendasikan langkah-langkah berikut:
+ [Tentukan di mana dan bagaimana memulainya](#decide)
+ [Atur untuk sukses](#organize)
+ [Menetapkan Mekanisme untuk mendorong perubahan](#establish)
+ [Kembangkan kedewasaan secara bertahap](#develop)
## Tentukan di mana dan bagaimana memulainya
Ini terdengar mudah, tetapi dengan begitu banyak yang harus dicapai, menemukan titik awal seringkali merupakan pertanyaan yang sulit dan diperdebatkan. Organizations yang bergerak ke cloud memiliki banyak hal untuk difokuskan, dan inisiatif dapat menjadi luar biasa jika tidak dimasukkan ke dalam konteks. Selama bertahun-tahun, tren pelanggan telah berkembang, tetapi titik awal yang konsisten adalah kepemimpinan [transformasional](https://docs.aws.amazon.com/whitepapers/latest/aws-caf-people-perspective/transformational-leadership.html). Mendorong arahan dan strategi dari atas ke bawah dan menciptakan pernyataan misi, prinsip, dan PR-FAQ memungkinkan manajemen menengah dan individu untuk membuat keputusan secara mandiri, mendorong kejelasan, dan mendorong nilai bisnis dari transformasi cloud. Jika Anda belum melakukan latihan ini atau yang serupa, kami merekomendasikannya sebagai tugas pertama Anda.
Selama latihan ini, Anda harus menyadari bahwa tidak seperti transformasi teknologi lainnya, transformasi cloud membawa teknologi lebih dekat ke bisnis. Teknologi adalah tuas yang digunakan bisnis untuk mencapai tujuan yang lebih luas dengan memungkinkan kelincahan, stabilitas, optimalisasi biaya, dan hasil serupa. Anda harus merencanakan transformasi ini dengan teknologi dan bisnis, bekerja kembali dari strategi 3-5 tahun organisasi Anda, mengidentifikasi tujuan di sepanjang jalan, dan tidak takut untuk berputar saat dibutuhkan.
## Atur untuk sukses
Bagaimana organisasi Anda terstruktur untuk mencapai tujuan migrasi, adopsi, dan transformasi cloud akan berubah saat organisasi Anda matang. Memahami hal ini, mempersiapkan, dan disengaja adalah kunci untuk memastikan kesuksesan.
Umumnya, pada awal perjalanan tim terbesar bekerja di lingkungan lokal. Kemudian, seiring berkembangnya adopsi cloud, tim-tim ini bermigrasi untuk membangun, mematangkan, mengoperasikan, dan mengoptimalkan platform cloud, dan organisasi Anda harus menyesuaikan diri dengan cara kerja baru di setiap tahapan ini. Kami telah mengamati bahwa perubahan yang sulit tetapi penting terjadi ketika sebuah organisasi telah memindahkan 5 hingga 10 persen dari beban kerja mereka ke cloud (transisi dari fase Peluncuran ke fase Skala). Pada titik ini, organisasi menggunakan tim lokal untuk mengoperasikan sumber daya cloud karena migrasi tidak cukup besar untuk mendapatkan perubahan penuh waktu, sehingga tim ini harus menyeimbangkan antara tanggung jawab yang ada dan yang baru. Pada saat yang sama, tim lokal yang sekarang diminta untuk mengoperasikan layanan cloud memerlukan keterampilan baru, yang melibatkan kurva pembelajaran yang curam.
Untuk memahami organisasi Anda dan mengembangkan rencana untuk mengaktifkan perubahan ini, kami sarankan Anda melihat topologi tim di seluruh organisasi TI Anda. Kami menggunakan metode ini dengan pelanggan untuk memahami pengaturan dan keterkaitan fungsi dalam organisasi TI, yang seringkali berbeda dari struktur organisasi, dan kemudian menggunakan Kerangka Kerja AWS COM untuk panduan tentang bagaimana mengatur untuk menyampaikan terhadap tahapan dan tonggak transformasi. Setiap perubahan pada struktur organisasi yang mungkin diperlukan diinformasikan oleh latihan ini.
Topologi yang kami gunakan dengan pelanggan termasuk model terdesentralisasi, terpusat, dan federasi. Ini memperluas representasi model operasi 2-by-2 yang tercakup dalam Kerangka [AWS Well-Architected](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operating-model-2-by-2-representations.html), Pilar Keunggulan Operasional.
### Terdesentralisasi
Perusahaan besar dan global yang beroperasi di berbagai geografi atau segmen industri sering menggunakan model terdesentralisasi, yang diilustrasikan dalam diagram berikut. Pada perusahaan-perusahaan ini, unit bisnis individu memiliki ketentuan TI sendiri yang dapat tumpang tindih dengan daerah atau unit bisnis lain. Namun, ini sering dipahami dan diterima sebagai cara untuk memberikan otonomi dan spesialisasi di wilayah tersebut.
![\[Model operasi terdesentralisasi\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/strategy-cloud-operating-model/images/decentralized-op-model.png)
Menggunakan pendekatan desentralisasi berarti bahwa setiap wilayah atau unit bisnis memiliki Model Operasi Cloud sendiri yang disesuaikan dengan kebutuhan wilayah atau unit bisnis tersebut.
### Tersentralisasi
Fungsi TI terpusat adalah model yang paling sering kita lihat. Ketika model ini ada, pelanggan berusaha mempertahankan topologi yang sama saat membuat Model Operasi Cloud mereka. Ini diilustrasikan dalam diagram berikut.
![\[Model operasi terpusat\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/strategy-cloud-operating-model/images/centralized-op-model.png)
Dalam model ini, tim pusat menyediakan platform yang dikuratori yang dapat digunakan oleh tim beban kerja yang memiliki Model Operasi Cloud mereka sendiri. Dengan pendekatan ini, tim beban kerja dapat fokus pada nilai yang mereka berikan kepada pelanggan akhir mereka tanpa harus khawatir tentang layanan, operasi, atau keamanan platform yang mereka gunakan. Model ini bekerja dengan baik untuk perusahaan kecil. Namun, dalam organisasi global yang besar, jumlah tim beban kerja bisa mencapai ratusan atau ribuan. Untuk mengelola pada skala ini tanpa kehilangan manfaat dari platform pusat, organisasi sering beralih ke model federasi, yang diuraikan di bagian selanjutnya.
### Terfederasi
Banyak organisasi mengadopsi model TI federasi karena menyediakan fungsi sentral yang bertanggung jawab untuk platform cloud tetapi memungkinkan untuk berbagai model operasi di tingkat beban kerja. Ini berarti bahwa tim pusat dapat fokus pada penyediaan platform terbaik bagi organisasi tanpa kendala bekerja ke common denominator terendah. Diagram berikut menggambarkan model federasi.
![\[Model operasi federasi\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/strategy-cloud-operating-model/images/federated-op-model.png)
Dalam organisasi besar, model federasi memberikan otonomi yang dibutuhkan oleh tim teknik sambil memastikan bahwa tim pusat menyediakan platform dan angkat berat yang tidak berdiferensiasi yang umum di semua beban kerja. Dalam model ini, tim pusat harus bekerja dengan cara yang berpusat pada produk yang sama dengan tim teknik, tetapi produk mereka adalah platform.
### Mengubah topologi agar sesuai dengan perjalanan
Topologi yang Anda pilih tergantung pada ukuran perusahaan Anda, tetapi juga menyesuaikan dengan tahap perjalanan cloud Anda. Organisasi departemen atau tim tidak statis, tetapi berubah dengan setiap tahap adopsi cloud. Ini berarti Anda dapat merancang, mendiskusikan, dan menambah topologi yang berbeda saat lingkungan berubah. Contoh faktor yang mempengaruhi meliputi:
+ Pindah dari bukti konsep (POC) ke beban kerja pilot
+ Perluasan unit geografis atau bisnis
+ Pindah ke tim yang berpusat pada produk
+ Peluang untuk mendapatkan keuntungan dari skala ekonomi dari komponen atau pola bersama
+ Realisasi [Hukum Conway](https://martinfowler.com/bliki/ConwaysLaw.html), yang mempengaruhi desain aplikasi dan layanan atas persyaratan arsitektur
+ Mandat cloud-first atau inisiatif top-down lainnya
+ Kehilangan tujuan KPI atau bisnis yang disebabkan oleh tujuan tim atau organisasi yang tidak sesuai
## Menetapkan Mekanisme untuk mendorong perubahan
Di Amazon, *Mekanisme* didefinisikan sebagai berikut: *Proses lengkap yang mengubah Input menjadi Output dan dirakit dari Tuas Organisasi. Ini menggunakan data dan umpan balik untuk mendukung proses dan memastikan hasil terpenuhi.* Karena setiap organisasi berbeda, setiap perjalanan Model Operasi Cloud berbeda, tetapi mereka semua membutuhkan Mekanisme untuk mendorong perubahan.
Kami menyarankan Anda meluangkan waktu untuk memahami dan mengembangkan Mekanisme agar sesuai dengan perubahan yang diperlukan untuk mengimplementasikan Model Operasi Cloud Anda. Pendekatan yang populer adalah mengadopsi prinsip-prinsip Agile. Mekanisme tangkas memecah hambatan organisasi dan berbasis proses antara tim yang terdiam, dan menciptakan loop umpan balik untuk memastikan bahwa organisasi Anda menghabiskan waktu berinovasi pada aktivitas paling berdampak yang akan mendorong nilai bisnis paling besar.
## Kembangkan kematangan secara bertahap
*Kematangan* dalam konteks Model Operasi Cloud mengacu pada seberapa dekat kemampuan Anda dengan cara kerja yang mengutamakan cloud. Misalnya, seberapa otonom proses Anda, dan seberapa banyak keterlibatan manusia yang diperlukan untuk mengelola bisnis seperti biasa (menjalankan perusahaan) dibandingkan dengan inovasi (mengubah perusahaan)? Jika aktivitas Anda lebih berat terhadap yang pertama, kematangan (cloud) Anda rendah; jika yang terakhir, kedewasaan Anda lebih tinggi. Menjadi rendah pada skala kedewasaan bukanlah hal yang negatif—itu adalah cerminan dari di mana Anda berada dalam perjalanan Anda. Tujuannya adalah untuk memahami di mana Anda berada dan di mana Anda harus pergi. Ketika kami bekerja dengan AWS pelanggan, kami menggunakan skala kematangan dalam AWS COM Framework untuk memberikan langkah-langkah di sepanjang perjalanan.
Kami merekomendasikan penggunaan Mekanisme untuk meningkatkan kematangan secara bertahap di seluruh kemampuan AWS COM Framework. Contoh bagaimana kami bekerja dengan pelanggan dengan cara ini adalah mengubah tinjauan dan prioritas jatuh tempo (input) menjadi peningkatan kematangan (output), dan kemudian melakukan peristiwa berbasis pengalaman seperti [Game Days](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.gameday.en.html) (loop umpan balik) untuk memverifikasi hasil dan menyesuaikan sesuai kebutuhan. Dengan membangun mekanisme ini bersama pelanggan, kami telah menemukan bahwa ketika kekuatan organisasi ini dikembangkan, itu tidak hanya memungkinkan pencapaian tonggak sejarah langsung, tetapi memungkinkan peningkatan tambahan yang berlangsung di luar fase awal perjalanan.
Memperhatikan kemampuan organisasi Anda yang matang dan secara bertahap membangun perubahan yang diperlukan dalam kemampuan tertentu, pada waktu tertentu dalam peta jalan Anda, mengikat strategi dengan implementasi. Ini juga membantu Anda memanfaatkan skala ekonomi yang datang dengan membangun pencapaian Anda sebelumnya.
# Ukur kemajuan
Bagian sebelumnya menyoroti bagaimana pemimpin cloud dapat membuat visi yang menarik untuk Model Operasi Cloud mereka. Kami memberikan panduan tentang cara menghubungkan strategi ke implementasi untuk mendukung pembuatan Model Operasi Cloud Anda. Kami juga menjelaskan perlunya kerangka kerja, seperti AWS COM Framework, untuk memahami dan mengembangkan tingkat kematangan, dan membangun peta jalan kemampuan yang memenuhi kebutuhan organisasi Anda. Ada satu bagian lagi yang diperlukan: memastikan yang KPIs ditetapkan untuk mengukur kemajuan dan menunjukkan di mana perubahan arah diperlukan untuk mempertahankan momentum.
Dalam komunitas AWS transformasi internal, salah satu pertanyaan yang paling sering diajukan adalah: *“Bagaimana pelanggan kami dapat mengukur apakah mereka benar-benar mengubah bisnis mereka?”*
Untuk memahami mengapa pertanyaan ini penting dan apa yang dapat dilakukan tentang hal itu, lihat Eric Tachibana 2015 re:Invent presentasi [9 Praktik Terbaik untuk](https://www.youtube.com/watch?v=dU3gFDcsZOw) Menghindari Program Transformasi Cloud yang Terhenti. Dalam pembicaraan ini, Eric menunjukkan bagaimana pelanggan dapat memperlambat atau bahkan menghentikan perjalanan adopsi cloud mereka (*The* *Great Stall*) dan memberikan praktik terbaik yang dikumpulkan dari AWS pelanggan yang telah berhasil mempercepat penundaan tersebut.
Grafik berikut menyoroti apa yang bisa terjadi di The Great Stall, dan Eric membahas cara untuk melewati fase itu. Kami dapat mengambil diskusi itu lebih lanjut untuk mengatakan bahwa kemajuan di luar The Great Stall dan mengelola perjalanan mengharuskan Anda menetapkan langkah-langkah dan memiliki kemampuan untuk memperbaiki arah Anda.
![\[Mengukur kemajuan\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/strategy-cloud-operating-model/images/measuring-progress.png)
Adopsi dan konsumsi layanan cloud memungkinkan perjalanan transformasi ini, sehingga tidak adanya Model Operasi Cloud yang fungsional dan kurangnya visibilitas ke dalam perjalanan dapat menyebabkan adopsi memasuki The Great Stall. Oleh karena itu, kami merekomendasikan para pemimpin cloud untuk membangun observabilitas dalam bentuk [balanced scorecard](https://www.investopedia.com/terms/b/balancedscorecard.asp). Kartu skor ini terdiri dari seperangkat metrik yang selaras dengan transformasi digital atau cloud. Ini menyediakan cara untuk memahami posisi Anda saat ini dan meramalkan masalah di depan.
## Memvisualisasikan metrik
Membangun balanced scorecard untuk memvisualisasikan metrik membantu memahami dan menempatkan upaya transformasi saat ini dalam konteks nilai bisnis yang ingin mereka berikan. Salah satu pendekatan yang digunakan oleh AWS tim dengan pelanggan mereka adalah membuat Dasbor Transformasi. Pendekatan ini didasarkan pada penelitian analis pelanggan yang telah berhasil menyelesaikan transformasi cloud mereka, dan analisis internal data konsumsi AWS layanan (anonim) lebih dari 5.000 pelanggan dari seluruh dunia, dan di berbagai segmen industri.
Meskipun diskusi kami dalam panduan ini hanya didasarkan pada AWS Cloud layanan, Anda dapat memperluas pendekatan ini untuk lingkungan hybrid atau multi-cloud. Dengan menggunakan metode ini, kami telah mengidentifikasi balanced scorecard untuk transformasi dan beberapa pola yang dapat dikaitkan dengan pelanggan yang berada pada tahap yang berbeda dalam perjalanan Model Operasi Cloud mereka. Tujuan dari pendekatan ini adalah untuk membantu pelanggan mengidentifikasi cara-cara di mana mereka dapat melacak tingkat pertumbuhan transformatif mereka secara keseluruhan, menghindari kemacetan, dan memastikan bahwa mereka terus mematangkan Model Operasi Cloud mereka sebagai enabler transformasi bisnis secara keseluruhan.
Balanced scorecard Dasbor Transformasi kami memiliki empat segmen:
+ Kelincahan dan waktu ke pasar
+ Keuntungan strategis (dan Inovasi layanan)
+ Pengurangan risiko
+ Efisiensi operasional
Dalam kartu skor ini, dua segmen menyoroti nilai-nilai yang terkait dengan waktu ke pasar, kelincahan, inovasi, dan mendapatkan keunggulan dibandingkan pesaing (dalam lingkungan komersial). Dua segmen lainnya fokus pada pengukuran bagaimana organisasi menjadi lebih efisien, efektif, dan tangguh, dan menghindari berada pada posisi yang kurang menguntungkan jika dibandingkan dengan pesaing. Kartu skor ditunjukkan pada diagram berikut.
![\[Memvisualisasikan metrik\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/strategy-cloud-operating-model/images/visualizing-metrics.png)
Dengan memplot titik data pada matriks ini, Anda dapat mewakili fokus organisasi Anda. Ini membantu Anda memahami apakah Model Operasi Cloud Anda sedang dikembangkan untuk *menghindari kerugian* atau untuk *mendapatkan keuntungan*. Jika yang pertama, kami sarankan Anda memperbaiki kursus Anda untuk memastikan bahwa Anda mengembangkan kemampuan untuk fokus pada yang terakhir, karena mendapatkan keuntungan adalah di mana Anda dapat menyadari nilai terbesar.
Secara umum, program migrasi skala besar untuk rehosting beban kerja (*lift dan shift*) fokus pada menghindari kerugian. Setelah migrasi terjadi, kegiatan modernisasi seperti mengadopsi Platform as a Service (PaaS) atau teknologi tanpa server mendukung keuntungan. Misalnya metrik, lihat dua studi yang AWS ditugaskan berikut yang meninjau pendekatan ini dan menyediakan KPIs berdasarkan riset pasar:
+ **Migrasi:** [Nilai Bisnis Migrasi ke Amazon Web Services](https://pages.awscloud.com/rs/112-TZM-766/images/hackett-group-the-business-value-of-migration-to-aws-012022.pdf) (Grup Hackett, Februari 2022). Dalam penelitian ini, The Hackett Group mengukur nilai migrasi ke AWS empat kategori: ketahanan, kelincahan, penghematan biaya, dan produktivitas staf.
+ **Modernisasi:** [Nilai Bisnis Modernisasi Cloud](https://pages.awscloud.com/rs/112-TZM-766/images/known-business-value-of-cloud-%20modernization-012022.pdf) (Diketahui, Januari 2022) menangkap penggunaan 22 unik KPIs untuk memahami nilai modernisasi melalui layanan cloud. Dalam studi ini, mereka mensurvei lebih dari 500 perusahaan yang telah memigrasikan beban kerja ke cloud untuk memahami nilai yang terkait dengan empat strategi modernisasi teknis: kontainer, tanpa server, analitik terkelola, dan data terkelola.
Sepanjang perjalanan Cloud Operating Model Anda, penting untuk memilih langkah-langkah yang dapat mencakup aspek Migrasi dan Modernisasi sehingga kemajuan dilacak, data dapat dibandingkan sepanjang perjalanan, dan hasil tentu saja koreksi dapat dilihat.