Migros One artan çevrimiçi talebe altyapısını nasıl uyarladı?

Migros One, AWS vaka anlatımına göre altyapı dönüşümünü yalnız daha çok trafiği karşılamak için değil, küçük mühendislik ekibinin operasyon yükünü azaltmak için de ele aldı. Bulut hizmetleriyle kapasite ve uygulama dağıtımı daha esnek hale getirilmeye çalışıldı. Ofise taşınabilecek öğrenim, iş hacmi büyürken aynı ekibe daha çok manuel takip yüklememek. Kapasite artışı, işin hangi adımının tekrarlandığı ve kimin kontrol ettiğiyle birlikte düşünülmeli.

Bir ekip başarılı olduğunda daha çok talep alabilir. Başlangıçta kişisel takip ve hızlı mesajlarla çözülen işler, hacim artınca karışır. Aynı yöntemle daha hızlı çalışmak her zaman yeterli olmaz; işin düzenini yeniden değerlendirmek gerekir.

Migros One vakasında neden dönüşüm istendi?

AWS’nin Migros One vakası, küçük mühendislik ekibinin altyapı işletmesinden çok müşteri değerine odaklanmak istediğini anlatıyor. Metin 2018’deki bulut dönüşümünü ve 2022’den itibaren yeni iş yükleri için yararlanılan programı belirtiyor. Veri taşımanın uygun olmadığı koşullarda farklı bağlantı düzeninin kullanıldığı da açıklanıyor.

Bu, hizmet sağlayıcının müşteriyle birlikte yayımladığı anlatım. Trafiğin karşılanması, aynı oranda satış veya kar artışı demek değildir. İlginç nokta ekibin sürekli altyapı işiyle uğraşması yerine müşteriye katkı verecek görevlere alan açma tercihi.

Birinci öğrenim: Büyüyen yükün yerini bulun

Toplam talep artıyor demek sorunu açıklamaz. Giriş, kontrol, onay veya son teslim adımlarından hangisi birikiyor? Her adımı aynı şekilde büyütmek gereksiz kaynak kullanabilir. Darboğazı tek bir gerçek dosyanın akışında arayın.

Örneğin yeni müşteri sayısı artarken kayıt açma hızlı olabilir ama sözleşme kontrolü bekliyor olabilir. İşin başında daha çok kişi görevlendirmek son kontrolü hızlandırmaz. Aksine kontrol noktasında bekleyen dosyaları artırabilir.

Bekleme ile işlem süresini ayırın. Bir dosya iki gün sistemde kalmış olabilir ama üzerinde çok kısa çalışılmıştır. Sürenin geri kalanı başka bilgiye bağlıdır. Bu fark, yeni araçtan önce teslim düzenini değiştirme ihtiyacı gösterebilir.

İkinci öğrenim: Tekrarı kapasite diye satın almayın

Bir iş hacmi artınca önce daha çok insan veya daha büyük sistem düşünülür. Ancak aynı bilginin farklı listelere yazılması gibi tekrarlar korunursa yeni kapasite de o işe gider. Önce hangi tekrarın gerekli olmadığını inceleyin.

Dosya adı, geçerli kaynak ve durum kaydı açık olduğunda ekipler aynı bilgiyi yeniden doğrulamak zorunda kalmayabilir. Bu bütün kontrolü kaldırmak değildir. Kontrolün doğru noktada yapılmasını ve sonraki kişinin güvenilir kayda ulaşmasını sağlamaktır.

Küçük bir değişikliği gerçek işte deneyin. PDCA ile süreç iyileştirme, sadece daha hızlı çalışma hedefi yerine belirli bir tekrarın azaltılmasını sınamanıza yardımcı olur.

Üçüncü öğrenim: Esneklikle sorumluluğu ayırmayın

İşi hızla büyütebilen bir sistem faydalıdır. Ancak erişim, veri kaynağı ve son kontrol belirsizse sorun da daha geniş ölçekte yayılabilir. Hangi değişikliğin kim tarafından onaylanacağı açık kalmalı.

Kapasite planında olağan dışı durumları da düşünün. Sistem çalışmazsa hangi iş bekleyebilir? Hangi teslim başka yoldan yapılabilir? Her dosyaya aynı aciliyet verilmesi, gerçekten önemli işi ayırmayı zorlaştırır.

Küçük ekibin bütün istisnaları tek kişiye taşıması sürdürülebilir olmayabilir. Sık sorunları açıklamak ve destek sorumluluğunu paylaşmak gerekir. Kullanıcıya yardım verilirken yardım eden ekibin gelişim ve bakım zamanı da korunmalıdır.

Açılan kapasitenin ne için kullanılacağını seçin

