SAP ve yapay zeka teslimatı için yedi danışmanlık çerçevesi

Bir SAP ya da yapay zeka programı tıkandığında nedeni genellikle yapısaldır ve yedi basit çerçeve onu ortaya çıkarır. Mevcut durumu haritalayın. Kimin neye karar verdiğini bir RACI ile belirleyin. İşi iş yetkinliklerine bağlayın. Kök nedenleri beş neden yöntemiyle bulun. Gereksinimleri MoSCoW ile sıralayın. Riskleri, programı gerçekten durdurabilecek olana göre sıralayın. Her aşamanın ardından gerçek bir post-mortem yapın. Bu rehber, SAP ve yapay zeka teslimatında çalışan program yöneticileri, danışmanlar ve sponsorlar için. Aşağıdaki tabloyla başlayın: belirtinizi bulun ve önce ona uyan çerçeveyi kullanın.

Katar'daki orta ölçekli bir medya şirketi, SAP'yi birkaç bölgede devreye alıyordu. Finans ve satın alma ilk aşamada canlıya geçecekti. Şirket ayrıca raporlamasına yapay zeka tahmin modelleri de eklemek istiyordu.

Altıncı haftaya gelindiğinde gecikmeler sızmaya başlamıştı. İş kullanıcıları gereksinimleri onayladıklarını, ama ne alacakları konusunda hâlâ kafalarının karışık olduğunu söylüyordu. Yapay zeka kullanım senaryoları önerilmişti ve verinin kime ait olduğunu ya da çıktının nasıl kullanılacağını kimse söyleyemiyordu. İnsanlar toplantılara geç geliyor ya da hiç gelmiyordu.

Tam o ara dönemdi. Başarısızlık demek için çok erken. Kendiliğinden düzeleceğini varsaymak için çok geç.

Çerçeveleri adım adım uyguladık. Hepsi başta hoş karşılanmadı. Bazı oturumlar sessiz geçti. Bazıları yoldan çıktı. Ama yapı işi kolaylaştırdı: ekip aynı yerde dönüp durmayı bıraktı, iş listesi yönetilebilir hale geldi ve yapay zeka kullanım senaryolarının gerçek sahipleri oldu. Proje planlanandan sekiz hafta geç canlıya geçti. Kusursuz değildi. Ama tamamlandı ve ikinci aşama daha sağlam bir zeminde, daha az bilinmeyenle başladı.

Yedisinin de çeşitli uyarlamalarını, Körfez'de, Avrupa'da ve ötesinde SAP, Oracle ve yapay zeka programlarında geçen 23 yıllık teslimat boyunca kullandım. Hiçbiri egzotik değil. Hepsi, belgeleme alıştırması olarak değil disiplinle uygulandığında işe yarar.

Belirtiyi çerçeveyle eşleştirin:

Gördüğünüz belirti	Çerçeve	Ne üretir	Tipik efor
Kullanıcılar gereksinimleri onayladı ama hâlâ kafaları karışık	1. Mevcut durum haritalama	İşin bugün gerçekte nasıl yürüdüğünün ortak haritası	3 ila 5 günlük atölye çalışması
Kararlar toplantılar arasında gidip geliyor	2. Kritik kararlar için RACI	20 ila 30 kilit karar için adı belli karar sahipleri	Bir atölye, ardından uygulatma
Sponsorlar “BT projesinden” uzaklaştı	3. Yetkinlik haritalama	İlerlemenin iş yetkinlikleri olarak raporlanması	Fit-to-Standard içine dahil
Aynı tür hata tekrar tekrar geliyor	4. Beş neden	Değiştirebileceğiniz bir kök neden	Sorun başına bir moderasyonlu oturum
Her şey yüksek öncelikli işaretlenmiş	5. MoSCoW	Gerçekçi bir Must Have listesi olan sıralanmış kapsam	İş ve BT ile ortak bir oturum
Risk kaydı iyi görünüyor ama ekip gergin	6. Risk sıralama	Programı durduran ve yalnızca zorlaştıran risklerin ayrı listeleri	Haftalık 30 dakikalık gözden geçirme
Aynı hatalar aşamadan aşamaya tekrarlanıyor	7. Post-mortem	Sahipleri belli üç ila beş değişiklik	Her aşamadan sonra yarım gün

