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:
- have a good understanding of the business- and user requirements based on business objectives, the service sales and delivery processes and the types of services provided.
- have an understanding of the existing IT architecture, IT strategy and roadmap to have clear understanding of how a new software product fits into the existing application landscape (for example CRM, ERP, SCM, EAM, HR) and adheres to the IT strategy and the (IT) constraints that need to be taken into account.
- have a good understanding of the standard functionality that each of the applications in a service management solution will provide in order to identify the functional gaps that remain, and what it takes to adapt the solution according to your way of working.
- select the right service management software product that fulfills the business- and user requirements and can be used to design an end-to-end service management solution.
- design an integrated end-to-end IT service management solution that uses the existing applications and any new acquired software products.
- implement the service management solution successfully in order to avoid a poor implementation that can significantly impact revenue, support costs and most importantly the ability to achieve the key business objectives.
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, which is a collection of functional features that the service solution must be able to support
- The different roles that users of the solution have.
- The user stories that define how a user with a certain role will use the functional features as part of their work as defined by Noventum’s best practice operating model. User stories are used to define and prioritize the exact solution scope, contain detailed user requirements and user acceptance criteria.
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 Application Architecture which defines the applications and software components to be used.
- The Functional Overview that shows which application in the Application Architecture will provide which functionality. For certain functionalities, several alternatives are provided where needed
- The Application Integration Design which defines the software components and integrations that will be used to realise the interfaces.
The Data Blueprint specifies the data structures used in the service solution and how the data is used. It contains:
- A Service Data Model that defines the meaning, data structures, the semantics and relationships between data objects as used by service in an application agnostic manner.
- An Application Data Model that defines the data structures provided by each of the applications and mapped with the Common Service Data Model.
- The Service Master Data Model that defines the master data objects and for each - who uses the master data, for what, and which application is the master.
- A Service Integration Model that defines the data flows and interfaces between the different products included in the Application Blueprint.
The Technical Blueprint defines the technical components of the service solution. It contains:
- The Technical Architecture Overview which shows the technical components and infrastructure, and how the application and software components use this.
- The (type of) software licenses needed for implementation
- The Non-Functional Requirements Overview which describes the key non-functional requirements that typically apply for service organisations and how these are addressed.
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:
- Significantly accelerate the design, build, integration and testing of a Service Management solution, and shorten the time to market, reduce opportunity costs and reduce implementation cost
- Utilize best practices and leverages both business and IT knowledge and experience, from both Noventum and software vendors
- Avoiding “reinventing the wheel” and significantly simplify what has traditionally been a potentially challenging and lengthy scoping, selection and design process.
- Completeness, ensures that all functionality is considered for inclusion
- Higher level of success of implementing a Service Solution because Service Solution Blueprints are based on proven success and best practices