For organizations using ClickSoftware’s (Click) Field Service Management (FSM) solution, the clock is ticking. As Click was acquired by Salesforce and assimilated into the Service Cloud, users will eventually need to find an alternative FSM solution. Depending on the Click product version – Service Optimization or Service Edge, the window of action is between one to four years (2021 – 2025 respectively). For organizations running a complex, heavy-on-resources field service, four years is not as long as it sounds.
The choice facing said organizations is a straightforward one carry out a from-scratch implementation of a new FSM solution, or “translate” the Click product into Salesforce Field Service (SFS), Salesforce’s own FSM solution.
The “translation” option is the preferable one in light of the similarities between the systems – Click’s Service Optimization (SO) or Service Edge (SE) and Salesforce Field Service, which allows for a smoother migration while retaining past investment already done in the SO\SE solution.
At Asperii, we coined the ‘Click-to-FSL’ migration as “translation” since we speak both languages fluently. Asperii was founded by ClickSoftware veterans and our razor-sharp focus in the last 10 years has been on Click Products & Field Service implementations.
After completing quite a few ‘Click-to-FSL’ migration projects, we wanted to share our way of thinking of such a project, the way we approach and execute it to achieve a smooth and successful transition of field service management and operation to a new system.
How We Think of the Migration Process
We approach a migration project as a holistic process, where all the moving parts should spin forward in unison. In order to put in motion such an action plan, we first ‘break down’ the existing Click system into individual components.
What is a component? It’s either an object, process, settings or static data.
Once we have the entire system laid out as individual components, together with the client, the system user, we work our way through understanding how each component should be migrated to Salesforce Field Service, based on 5 paths we devised that cover all the possible migration scenarios.
It might sound somewhat vague at this stage, but once we dive into the paths, it’ll all clear up and make perfect sense.
The 5 Paths of Migration
The 5 paths are specific solutions for the migration of individual components. As mentioned, we categorize each component into a specific path and map the way to migrate it. This allows us to achieve seamless parallel processes of migration, where each component gets the ideal treatment.
Path #1 – Components that can be migrated ‘As Is’
These components are fixed or static entities in the system. Since they don’t involve any process, they can be migrated directly from SO\SE to FSL. A simple, straightforward component migration.
Examples for such components are:
- Users – Dispatchers and Resources
- We may be changing the system, but the same people still need to use it and will have the same roles. We may name them differently in FSL, but conceptually they are the same.
- Some reference data (Service Optimization Dictionaries) – Skills
- The list of skills for the resources stays the same.
- Hierarchy
- The hierarchy of an organization may change every few years, but it will not change at the same time as a critical system change. Although the hierarchy scheme in FSL is created differently than in SO, the business hierarchy stays the same. The list of skills for the resources stays the same as well.
Path #2 – Find the Right Component
Components that need to be adjusted to FSL existing functionalities
These are no longer static, but rather ‘live’ components that can be updated and involve a process AND have similar functionality in FSL. So in order to migrate them, we first match them to their ‘counterparts’ in FSL, and then together with the client, decide how they should be adjusted to fit the FSL framework. The discussion needs to review the business process related to these components.
Examples for such components are:
- Service optimization object – Task
- There are different types of Tasks in SO\SE, and for them to be migrated, each requires different handling. The equivalent of Task in FSL divides to two:
- Work Order (WO)
- Work Order Line Item (WOLI)
All the Tasks in SO\SE need to be mapped into the WO/WOLI scheme, or more precisely, different Tasks need to be grouped together into WO/WOLI.
- Service Optimization object – Assignment
- Assignment can be translated into Service Appointment in FSL. However, Service Appointment can be in a scheduled or unscheduled state, where in SO Assignment always represents a scheduled state.
- Service Optimization configuration item – Generic Event: A generic event can be translated into a process, flow, or trigger on the FSL side. The decision on what to use depends on what the generic event is meant to achieve. This means the two generic events for the same object and of the same type may be translated differently on the FSL side.
Path #3 – “Make it happen”
Components that do not exist in FSL
Now we come to components that simply don’t exist in FSL. Still, these are active business processes so we must find a solution for them – either configure them or customize the platform to include them. How do we decide which to apply to every component?
The first thing we do is check the Salesforce roadmap. Since we have unique knowledge of future developments in FSL, we can leverage this knowledge to make an informed decision.
If the component in question is indeed on the Salesforce roadmap, there are two options:
- Wait for the launch, and until then find a workaround; this would usually mean a slightly longer process in FSL to complete it
- Custom develop the functionality in FSL
The decision here is taken together with the client, based on the delicate balance between the two options, and how complicated it is to carry out a workaround versus the effort needed for the custom development.
If the component in question is not on the Salesforce roadmap, there are three options:
- If it’s a must-have business process, custom develop it in FSL. An example of this would be a custom action in the ClickSchedule web client such as, right click on a task to convert it from one task type to another.
- Utilize other Salesforce capabilities to achieve the same result. An example of this would be the ClickDashboard that provides very detailed reporting. Since FSL doesn’t offer similar capabilities, Einstein Analytics can be utilized for the same purposes.
- Change the business process. This does not mean that instead of fixing charging docks, you’ll start delivering water bottles, but rather that a different process needs to be established in order to achieve the same result. In this category usually fits super complex, multi-stage tasks.
Path #4 – “Spring Cleaning”
Components that won’t make the cut
We like calling this path “Spring Cleaning”. Here we identify components or processes that will not be migrated to FSL. There can be three reasons for cutting out a process:
- An old process that is no longer in use – the business simply doesn’t work like that anymore
- A process that has a very low usage volume and can be assimilated into a similar one
- A highly customized process that’s not worth the effort of re-customizing it for FSL
A typical example of a clean-up is Task Properties. In many implementations of SO, many properties were added to the Task object for different functionalities, usually for customization. As we tend to replace customization with out of the box functionalities, many properties become redundant and are removed from future usage as part of the migration.
Path #5 – ”Evolve and Innovate”
New opportunities
Every migration process is an opportunity to take things to the next level and introduce new functionalities to improve the efficiency of your field service.
During the interaction with the client throughout the migration project, we gain such a deep understanding of their business processes and field operation that we are able to vision new ways for them to leverage the Salesforce platform in order to improve their service and by that achieve their business goals. We are so familiar with FSL, as it has been our focus for more than a decade now, that we can put the pieces together and come up with innovative ways for utilizing features and functionality of the system to improve efficiency and save costs.
An example of this can be Salesforce Chatter – as a Salesforce user, a business can use Chatter for communication and collaboration between the teammates.
Conclusion
From our experience, the 5-path way of thinking and executing a ‘Click-to-FSL’ migration leads to not only a focused and time-efficient process but also results in an optimized FSL system ready to bring the most value to the field service organization. And it is only thanks to our true understanding of both systems that we are able to create and follow through with such a precise migration process.
