Så blev det tredje dagen på SAP Teched, og folk begynder at se lidt mere trætte ud, men til gengæld bliver underviserne mere og mere friske og veloplagte. Så det går vel meget godt sammen.
Første ting på dagen for mig, var Operational Process Intelligence (OPI), som jeg skrev en smule om først på ugen. Her fik jeg mulighed for at gå i dybden med det, og det ser faktisk rigtig godt ud. Det spændende er, at man prøver at anskue integrationsproblemtik fra en forretningstankegang i stedet for en teknisk tankegang, og det giver rigtigt god mening. Nu har jeg lavet mange integrationer gennem tiden, og lige meget om det er smart SOA, simpel fil transfer eller komplekse BPM workflows, så er det næsten altid forretningen man har brug for, for at håndtere fejl.
Måden OPI fungerer på er, at man definerer sin forretningsprocess, som skal overvåges, og dette gør man dybest set via et proces diagram med forskellige procespunkter. Man har så mulighed for, at allokere tekniske integrationspunkter til de forskellige procespunkter (indgangs- og udgangspunkter), og definere hvorledes man holder styr på separate processer (i.e. ordrenummer, cpr-nummer og lignende). Det gør det muligt ikke kun at overvåge SAP systemer, men hele forretningsprocesser, da der som sagt er tale om integrationspunkter – som altså også kan være mellem ikke-SAP og ikke-SAP systemer. Herefter er det muligt at definere KPI’er for, hvornår det er godt, ikke så godt eller dårligt – eksempelvis går det godt hvis man får en ordrebekræftelse tilbage fra sin leverandør indenfor 1 time, ikke så godt hvis der går op til 1 dag, og derefter er det dårligt – og samtidig kan man også se hvor mange beskeder, der er fejlet.
Dybest set får man så et enkelt skærmbillede, som fortæller hvor mange processer der er i gang i de forskellige trin, og hvor mange der er i hvilken status. Og det er selvfølgelig muligt at bore ned og få specifikke detaljer om de forskellige processer, som er forsinket og/ellerhar fejlet. Det giver ikke mening altid, men har man f.eks. Mange B2B integrationer, så er det faktisk rigtig interessant hurtigt at se, hvor ting fejler og hvilke leverandører reagerer langsomt. Man vil også kunne se hvilke leverandører der ofte laver fejl, har problemer med logon, leverer dårlig datakvalitet o.s.v. Mulighederne er vildt spændende – og det er tydeligt at forretningsviden bliver mere og mere vigtigt for at lave integration, og nu bliver det tydeligt.
OPI kræver SAP HANA, og det er grunden til, at Process Orchestration (PO) fra version 7.4 kan køre på SAP HANA. Således kan man tilgå data direkte i HANA og der er ikke brug for replikering af data. På sigt vil PO også opleve hastighedsforbedringer, men lige nu er det mest i forhold til monitorering, at man oplever denne forbedring. Og selvfølgelig har SAP lavet rigtigt mange standard processer, som man kan bruge direkte i OPI (og tilpasse som man vil), såfremt man kører på PO 7.4.
Dette leder mig til PO 7.31/7.4, for jeg fik deltaget på et seminar om PO’s roadmap i går, og det giver god mening at følge op med info herom. Således kører PO på en java single stack, og det blev slået fast i går, at det er SAP’s strategi at køre single stack og at ABAP stack’en ikke anbefales. Så alle der installerer nye systemer bør slet ikke overveje dual stack, og dem der har dual-stack bør overveje at gå single stack vejen fordi det er billigere hardware omkostninger, mindre kompleks landskab, mere stabilt, hurtigere og al nyudvikling kommer hertil. Så der var ingen tvivl om, at man bør komme af med sin dual-stack. Har man dog mange ccBPM på sit gamle system, så vil man fra SP9 af PO kunne køre med abstrakte interfaces også, hvilket vil lette transitionen til det nye system og så blev det anbefalet at bruge integration patterns, som nu også er en del af PO.
Generelt blev BPM delen af PO pushet meget, og det er også interessante forbedringer med muligheder for substitutioner, understøttelse af komplekse forretningsprocesser, integreret monitorering, simpel interface til såvel mobiler som almindelige browsere o.s.v. Det er bare svært at beskrive det dybere i denne blog, så vil i stedet blot sige, at nu håndterer PO komplekse workflows på tværs af systemer, med simpel og letanvendelig brugergrænseflade og performance er god – derfor bør man overveje at gå den vej i stedet for workflows i separate systemer. Samtidig – kan BPM’er direkte kopieres ind i OPI, og så kan man hurtigt definere KPI’er for sine workflows.
PO er også blevet mere åben, og der er således åbne API’er til at tilgå og opdatere alle data på tværs af platformen. Så man behøver reelt aldrig at logge på PO for at monitorere eller bruge workflows, idet man faktisk kan få det distribueret til de andre systemer man bruger – om det er Sharepoint, Sitecore, Lotus notes eller lignende – så kan PO’s API’er understøtte, så længe der understøttes SOAP. Så PO er reelt blevet en åben platform hvilket passer godt med, at den nu er en ren java applikation.
Nå – allerede ved at blive en lidt for lang blog, så må hellere stoppe for i dag. I morgen er en kort dag og sidste dag, og så regner jeg med at få plads til at beskrive Solution Manager nyhederne, Netweaver Cloud Integration og lidt om B2B mulighederne i SAP PO.
Leave a Reply