04
Haz

SAP; Bir aşk ve nefret öyküsü…

Gürcan Yücel – Yazılım Direktörü

SAP ürün ailesi konusunda bir uzman değilim. SAP ile yolum projelerimiz gereği birçok müşteri ve müşteri adayı görüşmesinde kesişti. Bir ERP uygulamasının ilk uyarlama safhalarını da yakından takip etme fırsatı bulan birisi olarak zaman içinde çeşitli tespitler yaptım.

Tüm dünyada ve ülkemizde yaygın olarak kullanılan SAP platformunun marka bilinirliliği çok yüksek. Firmalar bu platforma sahip olmak için koca koca bütçeler planlıyor, ekipler oluşturuyor, yatırımlar yapıyor. Yönetim kadrosu desteğini arkasına alan SAP projelerinin tamamı bir “aşk hikayesi” olarak başlıyor. 

Uyarlaması yapılan modül ile ilgili uzman danışman bulmak çok zor. İşin doğası gereği, böyle bir danışmanı yetiştirmek daha da zor. Hem platformu ve modülü çok detaylı bilecek, hem de müşteri ihtiyaçları ile modül yeteneklerini örtüştürebilecek, hem de son kullanıcı ilişkisini yönetebilecek. Bazı projelerde anahtar kullanıcılar da yapıya dahil ediliyor. Bu kullanıcıların bir kısmının da örnekleme tecrübesi yetersiz kalıyor. Projeler esnasında doğru bir kullanıcı profillendirmesi de yapılamadığı için işler iyice karışmaya başlıyor.

Aslında önemli konulardan biri de projelerin neden yapıldığının zaman içinde unutulması. Tam anlamıyla projeler gerekli resmi ve resmi olmayan raporlara ulaşmak amacıyla yapılmalı. Bunun için de paydaşlar proje başlangıcında somut rakamlar ile ölçüm kriterlerini çok iyi belirlemeli ve tüm proje boyunca uygulamalılar.

Bunun içine “tüm kullanıcıları memnun etmenin zor olması”, “mobil kullanımının neredeyse olmaması”, “zaman içinde kullanıcı ihtiyaçlarının değişmesi” de dahil olunca maalesef başarılı bir proje yapmak gittikçe zorlaşıyor. Hele hele anahtar kullanıcıların zaman içinde iş değiştirmeleri sonucunda kurumlar ellerinde bir sürü neden olduğu belli olmayan ekran/özellik/entegrasyon ile baş başa kalabiliyor. Bu noktada aşk hikayesi, nefret hikayesine dönüşüveriyor.

Biraz araştırma yaptım fakat SAP özelinde başarılı proje oranlarını bulamadım. Proje yönetimi açısından bakıldığında dünya üzerindeki projelerin %40’ı henüz üretim ortamına geçmeden sona eriyor. Geri kalanların %30’luk dilim ise proje esnasında geri dönülmez sorunlar yaşıyor. Başarılı görünen %52’lik dilimin %25’i ise son kullanıcının önüne çıktığında “Bu ne şimdi?” tepkisi ile karşılaşıyor. Tüm projelerin %55’lik dilimi ise bütçe aşımına uğruyor. Türkiye’de SAP Uyarlama projelerinin bir tık daha başarılı olduğunu tahmin ediyorum.

Peki, nasıl olmalı da bir SAP projesini oldurmalı? Platform son derece esnek, deyim yerindeyse bu işin Porsche 911’i. Nasıl oluyor da oluyor? Eğer otobanlarınız çukur doluysa Porsche, maalesef hızlanamıyor. 

İşte bu noktada süreç platformları devreye giriyor. Platform adayı her açıdan SAP ile konuşabilmeli, yapılacak geliştirmeler mümkün ise kod yazılmadan yapılabilmeli, süreçler izlenebilmeli, ölçülebilmeli ve raporlanabilmeli. Kısacası PaperWork olmalıdır. 🙂