Bir programın başında en sık yapılan hata, mevcut olanı belgelemeden çözüme atlamaktır. Süreç dokümantasyonu genellikle güncelliğini yitirmiştir. İnsanlar işlerin nasıl yürümesi gerektiğini anlatır, nasıl yürüdüğünü değil. İkisi arasındaki boşluk, uygulama sorunlarının yaşadığı yerdir.

İşe yarar bir mevcut durum haritası, işi yönetenlerle değil işi yapanlarla yürütülen üç ila beş günlük atölye çalışması gerektirir. İçinde sırasıyla süreç adımları, her adımda kullanılan sistemler, elle müdahaleler ve geçici çözümler ile departmanlar arasındaki veri akışları yer alır.

Görünmez hale geldiği için kimsenin anmadığı elle adımlara, o kadar uzun süredir işlediği için artık standart süreç sayılan geçici çözümlere ve herkesin bildiği ama kimsenin düzeltmediği veri kalitesi sorunlarına bakın.

Katar'da mevcut durum haritası dokümantasyondan değil, kullanıcılarla yapılan atölyelerden çıktı. Onaylanmış gereksinimler konusundaki kafa karışıklığı da burada dağılmaya başladı.

Doğru yapıldığında mevcut durum haritası günler sürer. Belge toplama alıştırması olarak ele alındığında aylar sürer ve kimsenin güvenmediği bir ürün çıkarır.

Karar yetkileri, SAP ve yapay zeka projelerinde en sık eksik olan yapısal unsurdur. Herkesin bir görüşü vardır. Son kararı kimin verdiğini kimse bilmez. Kararlar bir sonraki toplantıya gider, o toplantı yönlendirme komitesine havale eder, komite de onları çalışma grubuna geri yollar.

RACI matrisi (Responsible, Accountable, Consulted, Informed: yapan, hesap veren, danışılan, bilgilendirilen) her karara ve çıktıya bir sahip verir. Hesap veren kişi tektir; aynı kişi işi yapan da olabilir ya da bunu devredebilir. Danışılanlar görüş verir. Bilgilendirilenler sonucu öğrenir.

Pratik hali şu: mevcut aşamadaki en kritik yirmi ila otuz kararı listeleyin ve karar vericilerin hazır bulunduğu bir RACI atölyesi yapın. Bir atamaya itiraz ediliyorsa bir şey öğrenmişsiniz demektir: ya yönetişim belirsizdir ya da yetki üzerinde siyasi bir çekişme vardır. Hangisi olursa olsun, bunu on dördüncü haftada değil ikinci haftada ortaya çıkarın.

Uygulatılmayan RACI süstür. İsimler, gerçek yetkisi olan kişilerle örtüşmelidir. Hesap verebilirliği adı belli bir kişi yerine bir rol unvanına vermek, riskin kime ait olduğu konuşmasından kaçınmanın bir yoludur.

SAP ve yapay zeka programları, iş tarafının göremediği çok sayıda teknik faaliyet üretir. Neyin inşa edildiği ile sağlaması gereken sonuç arasındaki bağ soyutlaşır. Sponsorlar uzaklaşır ve aslında iş kararı olan gecikmeler için “BT projesi” suçlanır.

Yetkinlik haritalama, sistem işlevini iş yetkinliğine bağlar: kuruluşun neyi yapabiliyor olması gerektiğine. Satın alma siparişi iş akışının yapılandırılıp yapılandırılmadığını izlemek yerine, kuruluşun tedarikçi faturalarını teslim alındıktan sonra üç gün içinde işleyip işleyemediğini izlersiniz. Yapılandırma mekanizmadır. Yetkinlik sonuçtur.

SAP Activate'te bu, Explore aşamasındaki Fit-to-Standard atölyelerine karşılık gelir. Kapsamdaki her süreç bir yetkinliktir ve SAP standardı ile gereken yetkinlik arasındaki her boşluk bir karardır: standardı kabul etmek, bir varyant yapılandırmak ya da genişletmek. Konuşmayı yetkinlik düzeyinde tutmak, iş tarafının dikkatini geliştirme boyunca canlı tutar ve herkesin kapsamda sandığı ama kimsenin doğrulamadığı yetkinlikleri ortaya çıkarır.

