31. 12. 2022 Fabrizio Dovesi Service Management

Data-driven Models – the Ultimate Fighter against a Company’s Complexity 👊 – Use Case Part 2 of 2

Guidelines on Data-driven models for managing data complexity and designing robust systems that might be consider both a single-source-of-truth and a single-point-of-contact. Use case scenario about a real Managed Service Provider ITSM with Atlassian Cloud products

As mentioned in my previous post (Part 1 of 2), data-driven models help companies in managing data complexity and are based on several necessary ingredients: Integrations, Automation, Consistent and updated data, Processes and procedures, Monitoring and “Thinking” people.

By properly integrating and automating your ecosystem, you set the base for:

Expanding the availability of data so that the information we need to work effectively is always at hand.
Restricting data entry done by hand while improving data quality to enable higher levels of automation.
Improving the user experience for everyone involved.

With the aim of following Business needs, we know how much it’s becoming necessary to transform Service Management processes, as well. They can increasingly progress within defined and directly agreed perimeters by continuous Business requests so as to concentrate all attention on the added value rather than interpreting nominal/subjective or undue expectations (as in the case of offering a service to a customer who has not renewed their existing contract). How can we turn this possibility into reality?

To better explain that and the benefits related to data-driven models, it’s time to dive deep into a practical use case scenario, one which uses an Atlassian cloud ecosystem representing both a Single-Point-of-Contact and a Single-Source-of-Truth for customers as well as internal staff. In hopes of giving some concrete meaning to the previous sentence, let me show you how this fits with a hypothetical company, MSP S.P.A., which is a Managed Service Provider for another company, ACME S.P.A., along with many other companies.

MSP S.P.A. provides multiple services (such as SOC, ITOPS, IT Service Delivery, etc.) at different contractual levels (like standard, premium, 24×7, etc.) to hundreds of customers. Each customer might even have different service access permissions based on a particular user role (e.g. for Administrative role >> enable to BackOffice/Sales only, for IT technical role >> All, for standard users >> IT customer support only, and so on).

When a company provides an MSP service to third-party companies like MSP S.P.A. does, it has to deal with a series of aspects relating to data management and how it is used:

Contractual and regulatory
Financial
Organizational
Technical and Operational
Security
Information and Communication

All of these data are frequently managed through many disparate technologies, and in our use case scenario such complexity is kept under control thanks to integrations that make them available within Jira issues.

Each MSP role, as well as the ACME role that receives its services, must have a predefined and limited interaction with that data based on its profile. Furthermore, the staff in each MSP role must be able to communicate exclusively with the staff of other companies who are needed to carry out the assigned duties. In our use case scenario this is managed with Atlassian Access, Jira Service Management configurations, the Jira permissions schemes, the issue security levels, automation and other solutions available within the Atlassian cloud ecosystem based on multiple layers of roles and permissions.

Looking at the image below, you can see we have five different ACME customers (shown along the top) who interact with multiple MSP figures: they will get what they need (based on their current needs and contractual positions) only if the various internal groups cooperate with each other on a concrete set of data. Yet they will be still speaking to a single organization through a dedicated channel (single-point-of-contact).

If the model is driven according to the customers’ perspective, then the focus on customer expectations and rights is ensured. The main point in one sentence is: individuate the data needed by customers and make it easily accessible.

Some examples are data on services/product documentation, customer/organization data, financial and contractual data (such as contract’s validity or deadlines), assets, resources, etc. .

But the customers’ perspective is not the only one that needs to be taken into account to design a data-driven model: another secret to boost service management processes is to enable MSP operators to quickly gather customer information during their activities:

Customer recognition
Customer data
Contract validity
Delivery state
Account receivable collection state
Authorization process
Customization list

For example, when Kelly raises a request to the ITOPS team, VLAD has immediately in front of him all the information relating to the customer (Kelly) as well as the ITOPS service contract status/validity for her company.

All that data is automatically shown alongside Kelly’s request and is available to Vlad thanks to integrations with other third parties systems such as ERPs and CRMs, the automation processes that store the data within each request, and to thinking people like Kahn, Susy, and Mina who continuously keep this data consistent and updated.

In this scenario, for Kelly’s current request, she receives the expected support from Vlad through a single-point-of-contact, the Jira Service Management customer portal, which can be used for further requests in the future, even with the other MSP Team/Services (such as asking a licensing question, or a renewal question to the Back Office or Sales teams), for consulting previous requests or product/service documentation, etc. .

At the same time, once the request has been raised by Kelly, Vlad can start solving the request in a few seconds since all the information he needs to check that customer/contract is already there within that Jira issue. Once the job is completed, he can click on “log work” to track the time spent on solving the request and, which will then be invoiced to ACME S.P.A. .

Contract data, managed by Khan from the MSP Sales department, is pulled from the ERP and uploaded to the Atlassian cloud ecosystem. It’s used to understand the contracts status, with related deadlines and purchased products.

The data relating to the personal customer data and the companies to which they belong are managed by Susy and extracted from the CRM to Atlassian Cloud.

Once the process is complete, the time spent as logged by Vlad will be exported from the Atlassian cloud to the ERP systems, the same ones that had partially fed the data into the initial request. This financial data will be absolutely helpful for Mina to track activities and calculate costs to be invoiced to the ACME customer, so that she can report to the customer itself, and/or alert Khan about time-consuming contracts close to their end.

This was just one possible scenario that’s made more manageable with the model described above. As I mentioned before, since ACME has multiple active contracts with MSP, Kelly is able to use the customer portal to ask for technical support, to read product documentation, to raise a security alert, to ask for licensing renewal, and for many other services prompted by the different MSP teams. From the internal operators’ perspective, such as that of Vlad, Mina, Susy and Khan in the previous example, solving customer requests will be thousands of time easier than ever since they collaborate with each other directly within the same Atlassian cloud site.

To conclude, in order to avoid your users becoming complexity victims, it’s time to get rid of that complexity by adopting a data driven model tailored-made to your company needs. Informed by our experience, there’s no way to copy and paste a model like this from one company to another in a prescriptive way, since there are so many variables. But it is obtainable by focusing on the main points described in these two posts, and with deep knowledge of the technologies involved.

For this reason, we strongly recommend designing the solution with expert and skilled people, without any delay. Bear in mind that this is going to solve something probably already in evidence to your users and customers, like logging in to multiple systems, or keeping their eyes on different tools and manually copying/pasting data across them, getting misaligned and confusing people, but also avoiding gaps in communication and elevated risks in data consistency.

Thanks for your attention and see you in my next post!

These Solutions are Engineered by Humans

Are you passionate about performance metrics or other modern IT challenges? Do you have the experience to drive solutions like the one above? Our customers often present us with problems that need customized solutions. In fact, we’re currently hiring for roles like this as well as other roles here at Würth Phoenix.