Voor meer achtergrond over SAP Operational Process Intelligence, zie ook de februari 2014 editie van Tips & Tricks.

Transcriptie

1 Titel Realtime proces monitoring met SAP HANA Operational Process Intelligence Introductie Meestal worden bij het realtime monitoren van processen en cases maatwerkschermen gebouwd. Dit omdat elke procestype natuurlijk andere velden heeft, zo ziet Sales procesmonitoring er anders 1 uit dan die van Maintenance. SAP Operational Process Intelligence biedt echter standaard (monitoring) schermen, waar met simpele data modellering verschillende procestypes (scenario s) gemonitord kunnen worden. In het volgende artikel zet Wout de Jong uiteen wat er kan en hoe dit in te richten aan de hand van een eenvoudig voorbeeldscenario de klant een internetaansluiting verschaffen. Met simpele data modellering heb je dan al snel zo n overzichtsdashboard. Er hoeft geen enkel maatwerkscherm gebouwd te worden. Het begin Het begint met het identificeren van de te monitoren case, zeg maar het business object, dat een bepaalde tijdscyclus doorloopt. Zoals een incident of een order of iets dergelijks. In het voorbeeld betreft het de klantaanvraag voor een internetaansluiting. Doel is om individuele cases door het proces te trekken binnen een bepaalde tijd. Deze tijd is in te delen in een aantal fasen. Zo is het voorbeeldscenario ingedeeld in 3-en, namelijk de Requesting Connection, Planning and Installing en Finalizing Administratives phases. Binnen fasen is er nog de mogelijkheid om mijlpalen te definieren. Niets houd je tegen om een mijlpaal meerdere keren te bereiken of zelfs over te slaan. Deze flexibiliteit is bijzonder nuttig, omdat processen op detailniveau zelden immer-gerade-aus lopen. In onderstaand screenshot is in deze specifieke klantaanvraag de mijpaal Location entered twee keer 1 Voor meer achtergrond over SAP Operational Process Intelligence, zie ook de februari 2014 editie van Tips & Tricks.

2 gepasseerd (binnen 11 seconden). // we orchestrate Het bereiken van een mijlpaal (inclusief de overgang naar een andere fase) vindt plaats door middel van een Event, dat is ontstaan in een SAP of non-sap backend systeem, of door een directe gebruiker-interactie. In het voorbeeld zijn de mijlpalen van de Requesting Connection fase allemaal gekoppeld aan interacties in een aansluiting-aanvraag webapplicatie, en worden de mijlpalen in de Planning and Installing fase getriggerd door Events (eigenlijk status updates) uit het planning systeem. In de Finalizing Administratives fase wordt direct door de gebruiker via het afvinken van een checklist een mijlpaal bereikt, zie het screenshot hieronder. Dit is nuttige functionaliteit om handmatige procesacties op te vangen. Het kan ook dienen als placeholder voor toekomstige backend-events, die in een eerste release nog niet ontsloten konden worden.

3 De context van de zaak Bijna altijd is er meer context rondom de zaak nodig. In het geval van de klantaanvraag voor een internetaansluiting zijn dat velden (attributen) zoals type product, de locatie van de aansluiting, en wanneer de klant de monteur wil ontvangen. Deze contextgegevens kunnen per scenario worden gedefinieerd en zullen per zaak (in dit geval: aanvraag) verschillende waarden bevatten. Deze contextgegevens kunnen uit andere systemen komen, maar ook worden afgeleid uit gegevens vanuit het HANA systeem zelf. Het is zelfs mogelijk om handmatig extra gegevens toe te voegen aan een individuele zaak. Bij het monitoren van al die duizenden klantaanvragen kan dan automatisch op deze attributen worden gefilterd en gezocht (text search). Ook kunnen hieraan autorisaties worden gekoppeld, bijvoorbeeld, een groep gebruikers mag alleen de aanvragen met Product Fiber-optic cable connection monitoren. Vanuit de context kun je ook navigeren (deeplink) naar een andere applicatie zoals een SAP Fiori Fact Sheet, of in dit geval via de link van het Status-attribuut naar (toch!) een maatwerkscherm. De maten en indicatoren Met de fases en mijlpalen, plus de context attributen heb je alle ingredienten om operationele proces dashboards en rapportages te modelleren. Standaard krijg je al de Fiori-stijl tegels met openstaande zaken (inclusief onderverdeling naar fase), plus de cycle time en completed tegels. Vaak is er behoefte aan nog specifiekere monitoring, bijvoorbeeld over gemiddelde doorlooptijd tussen 2 mijlpalen. Hieronder is de gemiddelde doorlooptijd tussen de inplanning van de monteur en de daadwerkelijk werkende internetconnectie bij de klant geconfigureerd als Average duration planned _ connected. Er zijn 2 tegels gedefinieerd, de ene met een vaste target van 11 dagen (oranje want nu 10,22 dagen), en de andere met een target met dynamische formule (dezelfde waarde 10,22, maar nu rood want target is 8,31 dus overschreden).

4 Een interessante vraag in het kader van de doorlooptijd van een klantaanvraag is wat de invloed is van mislukte afspraken tussen monteur en klant, want ook al is er sprake van een afspraak, het komt voor dat het toch misgaat en dat de monteur customer absent terug meldt. Dit is in SAP OPInt eenvoudig te modelleren door het aantal customer absent events per klantaanvraag te tellen, en deze in de context bij te houden. Als je doorklikt op de Average duration tegel en het attribuut Number of times Customer Absent selecteert, dan krijg je onderstaande grafiek waarbij op de x-as per dag een 1 of een 0 staat wat het aantal keren customer absent representeert. Het wordt duidelijk dat in kalenderweek 44 van 2015 het ruwweg 2 dagen extra tijd heeft gekost om een klant aan het internet te connecteren wanneer er 1 mislukte afspraak tussen monteur en klant heeft plaatsgevonden. Mochten er nog andere indicatoren benodigd zijn dan biedt OPInt daartoe ook nog ruimte aangezien OPInt gebruik maakt van de standaard calculationview-functionaliteit van HANA. Te denken valt aan de totale opbrengsten of kosten van alle openstaande klantaanvragen of de beschikbare capaciteit van de pool van monteurs.

5 Conclusie // we orchestrate SAP HANA Operational Process Intelligence biedt een standaard oplossing voor operationele proces monitoring door slim te data-modelleren zonder dat er proces-specifieke maatwerkschermen of rapportages gebouwd hoeven te worden. Over de auteur Wout de Jong is Solution Architect bij Creetion en werkt bij diverse klanten aan verbeteringen van ketenprocessen vanuit de invalshoek van de Case ("Zaak"). Zijn expertise (en interesse) bestaat voornamelijk uit software architectuur (met name SAP), systeemintegratie, BPM / Process Management, Case Management, Rules Management, en Software Lifecycle Management en alle onderwerpen die hiermee samenhangen.