PaperWork, SAP konnektör mimarisine sahiptir. Yani süreçlerde hiçbir kod yazmadan SAP üzerindeki iş nesnelerini (BAPI) çağırabilir, parametre gönderebilir, iş nesnesi çalışması sonucunda oluşan veriyi alarak iş akışını devam ettirebilir.

 

 

Yukarıdaki örnek ekranda olduğu gibi SAP konnektörü iş akışında bir aktivite olarak yer alır. Bu aktivite akışın gerekli bölümüne sürükle-bırak ile yerleştirildikten sonra SAP tarafında çalıştırılacak iş nesnesi listeden seçilir. Bu listede SAP tarafında uyarlama esnasında ek yapılmış olan tüm iş nesneleri bulunur. Seçim ile beraber iş nesnesinin giriş ve çıkış değerleri listeye gelir. Listeden iş akışı alanlarından hangilerinin hangi giriş/çıkış parametresi ile eşleşeceği seçilir. Hepsi bu kadar!!!

Seçim ile beraber otomatik olarak aktivitenin gelişmiş bölümünde C# kodu oluşur. Eğer gelen/giden veriler üzerinde değişiklik yapılmak isteniyor ise, bazı veri tipleri dönüştürülmek isteniyor ise bu bölümdeki kodlar üzerinde değişiklik yapılabilir.

Benzer bir C# kodu ile iş akışı elektronik formları listelerini SAP iş nesnelerinden doldurabilir. Veya SAP’ den alınan bir liste kullanıcının önüne çıkarılarak seçim yapması sağlanabilir. Kısacası her türlü SAP verisi kolay bir şekilde tüm PaperWork mimarisinden alınıp verilebilir.

SAP mimarisine bu kadar kolay bağlandıktan sonra artık PaperWork özellikleri devreye girmeye başlar;

. Süreçler dinamiktir. İhtiyaçların değişimi durumunda süreç üzerinde veya elektronik formlarda değişiklik yapmak son derece kolaydır.

. Süreçler izlenebilir. Hangi sürecin hangi aşamada olduğu takip edilebilir.

. Süreçler ölçülebilir. PaperWork süreçlerinde KPI nesnesi kullanılabilir. Buna göre bir iş adımının veya birden fazla iş adımının ne kadar sürede tamamlandığı ölçülebilir. Yapılan ölçümler raporlanabilir.

. Süreçlerde süre takibi yapılabilir. Yani süreçlerin belirli adımları için veya sürecin tamamı için SLA süreleri belirlenip işin bu süreler içinde yapılıp yapılmadığı takip edilebilir. Yapılan işlemler raporlanabilir.

. Süreç verileri raporlanabilir. PaperWork bir rapor tasarım ara yüzüne sahiptir. Süreçlerde oluşan, SAP’ ye giden veya gelen tüm veriler de kullanılarak dinamik raporlar hazırlanabilir.

. Süreçlerin veya bazı görevlerin çeşitli periyotlarda otomatik tetiklenmesi sağlanabilir. PaperWork tanımlı iş mimarisine sahiptir, tanımlanan iş tanımına göre otomatik olarak bir C# metodunu çalıştırabilir.

. Süreçler çeşitli ortamlardan yönetilebilir. PaperWork son derece zengin ara yüz çeşitliliğine sahiptir. Web üzerinde çalışan ara yüzler mevcuttur. IOS ve Android üzerinde çalışan native uygulamalar aracılığı ile kullanıcılar akışlarını yönetebilirler. Ayrıca MS Outlook içine yerleşen ve kullanıcıların iş akışlarını yönetmesini sağlayan ayrı bir uzantı da mevcuttur.

Bu ara yüzlere ek olarak henüz bitmemiş, bu doküman ile ilk defa duyurulan SAP BPM ara yüzleri mevcuttur. Hazırlanan ürün sayesinde SAP ara yüzlerinden ayrılmadan kullanıcı tüm iş akışlarını yönetebilecektir. Aşağıda bu ara yüze örnek bir ekran bulunmaktadır.


Aşk ile başlayan projelerinizin nefrete dönüşmemesi dileğiyle…