Bildiğiniz ve tecrübe ettiğiniz gibi yeni projelerde SAP’nin UX çözümlerine ilişkin ciddi bir beklenti mevcut. Şanslıyız ki bu beklentileri karşılamak için hali hazırda geliştirilmiş Fiori uygulamalarını çok fazla efor sarf etmeden devreye alabiliyoruz ve bu çözümler müşterilerimizin beklentilerini karşılıyor (şimdilik).
Ancak, SAP UX çözümlerinin daha önceden karşılaştığımız problemlerden farklı dinamikler içermesi söz konusu. Hali hazırda uzmanlaştığımız konularda danışmanlık vermek için farklı bileşenlere ait uzmanlardan çok fazla destek almamıza gerek olmazken, bir UX çözümünü devreye almak ve planlamak için teknik ve fonksiyonel kadrolar olarak ciddi bir iş birliği içine girmek gerekiyor.
Bu konuları toparlamak için gerek kendi toplantılarımızdan, gerekse müşterilerimizle yaptığımız toplantılardan derlediğimiz bir soru – cevap bölümü eklemek ve bir nevi “UX in a nutshell” olabilecek yazıyı göndermeye karar verdim. Şu anda hem dünyada hem Türkiye’de nispeten palas pandıras giden bu süreç için teknik ve teorik anlamda fena bir durumda değiliz esasında. Ancak bu süreci geliştirmekle mükellef olan kurumların, danışmanlık firması olmasından mütevellit, bildiklerimizi yaygınlaştırmak herkese ulaşabilecek vakti bulmak çok mümkün olmuyor.
Dediğim gibi bu yazının amacı, SAP UX dönüşümünü merak eden, bu dönüşümden bir fırsat oluşturabileceğini düşünen herkese bir başlangıç yapabilmesi için bir giriş olsun diye hazırlandı. Vakit ayırıp okuyanlara şimdiden teşekkürler, TLDR effecte (http://www.academia.edu/3709941/TL_D...Online_Reviews) maruz kalanlar ise şimdiden kusura bakmasın
Soru: SAP UX Projesi dendiğinde ne anlamamız gerekiyor ?
Cevap:
Projeleri, SAP’nin ürünlerin temel fonksiyonalitelerini etkilemeksizin sadece presentation layerda yaptığı değişiklikler ve geliştirdiği ürünlerin devreye alınması adımlarını kapsamaktadır.
Soru: SAP UX Projesi hangi aşamaları kapsamaktadır ?Cevap: SAP UX teriminden sadece Fiori ürününü anlamamamız gerekiyor. SAP UX dönüşümü üç aşamada gerçekleştirilebilir ;
NEW: SAP’nin son dönemde gerek geliştirdiği ürünler, gerekse yaptığı satın alımlar ile bünyesine kattığı uygulamalar yeni nesil UX metodolojisine göre geliştirilmekte ve ürün hali hazırda son jenerasyon UX teknolojilerine göre dizayn edilmektedir. Bu ürünlere örnek olarak daha önce hayatımızda olmayan ve SAP tarafından geliştirilen Fraud Management, Innovation Management gibi ürünleri ve Ariba, SuccessFactors gibi satın almaları örnek gösterebiliriz.
RENEW: Hali hazırda hepimizin kullandığı ve bildiği uygulamaların, yeni bir presentation ortamında, temel fonksiyonaliteleri değiştirilmeden yeniden dizayn edilmesi süreçlerini kapsamaktadır. Bu adım SAP Fiori implementasyonunu ifade etmektedir ve satış siparişi oluşturma, izin talebi oluşturma gibi temel ERP fonksiyonalitelerinin UI5 platformuna taşınması adımlarını kapsamaktadır.
ENABLE: Kullanılan tüm uygulamaların Fiori ortamına taşınması mümkün olmayabilir. Bu durumda ilgili uygulamada basit tasarımsal değişiklikler yapmak gerekebilir. Bu adımı uygulayabilmek için Screen Personas ürünü kullanılmaktadır ve temel ERP fonksiyonalitelerinin WebGUI platformuna taşınması adımlarını kapsamaktadır. Herhangi bir teknik bilgi gerektirmez ve ortalama 2 günlük bir eğitimle herkes Screen Personas uzmanı olabilir. Ayrıca Fiori’ye göre çok daha az bir deployment eforu gerekmektedir.
Soru: Screen Personas daha kolay ve daha maliyetsizken neden Fiori ?
Cevap: Yukarıda da bahsedildiği gibi SAP Fiori UI5 teknolojisini kullanırken, Screen Personas WebGUI teknolojisini kullanmaktadır. Sadece bu farklılık bile bizi aşağıda bahsedeceğim avantajlardan mahrum bırakacaktır.
Hız
Multi platform desteği (akıllı telefon, tablet ve masaüstü bilgisayarlara uyumlu ekranlar)
Push Notification desteği
Kamera, takvim gibi temel mobil fonksiyonalitelerden faydalanma
NWBC ürünlerinin (CRM, SRM, GRC vb.) Screen Personas tarafından desteklenmemesi. (Ekim ayının sonunda Screen Personas’ın da NWBC ekranlarını destekleyeceği bir versiyonun yayımlanması beklenmekte)
Ayrıca ürün mimarileri göz önüne alındığında;
SAP Fiori sisteminin ayrı bir server üzerinde kurulması mümkün olduğu için N sistemden tek bir platforma ulaşılabilir ve tüm işlemler bu platformdan (Fiori LaunchPad) üzerinden gerçekleştirilebilir.
SAP’nin kısa ve orta vadeli UX stratejisine göre, önümüzdeki süreç bizi tamamen Fiorinin hakim olduğu ekran yapısına götürmekte
Aslında bu kadar yazıdan ziyade aşağıdaki linkte, Screen Personas mitlerinin okunması da yeterli olacaktır kesinlikle.
http://www.sap.com/bin/sapcom/sv_se/...ience-pdf.html
Soru: O zaman neden Screen Personas var ?
Cevap: Aslında bu sorunun cevabı zamanda ve maliyette yatıyor. Facebook 2011 yılında UX dönüşümü için milyonlarca dolar harcadığında proje kapsamı 32 ekrandı. SAP bu konuda biraz benzersiz bir örnek teşkil ediyor, çünkü SAP’nin UX dönüşümü tam 250.000 ekranı kapsıyor. Hali hazırdaki yazılım teknolojileri göz önüne alındığında kademeli geçişten başka bir şans yok gibi gözüküyor. Dolayısıyla, yapılan kullanım analizlerine göre en çok kullanılan uygulamalar için Fiori uygulamaları geliştirilirken kalan uygulamalar için Screen Personas gibi hem deploymentı hem de danışmanlığı kolay olan bir ürün geliştiriliyor.
Bunun yanı sıra, Fiori implementasyonu için gereken efor ve maliyet göz önüne alındığında, en azından bir kaç sene için sadece Screen Personas içeren bir UX dönüşümü de düşük bütçeli projeler için gayet mantıklı görünüyor.
Soru: Ekranların bir kısmının Fiori bir kısmı Screen Personas olması müşteri için bir demotivasyon unsuru değil mi ?
Cevap: Kısmen. Ancak bu konuda da SAP’nin Screen Personas için bir RDS (Rapid Deployment Solution) paketi var. Bu paket içerisinde tamamen Fiori ikonları ve görünümleri ile geliştirilmiş WebGUI ekranları var ve bu ekranları Fiori LaunchPad’ine ekleyebiliyoruz. Ancak UI5 nimetlerinden faydalanamıyoruz tabi ki. Bir nevi Doğan görünümlü Şahin oluyor. Ancak hali hazırda çok ciddi bir bütçe ve ekibiniz yoksa tek bir kullanıcı deneyimi yaratacak ortamı sağlamak için başka bir yol yok ne yazık ki.
Soru: Ne Zaman Fiori Ne Zaman Screen Personas kullanacağımızı nasıl belirleyeceğiz.
Cevap: SAP’ye güvenmek en mantıklı yol gibi gözüküyor bu konuda. Bu yol da tam olarak şu şekilde çizilmiş durumda;
İlgili uygulama için mevcut bir Fiori uygulaması var mı ?
Evet – İkinci soruya geçin
Hayır – Fiori uygulaması geliştirecek bütçe, kaynak ve zaman var mı ?Evet – Fiori uygulaması geliştirin
Hayır Screen Personas paketi yükleyin
Hali hazırdaki uygulama içerisinde standart dışı ekran değişiklikleri var mı
Evet – Fiori uygulamasını genişletecek bütçe, kaynak ve zaman var mı ?Evet – Fiori uygulaması geliştirin
Hayır Screen Personas paketi yükleyin
Hayır – Fiori uygulamasını yükleyin
Tabi bu küçük soru setinde bir problem daha ortaya çıkıyor. UX projemize katmak istediğimiz uygulamanın hazır bir Fiori uygulaması olup olmadığını nereden bileceğiz. Bunun için “Fiori App Library” ‘ yi kullanmak en makul yöntem gibi görünüyor. (https://fioriappslibrary.hana.ondemand.com/). Bu web sitesi sayesinde en güncel Fiori uygulama listesine erişebildiğimiz gibi, ilgili uygulamanın projeyi yaptığımız back-end product (ERP uygulamalarımızın yüklü olduğu eski sistemimiz, nam-ı diğer SAP GUI) ile ne kadar uyumlu olduğunu da ölçebilecek verilere ulaşabiliyoruz. Temel olarak dikkat etmemiz gereken unsurlar;
Back-End’de yüklü olması gereken ürünler (Required Product) : Back-end sisteminde yüklü olması gereken ürünleri listelemektedir. (Bu alan, özellikle SRM & MM, CRM & SD, Simple Finance & FI gibi isminden karıştırılabilecek uygulamaların, yeterli önkoşullara sahip olunmamasına rağmen Fiori kapsamına alınmasını önlemek için önem taşımaktadır.)
Front – End Bileşenleri (SAP UX bileşenlerinin kurulduğu yeni sistemimiz)
Back – End Bileşenleri
Gateway ve Netweaver versiyonları
Back-End sistemlerdeki EhP seviyesi.
DB Tipi: Konu Fiori iken veritabanı tipinin uygulama tiplerine göre değiştiğini belirtmekte fayda var. Fiori için 3 temel tip uygulama tipinde bahsedebiliyoruz şu anda;Transactional Uygulamalar: ERP sisteminde doğrudan veri oluşturan, veritabanını güncelleyen uygulamalar. (Satın alma talebi onayları, kalite kararı vb.) Bu uygulamalar HANA olsun ya da olmasın tüm veritabanları ile uyumludur.
Factsheet: ERP sisteminde tanımlı ana veri ve fonksiyonel veriler arasında görüntüleme işlemlerinin yapıldığı uygulama tipleri. (Satın alma siparişinden duran varlık ana verisin görüntüleme, duran varlık ana verisinden ilgili amortisman hesabının görüntülenmesi vb.) Factsheetler ne yazık ki sadece HANA DB üzerinde çalışmaktadır. Bu noktada, SAP HANA’nın bir UX projesinin neredeyse ön koşulu olduğunu belirtmekte fayda var.)
Analytical Apps, Smart Business Cockpits: Adından da anlaşılacağı üzere belirlenen analitik çözümlerin ve modellerin Fiori üzerinde izlenmesi ve görüntülenmesine yarayan uygulamalardır. SAP HANA’nın var oluş sebeplerinden biri olduğu için doğal olarak SAP HANA veritabanı bu uygulama tipleri için de zorunludur.
Soru: Tüm bu UX dönüşüm sürecinde, NWBC, Portal, SAP GUI gibi ürünler ne olacak peki. WebDynpro, ABAP artık atıl mı kalacak ?
Cevap: NWBC orta vadede (2025) azalarak ortadan kalkacak gibi duruyor. Zaten hali hazırda bir çok NWBC uygulaması çoktan Fiori ortamına taşınmış durumda. Portal için ise Fiori üzerinde geliştirilen ve aslında ilk versiyonlarından bir tanesi yayımlanan “Unified Inbox” ürünü Portal’in yerini yavaş yavaş alacak. Unified Inbox sayesinde, tüm ERP sistemlerinizi tek bir Fiori uygulamasına bağlayabilecek, bu uygulama ile tüm UI5 özelliklerinden (Mobil etkileşim, takvim, push notification vb.) faydalanabileceksiniz. Geleneksel ABAP için ise aynı karamsar öngörü söz konusu. Uzun vade de uygulama ve geliştirme danışmanlarından oluşan şirket yapıları çok daha fazla dallanıp budaklanacak ve geleneksel ABAP sadece eski sistemler için faydalı bir programlama dili olarak kalacak.
Soru: Android, iOS ya da Windows Phone için native uygulamalar geliştirmek doğru bir strateji olmaya devam edecek mi ?
Cevap: Çok net bir hayır bana kalırsa. Aslında bunu bizzat SAP UX dönüşümünün başındaki Sam Yen’den de çokça duyduk. Teknolojik trendde çok ciddi bir değişiklik olmadığı sürece, bir kaç SuccessFactors uygulaması dışında SAP’nin native uygulama yazmak gibi bir planı yok. Varsa yoksa hybrid.
Soru: Fonksiyonel danışmanlar için bir şey değişecek mi ?
Cevap: Evet. Hem de çok. Hali hazırda SAP GUI ekranları üzerinden yapılan uyarlamalar yerini Guided Configuration’a RDS ya da BP gibi paketler de yerini SAP Activate’e bırakacak. Ayrıca tasarlanacak ve geliştirilecek ekranlar yerini Fiori’ye bıraktıkça fonksiyonel danışmanlardan Fiori uygulamalarına hakim olması ve bir Fiori uygulamasını devreye almak için gerekli fonksiyonel bilgi ve birikimi ilgili kişilere aktarması beklenecek. Yazılacak olan spekt dokümanları S/4 HANA, Simple, Enterprise Management.. (ne derseniz diyin) DB yapısında olacak, Extensibility opsiyonları da fonksiyonel danışmanlar tarafından teknoloji danışmanlarına iletilecek, testler de yine Fiori sistemi üzerinde yapılacak. Dolayısıyla fonksiyonel danışmanların hali hazırda kullandıkları GUI ekranlarının Fiori versiyonlarını da aynı uzmanlıkta kullanıyor olması gerekecek. Tabi ki SAP’nin fired up ürünü olan Simple Finance sayesinde finansal uygulama danışmanları bu konuda daha şanslı görünüyor.
Ayrıca Fiori LaunchPad konfigürasyonları ve tamamen değişen rol isimleri ile yetkilendirme listelerinin hazırlanması da fonksiyonel danışmanların ellerinden öpecek gibi duruyor.
Soru: ABAP Danışmanı, BASIS Danışmanı ve Fonksiyonel Danışman olarak ayrışan kadrolar değişecek mi ?
Cevap: Her proje için bu kadrolara ihtiyaç duyulacak ancak yukarıda da bahsettiğim gibi danışmanları farklı sorumluluklar bekleyecek. Bu değişiklikler kapsamında Fiori uygulamalarının geliştirilmesi kilit bir rol oynamakta. Özellikle Fiori uygulamalarının genel bir kimliği var. Bu kimlik de şu, 1 kullanıcı, 1 işlem, 3 ekran. Ayrıca tüm ekranların aynı dili konuşması ve müşteri tarafından kabul görmesi gerekiyor ki yapılan projelerden UX anlamında bir değer elde edilebilsin. Türkiye için çok gerçekçi gibi gözükmese de gerek SAP gerek yurtdışındaki danışmanlık firmaları birer “Designer” rolü yaratmış durumda. UX projesi yapan bir kurumda ya da danışmanlık firmasında şimdilik 1 Designer / 100 Developer kuralı öneriliyor. Ekran dizaynı ve Fiori’nin kimliğine sadık kalınabilmesi için de yardımcı bir araca ihtiyacımız var tabi ki. Bu aracın adı da SAP BUILD. (Belirtmekte fayda var, BUILD ürünü henüz beta versiyonunda.) Designer dışında teknoloji tarafında iki rol daha karşımıza çıkıyor: OData Developer ve UI Developer. Sanırım bu da biraz Fiori’nin kompleks yapısından kaynaklanıyor. OData (SAP Back-End ve Front-End arasındaki iletişimi sağlamak için kullanılan protokol) ve UI Development kısmı birbirinden nitelik ve vakit anlamında ayrılması gereken iki uzmanlık haline geliyor. Bu durumda yeni ekipler olur mu bilinmez ama SAP’nin metodolojisine bakarsak (Discover >> Design >> Build) danışmanlık firmaları olarak en azından aşağıdaki gibi yeni uzmanlık alanlarımız olacak;
Designer
UI Developer
OData Developer
Veri Güvenlik Uzmanı (Trusted Connection)
Soru: UX için bir Bulut Çözümü var mı ?
Cevap: Fiori on Cloud yolda. Temel niteliği kurumların Back-End sistemleri ile buluttaki Fiori sistemi arasında güvenli bir tünel kurmak üzerine esasında. Maliyet, deployment eforu ve konfigürasyonlar açısından kazanımlar sağlaması bekleniyor.
Soru: SAP UX çözümleri ile ilgili genel bilgilere hangi platformlardan erişebilirim ?
Cevap: SAP neyseki bu konuda gerek teknik gerekse teorik dokümanlar ve materyaller bakımından sürekli bir bombardıman halinde. Belki onlarca portal ve site var ama sanırım en kullanışlı olanları aşağıdakiler:
https://experience.sap.com/
https://fioriappslibrary.hana.ondemand.com
https://open.sap.com
https://www.sapfioritrial.com