In het vorige artikel in deze reeks hebben we het gehad over de routebeschrijving naar Maintenance-Centric Service. Hierin is het mogelijk om de S/4 HANA Service module te integreren met SAP Plant Maintenance (PM). Vanuit S/4 HANA Service kan daarbij de uitvoering worden gestuurd via SAP Field Service Management (FSM).

In dit blog zullen we verder ingaan op één van de uitgebreidere functies van het planbord van FSM: automatische planning. Je denkt waarschijnlijk: dat is toch één van de basisfuncties van SAP FSM? Hier hebben jullie toch al meer over geschreven? Dat klopt! Echter zien we ook dat SAP hierop hard door ontwikkelt en stappen maakt. Niet alleen in de algoritmes, maar ook in de presentatie richting de klant. We zullen daarom eerst kort de principes van automatische planning herhalen. Daarna leggen we uit hoe een planningsalgoritme kan worden bekeken in de policy designer en hoe het ontwikkelen van een klant specifiek algoritme (policy) in zijn werk gaat.

Verschillende soorten van plannen in SAP FSM

Binnen SAP FSM worden drie soorten van plannen onderscheiden: manueel, semi-automatisch en automatisch. In SAP FSM kan – zoals in vrijwel elk planbord – met de hand gepland worden. Dit kan middels drag-and-drop (of in de minder nette Nederlandse versie: sleur-en-pleur). We zien in de praktijk dat dit meestal wordt gebruikt bij uitzonderingen of wanneer een regel moet worden overtreden. Denk in dat laatste geval bijvoorbeeld aan het plannen van een activiteit buiten werktijd bij een grote storing.

Bij semi-automatische planning krijgt de planner verschillende voorstellen op basis van wat mogelijk zou zijn. Hierna kiest de planner in welk tijdslot hij een activiteit wilt plannen. Voorbeelden van functionaliteiten die gebruik maken van semi-automatische planning zijn het vinden van geschikte technici en de wachtrij. Semi-automatisch plannen wordt meestal gebruikt wanneer je er zeker van wilt zijn waar iets in de planning staat, bijvoorbeeld wanneer je een klant aan de lijn hebt en een afspraak inplant.

Tenslotte is er volledig automatische planning, de focus van dit artikel. Hierin wordt volledig automatisch en in de achtergrond een planning gemaakt. Deze conceptplanning wordt vervolgens naar de monteurs gestuurd, tenzij de planner nog handmatige of semi-automatische aanpassingen doet. Het starten van de automatische planning kan ook worden gestart op basis van een event, zoals bijvoorbeeld een activiteit die (veel) langer duurt dan gepland. Zie een overzicht van de verschillende soorten planning in de figuur hieronder:

Verschillende soorten planning

 

Maar hoe bepaalt de (semi-) automatische planning waar een activiteit gepland mag worden? En net zo belangrijk: waar niet? Dit gebeurt op basis van een policy. Een policy bestaat uit regels en doelen.

  • Regels komen overeen met een regel binnen een bedrijf. Deze mogen niet overtreden worden en kunnen altijd beantwoord worden met ja of nee. Een voorbeeld van een regel is dat een monteur over de juiste vaardigheden moet beschikken om een activiteit uit te voeren. Heeft de monteur de vaardigheden die nodig zijn om deze activiteit uit te voeren? Ja, dan mag hij gepland worden. Nee, dan valt deze optie af. Door middel van de regels vallen veruit de meeste planopties af.
  • Doelen komen overeen met bedrijfsdoelstelling Een doel wordt pas relevant als aan de regels is voldaan. Een doel bepaalt of een activiteit bij 1 van 2 geschikte monteurs in de planning terecht komt. Om te kunnen bepalen bij welke monteur dit is, worden doelen geprioriteerd. Sommige doelen zijn belangrijker dan andere. Dit impliceert ook dat een doel ten koste kan gaan van een ander doel. Voorbeelden van doelen zijn het hebben van zo min mogelijk reistijd en het plannen op prioriteit. Als een activiteit een hogere prioriteit heeft dan een andere, kan deze gepland moeten worden, ondanks dat dit extra reistijd met zich meebrengt.

