Share via

Antipattern organisasi cloud

  • Artikel

Pelanggan sering mengalami antipattern adopsi cloud dalam struktur organisasi mereka. Banyak faktor yang dapat menyebabkan masalah ini:

  • Alat
  • Mitra
  • Insinyur
  • Departemen TI yang tidak sejajar

Sangat penting untuk memahami peran faktor-faktor ini dalam skenario adopsi cloud yang berhasil.

Antipattern: Perlakukan TI sebagai pusat biaya

Banyak perusahaan memperlakukan departemen TI sebagai pusat biaya. Pendekatan ini dapat mengarah pada persepsi bahwa TI tidak menambah nilai bagi perusahaan. Ketika karyawan melihat TI sebagai penyedia daripada penentu, mereka bisa merasa putus asa. Perusahaan juga sulit untuk menarik bakat yang tepat. Berkurangnya motivasi dan hasil waktu siklus hidup yang panjang. Kualitas pekerjaan dari TI dapat melambat, dan silo dan wilayah kekuasaan dapat berkembang.

Contoh: Perlakukan TI sebagai pusat biaya

Sebuah perusahaan mengelola departemen TI-nya sebagai pusat biaya yang bertanggung jawab kepada kepala keuangan (CFO). Dewan pengelola menganggap TI sebagai penyedia layanan yang lambat, yang merupakan salah satu penyebab biaya terbesar perusahaan. Dewan pengelola tidak menyadari bahwa unit bisnis mobilitas menggunakan sebagian besar aset yang dipesan departemen TI. TI membeli pusat data untuk digunakan semua unit bisnis, tetapi unit bisnis mobilitas mendapatkan aset besar ini. Dewan tidak melihat TI sebagai penentu atau mitra.

Hasil yang disukai: Melihat TI sebagai penentu

Alih-alih mengelola departemen TI Anda sebagai pusat biaya, pertimbangkan salah satu pendekatan ini:

  • Penagihan balik: Unit bisnis memperlakukan biaya TI seperti biaya operasional dalam anggaran mereka.
  • Laporan pemutaran atau awareness-back: TI berfungsi sebagai agen. Dalam laporan kembali ke perusahaan, TI mengaitkan biaya langsung ke unit bisnis yang relevan.

Gunakan cloud sebagai alat untuk meningkatkan biaya dan transparansi bisnis. Misalnya, terapkan disiplin Cost Management untuk meningkatkan transparansi biaya. Maka Anda akan lebih mengetahui biaya unit bisnis yang berbeda. Anda akan melihat departemen TI sebagai penentu untuk unit-unit tersebut.

Untuk meningkatkan transparansi, fokuslah pada visibilitas, akuntabilitas, dan pengoptimalan saat pindah ke cloud. Untuk informasi selengkapnya, lihat Membangun organisasi yang sadar biaya.

Antipattern: Berinvestasi dalam teknologi baru tanpa melibatkan bisnis

Departemen TI sering menginvestasikan sumber daya manusia dan keuangan yang signifikan dalam membangun dan menyebarkan platform dan alat yang kuat. Tapi, kadang-kadang TI gagal mempertimbangkan unit bisnis dan kebutuhan mereka selama fase desain dan pengembangan. Kelalaian ini mengakibatkan platform baru memiliki relevansi minimal untuk unit bisnis. Karyawan kemudian ragu-ragu untuk menerima teknologi baru. Adopsi yang buruk atau lambat dapat terjadi. Rasa frustrasi juga muncul di dalam departemen TI ketika unit bisnis tidak menggunakan platformnya.

Contoh: Menyiapkan platform tanpa melibatkan unit bisnis

Departemen TI dari perusahaan analisis data menyiapkan dan menyesuaikan platform Azure tanpa melibatkan unit bisnis apa pun. Saat menggunakan platform, pengembang unit bisnis:

  • Sadarilah bahwa mereka tidak memiliki izin yang dibutuhkan untuk penyebaran.
  • Hanya dapat menggunakan jumlah layanan terbatas.
  • Keluarkan tiket dukungan, yang memperpanjang siklus persetujuan.
  • Mulai meragukan platform baru.

Pada akhirnya, beberapa pengembang membeli langganan Azure sendiri untuk menghindari kerumitan peraturan TI. IT bayangan muncul. Karena perusahaan memiliki sedikit kendali atas IT bayangan, risiko keamanan yang tinggi muncul.

Hasil yang disukai: Libatkan unit bisnis dalam pengambilan keputusan

Hindari membuat silo TI saat menyebarkan platform cloud yang siap digunakan perusahaan. Libatkan pengembang dan pembuat keputusan teknis (TDM) dari unit bisnis dalam proses desain dan pengembangan. Untuk meningkatkan adopsi platform, dengarkan masukan unit bisnis.

Lihat Mulai dengan zona landasan skala perusahaan Kerangka kerja Adopsi Cloud untuk praktik terbaik Azure dan prinsip desain yang meningkatkan kecepatan adopsi dan disesuaikan dengan pengembang. Mencapai keseimbangan yang tepat antara kepatuhan dan fleksibilitas. Misalnya, temukan cara untuk memenuhi kebijakan tata kelola dan keamanan sambil menjaga lingkungan pembangunan tetap gesit.

Antipattern: Lakukan outsourcing pada fungsi bisnis inti

Mitra konsultasi dan penyedia layanan terkelola (MSP) dapat memainkan peran penting dalam perjalanan cloud. Tapi, perusahaan harus berhati-hati bahwa pekerjaan mitra dan MSP tidak memberikan nilai paling besar dalam bisnis mereka. Perusahaan yang melakukan outsourcing tanggung jawab kepada MSP atau konsultan cloud seharusnya tidak bergantung pada penyedia ini.

Contoh: Lakukan outsourcing pada adopsi dan migrasi cloud

Sebuah lembaga penelitian memiliki proyek migrasi cloud yang disiplin terhadap waktu. Untuk mempersingkat perjalanan adopsi cloud, lembaga tersebut menyewa MSP untuk membangun fondasi Azure dan menerapkan migrasi. Alih-alih belajar tentang fase adopsi cloud dan membangun kemampuan, lembaga tersebut memilih untuk menyerahkan semua tanggung jawab Azure kepada MSP. Karena lembaga ini tidak memiliki pengetahuan cloud atau Azure, MSP memimpin semua keputusan, sehingga lembaga bergantung pada MSP.

Hasil yang disukai: Jadikan area desain yang penting sebagai tanggung jawab perusahaan

Ingatlah bahwa outsourcing merupakan strategi pemotongan biaya yang baik. Tapi, buat keputusan di dalam perusahaan Anda ketika mereka melibatkan bidang desain penting ini:

  • Pemerintahan
  • Risiko
  • Kepatuhan
  • Identitas

Simpan tanggung jawab di dalam perusahaan dan area lain yang sangat penting untuk keamanan Anda. Gunakan mitra eksternal untuk mempercepat perjalanan adopsi. Tapi, agar tidak bergantung pada penyedia, jangan melakukan outsourcing pada segalanya.

Antipattern: Pekerjakan pembuat keputusan teknis, dan bukan mengembangkan insinyur cloud

Perusahaan memprioritaskan untuk menemukan personil yang tepat. Akibatnya, perusahaan sering menyewa atau membangun TDM selama fase adopsi cloud awal. Perjalanan cloud yang sukses bergantung pada TDM. Tetapi yang lebih penting, adopsi cloud membutuhkan insinyur dengan mentalitas fokus pada tujuan dan kemampuan teknis yang mendalam.

Contoh: Hanya sewa TDM

Sebuah lembaga penelitian mempekerjakan beberapa TDM untuk memimpin perjalanan cloud-nya. Setelah fase konsep tingkat tinggi awal berakhir, fase implementasi dimulai. Lembaga ini kemudian menyadari bahwa penyebaran cloud berbeda dari penyebaran lokal. Perlu upaya rekayasa cloud ekstra untuk menerapkan konsep infrastruktur sebagai kode (IaC) dengan benar dan tata kelola berbasis kebijakan.

Hasil yang disukai: Gunakan insinyur cloud untuk fase implementasi

Ingatlah bahwa insinyur sangat penting untuk menerapkan konsep otomatisasi cloud dan zona landasan dengan benar. Tanggung jawab dan tugas dapat berubah secara signifikan ketika Anda mengadopsi model layanan. Dengan mengalihkan tanggung jawab ke penyedia cloud, Anda dapat masuk ke produksi lebih cepat. Anda juga dapat menggunakan TDM untuk pengambilan keputusan, tetapi pekerjakanlah insinyur cloud yang mampu menangani tugas-tugas yang membutuhkan pengetahuan teknik mendalam. Maka Anda akan menyadari keuntungan yang disediakan cloud.

Langkah berikutnya