Bulut kurumsal kötü model
Müşteriler genellikle kurumsal yapılarında bulut benimseme kötü modellerini deneyimler. Birçok faktör bu sorunlara neden olabilir:
- Toolsets
- İş Ortakları
- Mühendis
- Yanlış hizalanmış BT departmanları
Başarılı bir bulut benimseme senaryosunda bu faktörlerin rolünü anlamak önemlidir.
Kötü model: BT'ye maliyet merkezi olarak davranın
Birçok şirket BT departmanlarını maliyet merkezi olarak değerlendirmektedir. Bu yaklaşım, BT'nin şirkete değer katmadığı algısına yol açabilir. Çalışanlar BT'yi bir etkinleştirici yerine sağlayıcı olarak görüntülediğinde, önerilmez. Şirketin doğru yeteneği çekmesi de zor. Azaltılmış motivasyon ve uzun yaşam döngüsü süreleri sonucu. BT'den gelen çalışma kalitesi olumsuz etkilenebilir ve silolar ve fiefdomlar gelişebilir.
Örnek: BT'ye maliyet merkezi olarak davranma
Bir şirket, BT departmanını finans direktöründen (CFO) sorumlu bir maliyet merkezi olarak yönetir. Yönetim kurulu, BT'yi şirketin en büyük maliyet etmenlerinden biri olan yavaş bir hizmet sağlayıcısı olarak algılar. Yönetim kurulu, mobilite iş biriminin BT departmanının sipariş ettiği varlıkların çoğunu tükettığını fark etmez. BT, tüm iş birimlerinin kullanması için bir veri merkezi satın alır, ancak hareketlilik iş birimi bu büyük boyutlu varlığı alır. Pano, BT'yi etkinleştirici veya iş ortağı olarak görüntülemez.
Tercih edilen sonuç: BT'yi etkinleştirici olarak görüntüleme
BT departmanınızı maliyet merkezi olarak yönetmek yerine şu yaklaşımlardan birini göz önünde bulundurun:
- Geri ödeme: İş birimleri BT maliyetlerini bütçelerindeki işletim giderleri gibi ele alır.
- Geri gösterme veya geri tanıma: BT bir aracı olarak çalışır. İşletmeye geri dönen raporlarda BT, doğrudan maliyetleri ilgili iş birimlerine bağlar.
Maliyeti ve iş şeffaflığını artırmak için bulutu bir araç olarak kullanın. Örneğin, maliyet şeffaflığını artırmak için bir Maliyet Yönetimi uzmanlık alanı uygulayın. Ardından farklı iş birimlerinin maliyetini daha iyi fark edersiniz. BT bölümünü bu birimler için etkinleştirici olarak görüntüleyebilirsiniz.
Şeffaflığı geliştirmek için buluta geçerken görünürlük, sorumluluk ve iyileştirmeye odaklanın. Daha fazla bilgi için bkz. Maliyet bilincine sahip bir kuruluş oluşturma.
Kötü model: İşletmeyi dahil etmeden yeni teknolojiye yatırım yapın
BT departmanları genellikle sağlam platformlar ve araç setleri oluşturmak ve dağıtmak için önemli insan ve finansal kaynaklara yatırım yapar. Ancak BT bazen tasarım ve geliştirme aşamalarında iş birimlerini ve ihtiyaçlarını dikkate alamazsınız. Bu eksiklik, iş birimleri için en düşük ilgi düzeyine sahip yeni platformlara yol açar. Çalışanlar daha sonra yeni teknolojiyi kabul etme konusunda tereddüt ediyor. Düşük veya yavaş benimseme sonuçlanabilir. İş birimleri platformlarını kullanmadığında da BT içinde hayal kırıklığı olur.
Örnek: İş birimlerini dahil etmeden platform ayarlama
Bir veri analizi firmasının BT departmanı, herhangi bir iş birimi dahil etmeden bir Azure platformu ayarlar ve özelleştirir. Platformu kullanırken, iş birimi geliştiricileri:
- Dağıtım için gereken izinlere sahip olmadıklarını fark edin.
- Yalnızca sınırlı sayıda hizmet kullanabilir.
- Onay döngülerini uzatan destek biletleri oluşturun.
- Yeni platformdan şüphe etmeye başlayın.
Sonunda, bazı geliştiriciler BT kurallarının ve düzenlemelerinin zorluklarını önlemek için kendi başlarına bir Azure aboneliği satın alır. Gölge BT görünür. Şirket gölge BT üzerinde çok az denetime sahip olduğundan, yüksek güvenlik riskleri ortaya çıkar.
Tercih edilen sonuç: Karar alma sürecine iş birimlerini dahil etme
Kurumsal kullanıma hazır bir bulut platformu dağıtırken BT siloları oluşturmaktan kaçının. Tasarım ve geliştirme süreçlerinde iş birimlerinden geliştiricileri ve teknik karar alıcıları (TDM) dahil edin. Platform benimsemesini geliştirmek için iş birimi girişlerini dinleyin.
Benimseme hızını artıran ve geliştiricilere göre uyarlanan Azure en iyi yöntemleri ve tasarım ilkeleri için kurumsal ölçekli Bulut Benimseme Çerçevesi giriş bölgeleriyle başlama bölümüne bakın. Uyumluluk ve esneklik arasında doğru dengeyi sağlayın. Örneğin, geliştirme ortamlarını çevik tutarken idare ve güvenlik ilkelerini karşılamanın yollarını bulun.
Kötü model: Dış kaynak temel iş işlevleri
Danışmanlık iş ortakları ve yönetilen hizmet sağlayıcıları (MSP'ler) bulut yolculuğunda önemli bir rol oynayabilir. Ancak şirketler, iş ortaklarının ve MSP'lerin çalışmalarının işlerinde en fazla değeri sağlamadığını dikkate almalıdır. SORUMLULUKları MSP'lere veya bulut danışmanlarına dış kaynak sağlayan şirketler bu sağlayıcılara bağımlı olmamalıdır.
Örnek: Dış kaynak bulutu benimseme ve geçiş
Bir araştırma enstitüsünün zaman açısından kritik bir bulut geçişi projesi vardır. Bulut benimseme yolculuğunu kısaltmak için Azure temelini oluşturmak ve geçişi uygulamak için bir MSP kiralar. Kurum, bulut benimseme aşaması hakkında bilgi edinmek ve becerileri geliştirmek yerine tüm Azure sorumluluğunu MSP'ye devretmeyi tercih eder. Enstitüde bulut veya Azure bilgisi olmadığından, MSP tüm kararların başına geçer ve bu da enstitünün MSP'ye bağımlı olmasıdır.
Tercih edilen sonuç: Kritik tasarım alanlarını şirketin sorumluluğunda yapın
İyi bir maliyet kesme stratejisi olarak dış kaynak oluşturmayı göz önünde bulundurun. Ancak, şirketinizde bu kritik tasarım alanlarını içerdiklerinde kararlar alın:
- İdare
- Risk
- Uyumluluk
- Kimlik
Güvenlik varlığınız için kritik öneme sahip olan bu ve diğer alanlarda şirket içinde sorumluluğu koruyun. Benimseme yolculuğunu hızlandırmak için dış iş ortaklarını kullanın. Ancak sağlayıcılara bağımlı olmaktan kaçınmak için her şeyi dış kaynak olarak yapmayın.
Kötü model: Bulut mühendisleri geliştirmek yerine teknik karar alıcıları işe alma
Şirketler doğru personelin bulunmasına önem sağlar. Sonuç olarak, genellikle ilk bulut benimseme aşamalarında TDM'leri işe alır veya oluştururlar. Başarılı bulut yolculukları TDM'leri kullanır. Ancak daha da önemlisi, bulut benimsemeleri tamamen uygulamalı düşüncelere ve derin teknik becerilere sahip mühendislere ihtiyaç duyar.
Örnek: Yalnızca TDM'leri işe alma
Bir araştırma enstitüsü, bulut yolculuğuna liderlik etmek için birkaç TDM'yi işe alır. İlk üst düzey kavram aşaması sona erdikten sonra uygulama aşaması başlar. Daha sonra kurum bulut dağıtımlarının şirket içi dağıtımlardan farklı davrandığını fark eder. Kod olarak altyapı (IaC) kavramlarını ve ilke temelli idareyi düzgün bir şekilde uygulamak için fazladan bulut mühendisliği çalışması gerekir.
Tercih edilen sonuç: Uygulama aşaması için bulut mühendisleri kullanma
Mühendislerin bulut otomasyonu ve giriş bölgesi kavramlarını düzgün bir şekilde uygulamak için gerekli olduğunu unutmayın. Hizmet modellerini benimsediğinizde sorumluluklar ve görevler önemli ölçüde değişebilir. Sorumlulukları bir bulut sağlayıcısına kaydırarak üretime daha hızlı geçebilirsiniz. Ayrıca karar vermek için TDM'leri kullanabilirsiniz, ancak derin mühendislik bilgisi gerektiren görevler için yetenekli bulut mühendisleri kullanabilirsiniz. Ardından bulut tarafından sunulan avantajların farkına varacaksınız.