What is a DPS (Digital Product-Service System)
A DPS is a new software category designed to solve a new problem — the Data-to-Service Gap — that no existing category (IIoT Platform, FSM, BI, CRM, ERP) is designed to address. Until now, manufacturers undertaking Digital Servitization have built custom applications at considerable cost, all sharing strikingly similar features and patterns — a clear signal that a distinct software category exists.
At its core, a DPS is the central information system that enables and supports a Digital Servitization journey. It plays three core roles:
Backbone of the PSS (Product-Service System): processes data from the installed base to detect events, generate insights (KPIs, trends, benchmarks), flag anomalies, provide recommendations, and trigger automated workflows.
(if technically possible) Two-way communication layer with connected products, enabling remote delivery of commands, parameters, recipes, and firmware updates.
Information hub distributing data and capabilities to all stakeholders across the value chain, according to their roles and needs.
Typically DPS systems offer two main interfaces:
A Customer Portal — facing end customers, it delivers Digital Services and supports Connected Field Service, Smart Spare Parts, and Connected Advanced Services initiatives.
A Digital Control Room — facing the after-sales service workforce, it supports service operations and activities.
To learn more about the definition of this new software category read What is a DPS (Digital Product-Service) system?
Servitly is an off-the-shelf, configurable DPS
Servitly is an off-the-shelf, configurable DPS — the first purpose-built software for this category — with all the best practices of Digital Servitization already built in, proven across industries, and ready to deploy.
In this article you will find a practical description of the main concepts that compose the DPS system in Servitly.
Users
The DPS is designed to be accessed by all the users involved in the ecosystem of the OEM.
In the DPS, users can be associated with these business entities:
An Organization that represents a structured group of people and resources working together to achieve business goals, like selling products.
A Partner, which is a company or individual that collaborates with the main organization to deliver value, expand, or enhance the overall offer.
A Customer who is the recipient of products and services, who pays for or uses what the organization delivers.
For more details on entities and their relationships, see the article Business Entities.
User Types
According to the job-to-be-done, each DPS user has their own roles and responsibilities, so in the DPS, a user can be associated with a specific User Type (e.g. Technician, Operation Manager).
A User Type defines permissions and profiles what the user can see and do in the DPS.
User Types are associated with specific groups (Service, Customer).
Frontend
The Frontend is the presentation layer where information is displayed, and user interaction takes place.
It is composed of a set of static resources (e.g., HTML, JS, CSS, images) loaded and executed in the user’s browser or app.
The Frontend is composed of a set of predefined pages offering common functionalities (e.g., Login, User Profile Management), but according to the logged-in user, there will be other specific pages defined in Views.
For a more technical overview, you can refer to the article DPS Architecture.
Views and Pages
Instead of giving all users the same experience, the DPS provides different Views, each one offering a tailored user experience according to the job-to-be-done of the user (e.g., Service, Customer).
A View defines the pages composing the DPS for a specific User Type, and how they are interconnected to each other (e.g., navigation menus).
Metrics
A Metric defines a type of information provided by a connected product.
It models a measurable aspect of the product (e.g., temperature, pressure, or energy consumption), or a logic variable (e.g., status, error code, uptime, or counter of pieces), and establishes how individual data points are to be collected and stored.
Each data point is an instance of the metric at a specific moment in time, while the metric itself provides the semantic context that gives meaning to those values.
In the DPS, there are several types of metrics:
Raw Data metrics, which are used to store as is any data point provided by the product (e.g., Temperature).
Computed Data metrics to compute additional values on the cloud side to cover a specific lack of data (e.g., the sum of two Raw Data metrics).
Insight metrics, which are based on algorithms computed on the cloud side to provide additional valuable and actionable data (e.g., Uptime).
Insights
An insight is a specialized type of metric that is computed daily by running an algorithm on data from other metrics.
Its primary purpose is to generate synthetic indicators and actionable information.
For example, the Uptime insight calculates the percentage of daily operational time for a machine by processing values from the Standard System Status, which itself is derived from raw machine status metrics.
Insights can be based on predefined algorithms (e.g., Connection Index, Uptime) or custom algorithms.
Compared to other metrics, insight data is retained for up to 10 years because it is computed daily. For more details, refer to the data retention article.
This extended retention enables long-term comparison and aggregation (e.g., yearly), whereas raw metrics may have a shorter retention period (e.g., 6 months).
Commands and Parameters
Other than receiving data, the DPS also allows sending data to the connected products.
This is made leveraging an IoT Connector with a bidirectional communication channel, and leveraging the concept of:
Command: it represents an operation or task that must be executed on the product side and that is triggered by a simple button (e.g., Start Cleaning Procedure).
Parameter: similar to a command but with a manually provided value (e.g., Temperature set point).
Events
An event represents a noteworthy situation that has happened (e.g., [INFO] Batch operation completed) or is still happening on the connected product (e.g., [FAILURE] Power failure).
There are different types of events:
FAILURE when the machine is blocked and requires immediate intervention (e.g., Inlet blocked).
MAJOR ANOMALY when the machine is working, but action is needed to prevent it from stalling (e.g., Water shortage).
MINOR ANOMALY when the machine is working, but performance or quality may be affected (e.g., Calibration needed).
OPERATION when the machine works properly (e.g., Processing Started).
Events can be automatically created or cleared in case a specific condition occurs on a metric (e.g., temperature > 100°C), or manually to report special situations that cannot be detected by the machine due to a lack of sensors (e.g., High Vibration Detected).
When an event is cleared, it is automatically archived and remains available for browsing or computation of statistics.
An event instance (active or historical) is associated with a thing or a location.
Alerts and Notifications
The event allows you to keep track of everything important that happens, but that's not enough. You also need to notify the right people so they can intervene promptly.
Any event can be associated with an Alert that is user-profiled and visible in the DPS.
An alert can also be notified to the DPS users (e.g., via email or push notification), providing the information necessary to take action as soon as possible.
Actions
When an event occurs, an Action can be created to remind the user that a certain operation must be performed (e.g., Clean the Filter).
In addition to events, actions can be triggered based on time (e.g., every month) or usage (e.g., every 1000 working hours).
An action is associated with a specific thing and addressed to a particular group of users.