When companies choose a product based on their limited understanding of the requirements and the products’ capabilities, they typically, over time, learn more about what the service business requirements really are - only to discover they have made the wrong choice. They then enter a never-ending cycle of customization projects that run out of control.
The field service management software market has shifted significantly over the last few years where CoreSystems, ClickSoftware and Astea have been acquired by resp. SAP, Salesforce and IFS.
The number of independent field service management software vendors has been strongly reduced and today, most products cover all basic service functionality. Still, there are several (field) service management software products on the market, each with their own strengths and weaknesses. Key differentiators are in the breadth, depth and maturity of functionality they provide and how digital (data-driven) service business models can be supported.
Which product best suits your specific situation depends on many business-related aspects, such as the characteristics of your service business, the types of services and business models that need to be provided, the service processes in scope, how the service sales and delivery is organized and the desired customer experience.
However, almost as important are the non-functional aspects such as flexibility, scalability, security and integration capabilities. A product must be flexible enough to allow the product to be configured to match your way of working rather than having to adopt your processes to match the products’ capabilities.
Companies wanting to digitally transform their service business need to ensure that they:
Noventum’s Service Solution Blueprints help to accelerate the digital transformation of service by providing templates for solution architectures and design for specific but proven combinations of software products that together form a Service Management solution and enables a service organisation to deliver a specific set of business capabilities to sell and deliver services.
Noventum has developed multiple SSB’s that each describe a possible combination of software products and how these are used in an integrated manner.
The number of Field Service Management products that can be considered can be reduced to one or two by selecting the Service Solution Blueprint(s) that best matches the current IT architecture and strategy, type of service organisation, type of services provided, key non-functional requirements, IT constraints and specific functional requirements.
A Service Solution Blueprint consists of blueprints for four different viewpoints; functionality, data, application structure and technology.
The Functional Blueprint defines the functionality that needs to be provided by the solution.
This is the functionality required by the service business based on the type of services provided (see Noventum’s Service Evolution Model), the sales and delivery processes and organisational design.
The functional blueprint is based on Noventum’s best practice service operating models that include processes, management practice, performance metrics and organisational design.
The Functional Blueprint defines:
The functional scope defines which functionality will need to be implemented. The Functional Reference Architecture for Service contains a complete set of functional features that a service organization needs, based on Noventum’s best practice processes, management practices and performance metrics for service.
The features are grouped into functional domains, such as Service Request Management, Technical Documentation and Service Contract Management. Within each domain, a sub-domain further details the functionality for a specific area. For each sub-domain several functional features are defined.
The Application Blueprint defines the applications and software components that are used to provide the required functionality and how they’ll work together in order to ensure end-to-end integrated support. It contains:
The Data Blueprint specifies the data structures used in the service solution and how the data is used. It contains:
The Technical Blueprint defines the technical components of the service solution. It contains:
How to use the Service Solution Blueprints?
Service organisations wanting to implement a new service solution can use the Service Solution Blueprint as a starting point to rapidly define the scope, determine the requirements, select a pre-defined solution architecture and select the most suitable Field Service Management product.
Key benefits of using the Service Solution Blueprint include: