RSMUS.comThe purpose of this blog is to explain the concepts of Microsoft Dynamics 365 Field Service Scheduling and to provide a roadmap, and tricks, to get you from manual scheduling to fully automated scheduling, utilizing RSO (resource scheduling optimization).
Microsoft docs provides an article on the 5 stages of scheduling adoption. The article does a good job of explaining how a company can move through a maturity model going from manual scheduling to fully automated scheduling.
Benefits to a field service organization include:
- Turning tribal knowledge held by dispatchers into institutional knowledge
- Info is baked into your field service system and field service data, reducing the risk of losing specific employees and the ability to easily have other folks take over the dispatching role
- Reducing the number of service admins required to support the business
- Represents real savings to the current business
- Allows a company to grow without a need to increase administrative headcount
- Utilizing routing and machine learning to more effectively and efficiently route technicians
- Efficient routing is a complex endeavor that can involve trillions of computations
- Dispatchers can be overwhelmed and are not able to take into account all factors
- Manual routing results in a technician getting routed hours away one day only to send them to practically the same location the next day
Dispatching is a fairly easy concept at its core
- Identify what resources are needed to service a work order. This can include a person, tools, equipment, transportation, and parts. You don’t just need any person, you need a person with specific skills, training and/or certifications to effectively service the work order (work order requirements)
- Identify the people that have a particular skill and that are in a specific territory
- Dispatching, then, is the process to identify what is needed for the work order and then to match it to who is best served to work on the work order
Although dispatching is easy conceptually, there are many complexities with dispatching that are beyond the scope of this article including multi-resource, real-time location tracking, efficient routing, etc. For the remainder of the article, I’m going to focus on only the skills (or characteristics) that are required to service a work order.
Characteristics of a work order
Microsoft Dynamics 365 for Field Service provides characteristics to track the skills required for a work order and the ability to track skills that are held by technicians. The out of the box way to easily add characteristics to a work order is to set up Incident Types, which are work order templates that copy down requirements to a work order when the incident type is selected on a work order. As an example, an incident type called “MRI 6 month maintenance” could have characteristics on it that would require the appropriate skills for performing an MRI maintenance and this, then, would require a specific level of skill or even a certification if the technician needs to certify the work performed.
However, what if the requirement to perform the work order is something like a specific badge that is required for a job site or a skill that is needed for a specific type of equipment? Although you could set up a bunch of different incident types for each job location, this is not a good concept architecturally because you’re replicating the entity structure you already have for service accounts. For the other requirement, a skill on a specific type of machine, you could set up many incident types for the different types of machines you work on, but again, you would be replicating entities that already exist in the form of customer assets and the products that those customer assets are related to.
RSM implements characteristics
For these types of requirements (e.g. badging and product-specific skills needed), RSM has extended characteristics to service accounts and customer assets/products. Conceptually, this is illustrated below incorporating the out of the box features of resource characteristics, incident types, and the schedule board matchmaking process. The idea is that you’re already adding a service account to a work order and a badging requirement belongs to the service location, as opposed to an incident type. By attaching badging characteristics to a service account, you can have those flow onto the work order as soon as the service account is assigned to the work order. Similarly, if you have skills that are required for a specific type of machine, then you can have the characteristics flow to the work order from the customer asset (and the product the customer asset is assigned to) whenever you assign a customer asset to a work order. This avoids someone from having to manually add characteristics to a work order and allows them to be assigned to and flow from the entities to which they are naturally associated.
So, whether you’re doing assisted routing utilizing the schedule board (Stage 2 of the 5 stages of scheduling adoption) or fully automated routing utilizing Resource Scheduling Optimization (Stage 5 of the 5 stages of scheduling adoption), it’s important that your resource data is up to date and that characteristics get added to work orders in an automated fashion. This article explained conceptually how you can extend the out of the box functionality around characteristics and work order requirements to assist with getting your organization to recognize the benefits of getting beyond manual routing and even assisted routing for scheduling and dispatching your field service workforce.
