Usecase "Maintenance Planning" (strategic/operational)

[Bernd Welter]

In this post I'd like to describe the combination of several methods in the context of a typical usecase: the scheduling process of maintenance tasks over a longer period (aka Workforce Management / WfM). You may also try to apply this approach on other branches such as sales forces.
Many users try to approach this with story with xTour only but there's a much better approach. It is based on several steps and I'll describe them one by one. But let's start with the story itself. The screenshots I use for this are based on an internal tool...

Input scenario: Imagine this...
PS: fancy video in German

Let's start with a set of georeferenced orders, each one given with (x,y) and additional properties such as service time per visit, post code and more. One specific value is the so called ACTIVITY which can be derived from different other properties. The ACTIVITY is an important value because one of the goals in the following process is to achieve an equal level of activity for each technician as a whole, period or area. Typical sources for the ACTIVITY are:

• simply the value 1: same number of customers
• service period within same period of time, e.g. amount of time you spend with an account per year
• potential revenue : ensure that each sales rep has the opportunity to get the same success
• category based : often customers are categorized into A/B/C. Just assign each category to a specific score such as (A=10,B=7, C=3)

Several thousand orderes simply clustered by their postcode area. The size of a postcode circle depends on the aggregated service period of all visits in this area. Therefore the size does not reflect the amount of visits itself but another KPI. The chart on the left shows the aggregated activity per postcode areas. Most of the areas in this example have an activity of 1. Only 10 area's activity is betweeen 5 and 10 and just 3 of them exceed 10.

Then we are responsible for a set of technicians with an individual homebase

The eight technicians are located on individual positions and in this scenario one of the targets is to assign an equal aggregated service period to each technician.

Though the original data of the orders (or customers) may contain several hundred thousand records we aggregate them to a smaller number of logical packages. This can be achieved on client side by simple SQL GroupBy statements, e.g. "SELECT POSTALCODE,SUM(ServicePeriod) as Activity FROM Customers GROUP BY POSTALCODE".

The second step in the overall process is the assignment of the POSTALCODES to the technicians. It is not necessary that each technician gets the same number of postal codes as long as the sum of the assigned postal codes aggregated service period is on an equal level. We use xCluster.planClusters for this.

The assignments of the postal code areas to the technicians. The chart shows that the workload of each technician is almost on the same level.

In the third step we focus on the technicians one by one. We use xCluster.planVisits to determine the optimal visit dates for all the visits on the stack of an individual technician. In the next image the original 100% of the visits are resolved so I applied planVisits not only to the roughly 300 postcode areas but to the several thousand indiidual customers. As a simple goodie of xCluster the service can also compute an optimal sequence of the visits within a day. (works fine for a small number of visits).

Each red line in this image shows us the sequence of visits on a specific day. In this example I've chosen a horizon of twelve weeks but this also works fine with longer scopes such as 3 months, 6months or even a whole year.

This story is quite generic so far. But we can do more:

• In my example all customers have been visited once in the planning cycle but the API enables you to specify visit rhythms, i.e. you can set different categories such as "prio A customers: every week" and "prio B customers: every 2 weeks" and "prio C customer: every 4 weeks".
• Furthermore it is possible to define indicidual activities per technician. This allows you to scale between the technicians (e.g. "technician works only 50% FTE" or "a technician office has more than one technician to server orders from").
• Another interesting feature is the consideration of regularities: if a customer is supposed to be visited several times within the cycle you can ensure that each visit is placed on the same day of the week though you don't know the day itself in advance.

Furthermore it is important to understand that the first steps in this concept are based on the regular orders than can be scheduled in advance. In real life there will also be some incidents which have to be put into the story on a short term. So in many cases a technician deals with

• 80% regular maintenance tasks or even more
• 20% incidents (or even less)

These incidents are then scheduled on top of the strategic maintenance tasks.

So much for now - I hope this inspires you to takt a closer look at xCluster. It is a might interface that is valuable especially if you work with a larger number of regular visits.

By the way: instead of postcode areas you can use other adminstrative base regions such as districts or federal states. We also know communities that apply this procedure on their periodical tasks such as garbage collection. In this case the number of core objects easily exceeds 50'ooo or even 100'ooo (garbage bins) and the aggregation is based on street names or street sections. Furthermore the activity is derived from the known volume of bins (e.g. 800l/1200l) and the picking rhythm (daily, weekly, biweekly).

In case of questions do not hesitate to get back to me and I'll answer as smart as possible.

Best regards,
Bernd