Keşke hızlı BT operasyonları (ITOPs) yalnızca doğru takımların seçilmesiyle ilgili olsaydı. Bunun yerine, BT’de sıklıkla olduğu gibi, iş sonuçları sağlayan optimum yazılım ve hizmet sunumunun sağlanması, “insanların sorunlarının” çözülmesini de içerir.
Yönetilen hizmetler sağlayıcısı (MSP) platform tedarikçisi Popx’in teknoloji sorumlusu Andy Venables, “İnsanların yaptıklarını gördüklerimizle yapmaları gerektiğini düşündüklerimiz arasında büyük bir boşluk var” diyor. “Ve yaptığımız şey gerçekten büyük bir yatırım olabilir; örneğin e-posta yerine tamamen farklı bir düşünce süreci gerektirir.”
BT şeflerinin yatırım yapmadan önce bir araç üzerinde ödevlerini yapmaları çok önemlidir. Venables, çok az kişinin operasyonel iyileştirmelerden emin olacak kadar bilgi sahibi olduğunu söylüyor. Bir araç edinip daha fazlasını öğrendiklerinde artık çok geç olabilir.
Örnek olarak Venables, bu yıl Oracle proje maliyetlerinin 20 milyon £’dan 100 milyon £ civarına çıkmasının ardından mali sıkıntı ilan eden Birmingham Şehir Konseyi’ne işaret ediyor. “Bu, ne soracaklarını veya ne tür bir sorunla karşılaşabileceklerini bilmedikleri ve doğru güvenlik önlemlerine sahip olmadıkları tipik bir durum gibi görünüyor” diyor.
Venables, böyle bir kaderden kaçınmanın büyük ölçüde BT tedarikçisi ile müşteri arasındaki ilişkinin iyileştirilmesine bağlı olduğunu öne sürüyor. BT liderlerini, kuruluşlarının tam olarak neye ihtiyaç duyduğunu ve sistemin nasıl çalışmasını istediklerini öğrenmeleri, ardından üretkenliği ve müşteri deneyimini artırmak için entegrasyonlar ve self servis otomasyonlar konusunda tam şeffaflıkla onlara rehberlik etmek üzere tercih ettikleri BT sağlayıcısıyla birlikte çalışmaları konusunda teşvik ediyor. mesai.
“Her zaman buna meydan okuyabilirler ama en azından ‘bizim işimiz’ ile başladık. Eğer bu mantıklıysa, güveni kazanırsınız ve döngüde ilerleyebilirsiniz” diyor.
Önce ilk şeyler, sonra geri kalanı
Venables’a göre ServiceNow müşterileri, sektördeki beceri eksikliği ve bir araya getirilmiş uygulamalara ek olarak sıklıkla teknik borçtan, platformun yanlış yapılandırılmasından veya ITIL uyumunun eksikliğinden muzdarip oluyor. Venables, “Bir takımın şekli o kadar bozulabilir ki artık ITIL yöntemiyle çalışmaz hale gelebilir” diye uyarıyor. “Stabil hale geldikten sonra para tasarrufu sağlayan gerçek otomasyon hakkında konuşmaya başlayın” diye ekliyor.
Xdesign Ürün Teknolojileri Sorumlusu (CPTO) Jeff Watkins’e göre sürekli teslimat, BT karar vericilerinin istediklerini ve beklediklerini düşündükleri ile üretime teslim edilenler arasındaki farkların en aza indirilmesinde önemli bir rol oynayabilir.
Watkins, “Haftada birkaç kez veya daha fazla yayın yapıyorsanız daha az korkutucu olur” diyor. “Sayfaya veya uygulamaya yeni bir widget koyuyoruz. Yanlış giderse, özelliği tekrar işaretleyeceğiz.”
Özellikler arka planda dağıtılabilir ve kullanıcı için çalışmıyorsa geri döndürülebilir, en son güncelleme üzerinde sürekli olarak yineleme yapılabilir, A/B testi eklenebilir ve benzeri; bunların tümü daha hızlı, daha çevik mühendislik uygulamalarına ve kullanım sırasında kullanıma sunulmasına katkıda bulunur. Beklentileri daha iyi yönetmenin ve aynı zamanda bu beklentileri karşılamanın mümkün olduğunu söylüyor.
Watkins, “Bunun mümkün olduğu kadar çoğunu otomatikleştireceğiz” diyor. “Düğümleri mavi/yeşil olarak işaretlemek de dahil, böylece hiçbir şeyi kaldırmadan ekosistemin bazı bölümlerine konuşlandırabilirsiniz.”
İnsanların yeni bir sürümü beklerken hayal kırıklığına uğramamalarını sağlamak için BT liderlerini hızlı geri bildirim döngülerini etkinleştirmeye çağırıyor.
Bu, dahili geliştirici kaynakları bir dijitalleştirme projesi için kullanıldığında da aynı derecede geçerlidir. JetBrains eklenti sağlayıcısı Digma’nın genel müdürü Nir Shafrir, BT liderlerinin geliştirici düzeyinde gerçek zamanlı olarak sürekli geri bildirim sağlayabileceğini ve Digma’nın durumunda JetBrains IntelliJ entegre geliştirmesindeki Java koduyla, dağıtılırken işbirliğine dayalı kod iyileştirmesini hızlandırabileceğini belirtiyor. ortam (IDE).
Yeni bir dijitalleştirme projesinin yarattığı tüm heyecanla birlikte, geliştirilen yazılımın tüm yaşam döngüsüne daha az önem vermek kolaydır. Shafrir, “Java birçok zorluğu da beraberinde getiriyor; insanlar şirketlerden ayrılıyor ve kimse kodu kimin yazdığını veya nasıl değiştirileceğini bilmiyor, örneğin Java uzun yıllardır oradaydı” diyor. “Geliştiriciler hakkında pek konuşulmayan bir ‘insan sorunu’ olabilir.”
Yanlış iletişim sistemi
Geliştirici ekipleri ile “iş türleri” arasındaki iletişim sorunlu olabilir. Geliştiriciler genellikle müşterilerin istediklerini sunmak için uzun saatler boyunca çok çalışırlar. Ancak Shafrir, çabaların sıklıkla başarısızlıkla sonuçlandığını, bunun da büyük ölçüde taraflardan birinin veya her ikisinin diğer tarafın gerçekte ne istediğini veya neye ihtiyaç duyduğunu anlama veya açıklama konusundaki başarısızlığından kaynaklandığını söylüyor.
“İkisi arasında her zaman bir duvar olacak, ancak özellikle internetteki tonlarca hizmetin ve yazılımdaki günlük değişikliklerin olduğu bu dönemde. Müşterilerle sadece iş adamlarının iletişim halinde olması sorun oluyor” diyor.
Geliştiricilerin genellikle müşterilerin ürünü nasıl kullandıklarına dair çok az fikirleri vardır; bunun en önemli sebebi kod yazıp “onu çöpe atmaları”dır.
“O zaman sinir bozucu oluyoruz [developers] Kalitemizin çok düşük olduğunu ve bunun iyi bir iş olmadığını, yeterince sıkı çalışmadığımızı ve diğer şeyleri söyledik” diyor Shafrir.
Shafrir, BT liderlerine iki ekip arasındaki “duvarı yıkmalarını” tavsiye ediyor. Geliştiricilere bilgi verilirse ve kodun müşteri ortamında nasıl performans gösterdiğini tam olarak (sürekli olarak) bilirlerse, düzeltmeler daha hızlı gerçekleştirilebilir. Elbette bu, bir projedeki tüm paydaşların desteğini almak anlamına gelebilir.
“Kurumun yarısı bunun bir parçası değilken nasıl dijital dönüşüm yapabilirsiniz?” diyor Shafrir.
Açık telemetri gibi yeni teknolojiler ve açık protokoller, ölçeklendirme sorunları, yavaşlık, performans sorunları ve çoklu hatalara ilişkin bir görünüm sağlamak üzere canlı ortamların izlenebileceği anlamına gelir. Ancak sorun kodun içinde olsa bile, tüm bu veriler genellikle BT ve operasyonlarda “büyük, güzel bir kontrol panelinde” bulunur.
Bu, onların göremediği bir şeydir ve bir şeyler çok ters gitmediği sürece; geliştiricileri de bunu göremiyor. “Bu aslında bir SaaS’ta dijital dönüşümü engelliyor [software-as-a-service] veya bulut ortamı” diyor Shafrir.
Teslimatı engelleyen ‘büyük resim’ unsurları
Uygulama yaşam döngüsü yönetimi (ALM) uzmanı Adaptavist’in teknoloji şefi Jon Mort, en başlangıçta, bir dijital dönüşüm girişimine başlarken, BT liderlerinin istenen dönüşümü ileriye taşıyacak mümkün olan en küçük değişikliği tespit ederek başlamalarını öneriyor.
Mort, “Çözüm ortağımızdan bazı geri bildirimler alıyoruz, bazılarını da çözüm ortaklarımızla birlikte sahada dinleyerek bunları paketliyoruz” diyor.
BT liderlerinin, belirli zaman aralıklarına sahip projeler yerine yazılım yeniliği üzerine ürün odaklı düşünmeyi daha fazla kullanmasını öneriyor. Mort için güvenilir ortaklıklar veya iş ortağı ekosistemleri, dahili BT ekiplerinin artan karmaşıklık ve zorluklarla başa çıkmalarına yardımcı olmak açısından da kritik önem taşıyor.
“Bu sadece çözüm ortağı meselesi değil. Mort, bunun ne kadar açık olduğuna ve kullanabileceğiniz uygulamalar ve entegrasyonlar veya güvenebileceğiniz bir kullanıcı topluluğu olup olmadığına bakıyorsunuz” diyor.
Her şeyden önce BT liderlerinin, dijitalleştirme planlarının gerçekten yenilikçi olup olmadığını ve müşterilere değer sunup sunmadığını değerlendirmelerini tavsiye ediyor. Cevap gerçekten “gerçekten değil” ise Mort, odak noktasının teknolojiyi süper güvenilir hale getirmek ve arka planda kalmasına izin vermek olduğunu söylüyor.
Açıkçası, yazılım sürümünün optimize edilmesi dijitalleştirmede başarı için şarttır. Ancak BT operasyonlarının aynı zamanda yeni yazılım destekli iş girişimleri akışını ve genellikle dijitalleştirme girişimleriyle ilişkilendirilen sürekli güncellemeleri desteklemeye ve yönetmeye de hazır olması gerekir. Pazaryeri Also Cloud’un baş müşteri sorumlusu Mark Appleton’a göre, BT liderlerinin etkili yazılım ve hizmet dağıtımları sunarken karşılaştığı operasyonel zorluklar arasında artan veri kullanımı ve süper uygulamalardan sürekli mevcut siber güvenlik risklerine kadar sorunlu alanlar yer alıyor.
Computer Weekly’nin görüştüğü uzmanların tavsiyesi, BT liderlerinin, geleceğe hazır altyapı ve uzun vadeli yazılım bakımı için net araştırma ve bütçeleme ile dijitalleştirme projesi dağıtımları için BT operasyonlarını hazırlaması gerektiği yönünde. Venables, BT personelinin eğitiminin gelecekteki başarının anahtarı olduğunu ve kullanıma hazır bir ürünü dijitalleştirme stratejisine uyacak şekilde bükmenin cazibesinden kaçındığını belirtiyor.