Tekrar azalınca açılan zamanı yeni işlere ayırmak mümkün olabilir. Ancak ekip sürekli daha çok teslim yapmaya zorlanıyorsa bakım ve kontrol yine aksar. Hangi zamanın müşteri geliştirmesine, hangisinin sistemi güvenilir tutmaya ayrılacağını konuşun. Her boşluğu yeni görevle doldurmak zorunda değilsiniz.

Kapasiteyi yalnız dosya sayısıyla anlatmayın. İş türü değişmişse aynı adet daha çok emek gerektirebilir. Geçmişte standart başvurular ağırlıktayken yeni dönemde özel koşullu müşteriler artmış olabilir. Farkı raporda görünür tutun. Kullanıcının daha fazla soru sorması yeni açıklama ihtiyacını gösterebilir.

Yeni uygulamanın bakımını kimin üstleneceği belli olsun. Küçük ekip her sorunu kendi çözüyorsa dış hizmetin faydası sınırlı kalabilir. Yardım, kayıt ve istisna yolunu güncel tutmak gerekir. Büyüme yalnız daha büyük sistem değil daha anlaşılır görev düzeni oluşturmalı. İlk incelemede çalışanın hangi işten gerçekten kurtulduğunu sorun; ekrana daha hızlı giriş yapmak bütün yükü açıklamaz.

Ofiste doldurulmuş büyüme değerlendirmesi

Şöyle bir durum düşünün: Operasyon ekibiniz yeni müşteri talebi alıyor. Her talep önce e-postada, sonra ortak tabloda, ardından raporda yeniden yazılıyor. Dosya sayısı arttıkça ekip aynı bilgiyi takip etmek için daha çok zaman harcıyor.

Önce gerekli alanların aynı anlamı taşıdığını kontrol edin. Bir listede hizmet başlangıcı, diğerinde sözleşme tarihi varsa alanlar benzer görünse de aynı değildir. Tek kayıt oluştururken farklı bilgiyi yanlışlıkla birleştirmeyin.

Yeni düzeni bütün müşteri dosyalarına bir anda yaymak yerine küçük bir görev grubunda inceleyin. Kullanıcı bir dosyanın durumunu gerçekten görebiliyor mu? Son onaylı bilgiye ulaşabiliyor mu? Eski listeler hala manuel güncelleniyorsa yükün azalmadığını fark edebilirsiniz.

Küçük ekibin zamanını nereye ayırmalı?

Operasyon işini azaltınca açılan zamanı otomatik olarak yeni teslimlerle doldurmayın. Bakım, öğrenme ve kalite kontrolü de gelecekteki kapasiteyi korur. Herkes sürekli acil işi çözüyorsa aynı sorunların tekrar nedeni incelenemez.

Ekip üyelerinden en sık tekrar eden destek talebini seçmelerini isteyin. Bir açıklama notu, daha net alan veya uygun örnek bu yükü azaltabilir. Her soruna yeni sistem gerekmez. Kullanım düzenini iyileştirmek de ölçekleme kararının parçasıdır.

Hazırladığınız sonuç notunda iş hacmi, tekrar ve kontrol ihtiyacını ayrı gösterin. Raporlarda gözlem ve yorumu ayırmak, büyüme anlatısının gerçek yükü gizlemesini önler.

Migros One vakasının küçük ekipler için güçlü dersi, kapasiteyi sadece makine veya kişi sayısı olarak görmemek. İşin nasıl hazırlandığını, aktarıldığını ve kontrol edildiğini birlikte düşünmek gerekir. Bu analiz yaklaşımını geliştirmek için kariyer gelişim kursunun programını inceleyebilirsiniz.

Sık sorulan sorular

Buluta geçmek her şirket için doğru çözüm müdür?

İhtiyaç, veri koşulları, güvenlik ve maliyetlere bağlıdır. Bu vaka genel bir satın alma önerisi değildir. Önce hangi kapasite ve işletme sorununun çözülmek istendiğini belirlemek gerekir.

Trafik artışı satış başarısını kanıtlar mı?

Hayır. Trafik kullanım hacmini gösterir. Satın alma, gelir ve kar farklı göstergelerdir. Sistemin yükü karşılaması ticari değerlendirmeye bilgi verebilir ama tek başına bütün sonucu açıklamaz.

Küçük ofis ekibi nereden başlamalı?

Bir dosyanın akışını izleyerek tekrar ve bekleme noktalarını ayırabilir. Aynı bilginin kaç kez yazıldığına ve hangi onayın beklendiğine bakın. Önce küçük değişikliği sınamak daha anlaşılır olabilir. Bir küçük değişiklik seçip PDCA ile sınamak uygun başlangıç olabilir.

Kontrol sayısını azaltmak riskli değil mi?

Gerekli kontrol korunmalıdır. Ama aynı bilgiyi farklı listelerde tekrar incelemek her zaman daha güvenli değildir. Geçerli kaynak, doğru sorumlu ve açık istisna yolu daha işlevli bir düzen kurabilir.