SAP levert een aantal standaard policy’s, maar biedt ook de mogelijkheid om samen met Ideo en een SAP Product Team een eigen policy te ontwikkelen. Beide policy’s kunnen worden bekeken in de policy designer.

Policy’s en de policy designer

Vanaf de 2202 release van SAP FSM is de policy designer beschikbaar. Deze kan worden benaderd vanuit de Planning & Dispatching module van SAP FSM. In de policy designer kunnen de verschillende regels en doelen in een bestaande policy worden bekeken en vanaf de 2205 release zelfs al worden gekopieerd en aangepast. Zie het voorbeeld hieronder voor de regels en doelen van de standaard policy “DistanceAndSkills”:

Standaard policy DistanceAndSkills in SAP FSM

Momenteel kunnen policy’s hier dus al worden bekeken, gekopieerd en aangepast. Op de roadmap van SAP staan items om in de toekomst een nieuwe policy via de policy designer aan te maken en zelfs eigen regels en doelen te schrijven.

Standaard biedt SAP de volgende policy’s aan:

  • Vaardigheden: een monteur wordt enkel gepland wanneer hij de juiste vereiste vaardigheden heeft (regel). Daarnaast wordt als doel gekeken naar optionele vaardigheden. Beschikt een monteur over alle optionele vaardigheden, dan is de kans groter dat de activiteit bij hem wordt gepland.
  • Afstand: de activiteit wordt bij voorkeur gepland op de monteur die hiervoor de minste reistijd heeft (doel).
  • Afstand en vaardigheden: een combinatie van de twee bovenstaande policy’s. De monteur met de juiste vaardigheden en de minste reistijd wordt ingepland.
  • Snelst: de activiteit wordt bij voorkeur gepland op de monteur die er het snelst kan zijn (doel). Dit gebeurt op basis van het minst aantal minuten tussen de starttijd van de activiteit en de tijd dat de monteur op de locatie van de activiteit kan zijn.

Het is momenteel ook al mogelijk om als bedrijf een klant specifieke, custom policy te ontwikkelen. Dit gaat in samenwerking met consultants van Ideo en een Product Team van SAP.

Een klant specifieke, custom policy

Zoals hierboven besproken is het mogelijk om samen met consultants van Ideo en SAP een custom policy te ontwikkelen. Hierin kunnen regels en doelen worden opgesteld die afwijken van de regels en doelen in de standaard policy’s. Voorbeelden zijn het plannen op prioriteit of rondom een bepaald gebied om de dekking voor eventuele storingen te waarborgen.

Hoe ziet het proces van het ontwikkelen van een custom policy eruit? Onze mensen stellen samen met jou als klant de requirements op. Vervolgens sturen we deze naar SAP. Zij zullen ons uitdagen op de inhoud en business voorbeelden geven op basis van hun ervaring. Vervolgens wordt de policy ontwikkeld door SAP en geïmplementeerd op het klantsysteem. De overige voorwaarden worden door Ideo samen met de klant in orde gebracht waarna getest kan worden. Dit proces herhaalt zich totdat de gewenste testresultaten bereikt zijn. Uiteindelijk wordt de policy geïmplementeerd op de productie omgeving en in gebruik genomen. Het proces tussen klant-Ideo-SAP ziet er als volgt uit:

Proces tussen klant-Ideo-SAP

Meer weten?

In dit artikel is veel besproken. Het is dan ook niet gek als niet alles direct landt. Benieuwd naar meer informatie rondom automatisch plannen binnen jouw organisatie, de policy designer of een custom policy? Neem gerust contact op met onze mensen, zij helpen je graag verder!