Aynı türden bir sorun sprintler ya da aşamalar boyunca ortaya çıkmaya devam ediyorsa, her örneği ayrı ayrı yamalamak işe yaramaz. Neden, akış yukarısındadır.

Beş neden, en basit kök neden aracıdır. Sorunun neden yaşandığını sorun, sonra bunun neden yaşandığını, değiştirebileceğiniz bir şeye varana kadar. Beş tur genellikle gerçek nedene ulaşır. İki tur çoğunlukla belirtide kalır.

Bir veri taşıma örneği. Deneme yüklemesinde veri kalitesi hataları var: bu, belirtidir. Neden? Kaynak çıkarımında alan eşlemeleri yanlıştı. Neden? Eşleme spesifikasyonu iş tarafındaki veri sahibi tarafından hiç gözden geçirilmemişti. Neden? Veri sahibi ancak eşleme bittikten sonra atanmıştı. Neden? Plan, veri sahibinin katılımını eşleme için bir bağımlılık haline getirmemişti. Kök neden budur ve çözüm bir veri düzeltmesi değil, bir yönetişim kararıdır. SAP veri taşımasının neden başarısız olduğunu anlatan yazım, bu zincirin tam olarak ne sıklıkla ortaya çıktığını gösteriyor.

1. 01Deneme yükleme hatalarıBelirti
2. 02Yanlış alan eşlemeleriYükleme neden başarısız oldu?
3. 03Spesifikasyon hiç gözden geçirilmediEşlemeler neden yanlıştı?
4. 04Sahip çok geç atandıSpesifikasyon neden gözden geçirilmedi?
5. 05Plan bağımlılığı atladıSahip neden geç atandı?

Kök neden bir veri düzeltmesi değil, bir yönetişim kararıdır

Suçlamanın olmadığı bir odada kök neden analizi dürüst yanıtlar üretir. Suçlayıcı bir odada savunmacılık üretir. Moderatörün işi, konuşmayı kişilerde değil süreçte tutmaktır. Yapılandırılmış düşünme ve problem çözme rehberim, neden sormaya başlamadan önce dağınık bir sorunu nasıl parçalayacağınızı anlatıyor.

Her SAP ve yapay zeka kapsam tartışmasında bir mutabakat tuzağı vardır. Kimse ödünleşim yapmak istemez, bu yüzden her şey yüksek öncelikli olur. Her şey yüksek öncelikliyse hiçbir şey değildir ve geliştirme ekibi hepsini yapmaya çalışır.

MoSCoW (Must have, Should have, Could have, Won't have this time) seçim yapmaya zorlar. Must Have, canlıya geçiş için gereken asgari düzeydir. Should Have önemlidir ama engelleyici değildir. Could Have, zaman ve bütçe elverirse istenir. Won't Have ise açıkça ertelenmiştir.

Disiplin, Must Have çizgisindedir. Bir MoSCoW çalışmasının ilk turu genellikle Must Have'e fazlasıyla çok şey koyar. MoSCoW'un kaynağı olan Agile Business Consortium'un DSDM rehberi, Must Have'ler için eforun %60'ını tavan olarak belirler ve daha yükseğe çıkmanın teslimatı riske attığı konusunda uyarır. İlk tur ile gerçekçi liste arasındaki fark çoğunlukla sınanmamış varsayımlardır.

MoSCoW'u iş ve teknoloji aynı odadayken yürütün. Ayrı ayrı yürütüldüğünde BT'nin Must Have listesi ile iş tarafının Must Have listesinin uyumsuz çıktığı görülür ve yapılandırma başlayana kadar kimse bunları uzlaştırmaz.

Çoğu risk kaydı, olasılık ve etkiyle puanlanan, aylık gözden geçirilen ve RAG durumları nadiren değişen uzun listelerdir. Riski kaydederler, ama eylemi yönlendirmezler.

Programı durdurabilecek riskleri, onu yalnızca zorlaştıran risklerden ayırın. İlk grubun sahiplere, müdahale planlarına ve haftalık görünürlüğe ihtiyacı vardır. İkincisinin izlemeye.

Katar'da risk kaydı kâğıt üzerinde iyi görünüyordu, ama herkes gergindi. Aylık değil haftalık gözden geçirilen hızlı bir risk-etki matrisi, gerçek kaygıları ortaya çıkardı.

Ekip gergin olduğu halde iyi görünen bir kayıt, neredeyse her zaman bir şeyi saklıyordur. Gerçek, kayıt değildir; kaydın çevresindeki konuşmalardır. “Dün gece sizi ne uyutmadı?” diye soran haftalık bir gözden geçirme, “14. maddenin durumu nedir?” sorusundan daha fazlasını ortaya çıkarır. SAP risk değerlendirme matrisim, puanlama ve sahiplik için bir şablon sunuyor.

Bir aşamanın ya da canlıya geçişin ardından yapılan post-mortem'ler, aynı hataların bir sonraki aşamada tekrarlanmasını önler. Aynı zamanda takvim baskı altındayken ilk kesilen şeydir.

İşe yarar bir post-mortem dört soru sorar. Neyi başarmayı planladık, neyi başardık? Neler iyi gitti ve tekrarlanmalı? Neler kötü gitti ve nedeni neydi? Neyi farklı yapardık? Sonunda, olanları özetleyen bir belge değil, sahipleri belli üç ila beş somut eylem olmalıdır.

Sık görülen başarısızlık, ekiplerin kararları incelemek yerine savunduğu bir gerekçelendirme alıştırmasıdır. Bakışı ileriye çevirin. Soru, altıncı haftadaki gecikmelere kimin yol açtığı değildir. Soru, bir sonraki aşamada bunları hangi yapısal değişikliğin önleyeceğidir.

Katar'da post-mortem, canlıya geçişin hemen ardından yapıldı ve suçlamaya değil eyleme odaklandı. İkinci aşamanın daha sağlam bir zeminde başlamasının büyük bir bölümü bundandır.

Çerçeveler değişmedi. Nasıl uygulandıkları üç yönden değişti.

Taslak hazırlamak hızlandı; dinlemek hızlanmadı. Yapay zeka araçları artık atölye transkriptlerini ve süreç belgelerini dakikalar içinde ilk geçiş haritasına dönüştürüyor ve SAP Cloud ALM, Fit-to-Standard transkriptlerinden gereksinim taslağı çıkarabiliyor. Atölyelerin kendisi her zamanki kadar sürüyor, çünkü işin özü dinlemek. Taslakta kazanılan zaman, haritayı insanlarla sorgulamaya gitmeli.

RACI taslakları hazır geliyor, zor kısım olduğu yerde duruyor. Genel amaçlı bir yapay zeka asistanı, bir proje başlatma belgesinden ve bir iş paketi listesinden bir dakikada RACI üretir. Disiplin müzakereye kayar: her hücre, yetki ve eskalasyon üzerine gerçek bir konuşma gerektirir. Taslağı hazırlamaktan kazanılan zaman, bu zor konuşmalara harcanmalı.

Odada yapay zeka varken MoSCoW zorlaşır. Yapay zekanın yaptığı bir gereksinim sıralaması inandırıcı, cilalı ve yerel siyaset konusunda çoğu zaman yanlıştır. Onu sorgulamadan kabul eden danışmanlar, boş bir sayfayla başlayan danışmanlardan daha kötü öncelik listeleri üretir. Yapay zeka taslağını bir başlangıç noktası olarak görün, asla yanıt olarak değil.

Bu çerçevelerin üzerine koyduğunuz muhakeme artık daha değerli, daha az değil. Bu becerileri danışman olarak geliştiriyorsanız, SAPopedia'nın kariyer yolları bir SAP kariyerinin her aşamasında hangilerinin önemli olduğunu ortaya koyuyor.

Danışmanlık çerçeveleri nelerdir ve SAP projeleri onları neden kullanır?

Analiz, karar verme ve problem çözme için yapılandırılmış yaklaşımlardır. SAP ve yapay zeka programlarında iş liderlerine, mimarlara, proje yöneticilerine, entegratörlere ve sponsorlara ortak bir yöntem verirler.

Böyle bir yöntem olmadığında her grup kendi zihinsel modeline döner: süreç sonuçları, mimari ya da takvim ve kaynaklar. Mevcut durum haritalama, RACI ve MoSCoW gibi çerçeveler, anlaşmazlığı açık ve çözülebilir kılar. SAP Activate de aşamalar, kapılar ve çıktılar için bir çerçevedir; bu yedisi onun içinde çalışır ve yöntemin tek başına çözemediği yapısal ve insani sorunları ele alır.

SAP uygulamasında mevcut durum haritalama nasıl işler?

Yapılandırma başlamadan önce süreçlerin, mevcut dokümantasyonun nasıl çalışması gerektiğini söylediğine göre değil, gerçekte nasıl çalıştığını belgeler. Süreçleri yürüten kişilerle yapılan atölyelerde oluşturun: adımlar, sistemler, devir teslimler, elle müdahaleler ve geçici çözümler.

SAP Activate'in Explore aşamasındaki Fit-to-Standard atölyelerini besler; mevcut durum burada SAP'nin standart süreçleriyle karşılaştırılan referans noktası olur. Bunu o atölyeler başlamadan tamamlayın, yoksa boşluk analiziniz varsayımlara dayanır.

MoSCoW önceliklendirmesi nedir ve SAP programlarında ne zaman kullanılır?

MoSCoW, gereksinimleri Must have, Should have, Could have ve Won't have this time olarak sıralar. Must Have'ler canlıya geçiş için asgari olanlardır; Won't Have'ler açıkça dışarıda bırakılır, böylece geri sızamazlar.

En çok Explore aşamasında, Fit-Gap bulguları uzantı kararlarını yönlendirirken ve Realize aşamasında, hatalar ile iyileştirmeler geliştirme zamanı için yarışırken işe yarar. Olağan sorun, ilk turda çok fazla Must Have olmasıdır. DSDM, eforun en fazla %60'ının Must Have'lere gitmesini önerir; her birini sorgulayan bir moderatör, iş ve BT aynı oturumdayken sizi oraya getirir.

Bir SAP projesinde etkili bir risk gözden geçirmesi nasıl yürütülür?

Durum güncellemesi olarak değil, bir konuşma olarak. Kaydı gözden geçirmeden önce “Bu hafta kayıtta olmayan en büyük kaygınız nedir?” gibi açık sorularla başlayın.

Her yüksek öncelikli risk için ne değiştiğini, hangi eylemin alındığını, eğilimin iyileşip iyileşmediğini ve müdahale planının hâlâ uygun olup olmadığını sorun. Haftalarca eylemsiz biçimde aynı derecede duran riskler çoğu zaman olduğundan düşük gösterilmiştir. Aktif aşamalarda haftalık gözden geçirin ve yönlendirme komitesine tüm kaydı değil, durumu ve sonraki eylemiyle en önemli beş riski gösterin.

SAP canlıya geçişinden sonra yapılan post-mortem'i işe yarar kılan nedir?

Bir sonraki aşama için somut, uygulanabilir değişiklikler. Olanların özeti bir kayıttır, post-mortem değil.

Neyi başarmak üzere yola çıktığınızı, neyi başardığınızı, neyin işe yaradığını ve neyin yaramadığını ele alın. “Kaynağımız yetersizdi” gibi yüzeydeki açıklamaların altına inin: kaynak planı mı yanlıştı, kapsam mı, yoksa eskalasyon yolu mu bozuktu? Her biri bir sahip ve bir tarihle, üç ila beş değişiklikle bitirin.

Danışmanlık çerçeveleri SAP ortamlarında yapay zeka uygulamasına nasıl yardımcı olur?

Yapay zeka projeleri, SAP projeleriyle aynı yapısal nedenlerle, bir de kendilerine özgü birkaçıyla başarısız olur: sahibi olmayan veri, tanımsız başarı ölçütleri ve çıktıya göre hareket etmek için üzerinde anlaşılmış bir süreç olmaması.

Mevcut durum haritalama, bir modelin ihtiyaç duyduğu verinin kime ait olduğunu ve ne kadar iyi olduğunu gösterir. RACI, çıktıyı kimin doğruladığı, ona göre hareket etmeye kimin karar verdiği ve yanlış olduğunda kimin hesap verdiği sorusunu yanıtlar. MoSCoW, temel kullanım senaryolarını ilginç olanlardan ayırır. Aynı anda on beş senaryoyla değil, net sahipleri ve başarı ölçütleri olan iki ya da üç temel kullanım senaryosuyla başlayın.