• Skip to main content
  • Skip to primary sidebar

This view of service management...

On the origin and the descent of managing services. We put meat on the bones.

  • Kanban eLearning
  • Services
    • Kanban Software Solutions
    • Consulting & Coaching
    • Training and Seminars
  • Posts
  • Events
    • Events – Agenda View
    • Events – Calendar View
    • International Service Management Calendar
  • Publications
    • Our Publications
    • Notable Publications
    • Quotes
  • About us

AI Data Strategy for Service Management

3 June 2019 by Robert Falkowitz Leave a Comment

Is the data you record about managing services merely a by-product of other activities, just some administrative overhead? Do you want to benefit from artificial intel­li­gence tools to improve your services? If so, you should consider establishing an AI data strategy in your organization.

The quality and the quantity of available data underpin the benefits of artificial in­tel­li­gence. However, service pro­vi­ders often view the data concerning service delivery and service management only from an operational or even a tactical perspective. They view data as a by-product of service delivery and service management.

A strategic per­spec­tive on service management data specifically targets the breadth and quality of its production. Successful use of artificial intelligence to support these delivery and management activities de­pends directly on this data. Thus, the service provider would benefit from an AI data strategy. What do I mean by this?

To answer this question, I will first review the data issues that a service provider typi­cally faces. As we will see, these issues undermine the usefulness of ser­vice ma­nage­ment data in sup­port­ing artificial intelligence. I will then articulate various data strategies intending to address these issues. These strategies should provide a sound basis for using AI to support the delivery and management of services.

The Problem of Service Management Data

Consider how service pro­vi­ders often approach the management of the data concerning their management of services. They define a set of management disciplines, such as incident ma­nage­ment, change ma­nage­ment, pro­blem ma­nage­ment, etc. Each dis­cipline handles a set of cases. Data records describe each case. One or more service management tools store these data records in their re­spec­tive databases.

This approach leads to a variety of issues in data management:

  • Focus on collecting data about non-value adding activities
  • Multiple systems of record
  • Focus on the volume of work rather than the quality of work
  • Redundant data recording
  • Devaluing service support roles
  • Focus on inspection and correction rather than the right quality at the service act

Non-value adding activities

Net value of service acts after incident
Fig. 1: Imperfect service management reduces the net potential value of service

In almost all cases, these dis­ci­plines are non-value adding (as viewed from a lean perspective). In other words, they are concerned with preventing the destruction of value, rather than making positive contributions di­rect­ly to the service consumers. Thus, handling a service incident does not increase the value of the disrupted service act; it only tries to restore normal operations in a timely way. Often, the incident destroys value in proportion to the length of time required to restore acceptable ope­ra­tions.

Handling a change concerns iden­ti­fy­ing the negative risks associated with the change and ensuring appropriate mitigation of those risks. Failure to identify and appropriately mitigate such risks increases the probability that performing that change will destroy value.

Net value of service act - wrong understanding
Fig. 2: Wrong understaning! Even the best incident management cannot increase service act value

Looking at the other side of the coin, good handling of an incident nevertheless adds no value to the service acts that were disrupted. At best, today’s good incident handling can help tomorrow’s incident handl­ing to resolve incidents with even less destruction of value.

Similarly, even though a service provider might per­form a change under perfect control, that control would not make the change more valuable. Again, good change control might result in future change requests that better analyze and plan for risks, but it does not increase the value of the changes themselves.

Thus, the data collected from many service management dis­ci­plines (indeed, the disciplines on which most organizations focus!) cannot be the basis for improving how the service provider adds value.

Systems of record

Service providers generally create authoritative records of management activities based on the data collected about those cases. Those data allow service providers to com­pare their performance to bench­marks, to justify their in­vest­ments in management resources and, one hopes, to guide improvement ac­ti­vi­ties. The decisions made about handling cases determine which data are collected. Thus, those data reflect, at best, what was done, rather than what should have been done.

systems of record
Fig. 3: The quality of a service act is directly influenced by the data collected during the service act. The data used in the reporting tool can only indirectly influence future performance.

Post mortems, prob­lem management, knowledge ma­nage­ment and other im­prove­ment activities ad­dress the gap between what did happen and what should have happened. Often, what should have happened differs sig­ni­fi­cantly from what had initially been planned. Initial planning never considers all possible even­tu­ali­ties. Com­plete­ly unexpected events occur. Sometimes, a com­bi­na­tion of anodyne events occurs in un­pre­dict­able ways. Also, the planning is sometimes incomplete or inaccurate. The result is that there is a split between the system of record that records what did happen and the system of im­prove­ment that attempts to shape what will happen, if there is a next time.

But which system is used to train artificial intelligence to support future service act performance? AI should be trained on the records of what did happen and what should have happened (ac­cord­ing to a post mortem). All too often, the only the record of what was planned is preserved after the fact. The actors in the service act record in an unstructured way what did happen, if they record it at all. They record what should have happened, again, if recorded at all, in an abstract, generalized format. If the service management personnel record links be­tween the records of what did happen and the record of what should have happened, such as the link between an incident and a problem or a change and an incident, those link structures have minimal se­man­tic value.

Volume of work rather than value of work

Data collection during the handling of a case is problematic for various rea­sons. First and fore­most is the pressure to work quickly. While this pressure might be most obvious for handling service incidents, it is present in all disciplines. This is because most managers tend to assess work in terms of the volume of cases handle per unit of time, rather than in terms of the value accrued to providers and consumers by the handling of those cases.

emphasis on volume of work
Fig. 4: Emphasis on the volume of work
emphasis on value of work
Fig. 5: Emphasis on the value of work

Service management tools and technology management tools

redundant work with ITSM tools
Fig. 6: Technology specialists are often asked to do redundant work using ITSM tools

Another issue is the use of service management tools in parallel with technology ma­nage­ment tools. Virtually all service system technical components, such as server platforms, network nodes or databases, have their own management tools. These tools are the primary interfaces between the com­po­nents themselves and the specialized personnel ma­nag­ing those components. The architects of service ma­nage­ment tools ask those spe­ci­a­lists to record the same data that is available in those management tools. They im­pose a significant manual and redundant effort since there are hardly any auto­mated interfaces between tech­no­logy management tools and ser­vice management tools, ex­cept­ing events or alerts. That effort is of little value to the specialists, who depend instead on their tech­nology management tools for their perceptions of reality. Con­se­quent­ly, records tend to be in­com­plete and prone to contain errors of fact.

Low cost and high turnover

When considering the first line of support for service consumers (in organizations where this tra­di­tional struc­ture exists), the issues are quite different. Too often, managers treat these support people as if they were fungible, with the result that they are thought to be easily replaceable and worthy of only very low salaries.

These two factors work against the need to develop experience in working with a service provider, learning about its culture, its services, its technologies and its con­sumers. Often, there is little investment in training and developing these people. If they gain enough experience to be effective, they quickly move on to other positions. In many org­ani­za­tions, com­mu­ni­ca­tions be­tween first and second lines of support (and, heaven forbid, the third line of support) are erratic at best. The first line sends work to the second line, which sends that work back because it is, in the view of the second line, incomplete, erroneous or mis­directed. In spite of these issues, they hardly ever reserve enough time to transfer the know­ledge that would be required to get the data re­corded correctly the first time around.

A traditional command and control approach to managing data quality fo­cuses, as we will see be­low, on inspection and data correction activities. But preventive improvement ac­ti­vi­ties, too, are prob­le­matic because they are very poorly scalable. Since the individual experiences and knowledge of each support agent are likely to be very different, improvement needs to be tailored to the individual. Unwilling to invest in such expensive and extended development ap­proa­ches, many organizations end up doing exactly the opposite of improvement. Instead of bene­fiting from the particular skills and know­ledge of each agent, they seek to bring them all down to a least common de­nom­i­na­tor of behavior. Support becomes pre­dic­tably humdrum and un­in­spir­ing.

Thus, the circumstances described above often im­pair the quality of the data recorded about the handled cases.

Inspection and Data Correction

Recognizing the issues described above, some org­ani­za­tions invest in data record inspection and cor­rec­tion as part of the closure activity in case handling. They justify this activity in various ways. It is a way of detecting quality issues in the handl­ing of cases. Thus, it is a precursor to some type of improvement activity, a highly laudable purpose. Furthermore, by improving the quality of the data in the records, the reporting should be more accurate.

Often, someone other than the person who initially handled the case handles the inspection and correction of that data. This inspection activity may introduce ad­di­tional bias to the data recorded. The initial data recorder already has certain biases concerning what data they deem worthy to record. The inspector does not have first-hand knowledge of the case. Thus, the corrected data reflects that inspector’s in­e­vi­tably biased un­der­standing of the documented issue. A discussion between the ori­gi­nal data recorder and the inspector might mitigate the problem of bias, but how many organizations are willing to invest in what is essentially triple work? Fur­ther­more, faulty memory tends to facilitate the in­tro­duc­tion of biases, unless the inspection occurs very soon after the events.

Unfortunately, the inspection and correction approach comes too late to avoid the waste in the handling of the case. The situation is exactly as in the manufacture of goods. If you wait to the end of the production line to inspect the goods and throw away the defective ones, you do nothing about all the wasted effort that went into producing the defective goods, not to mention the cost of the wasted raw materials and the wasted intermediate inventory handling.

So it is with service delivery and service management. If you deliver the wrong service or if you handle a ma­nage­ment activity in­cor­rect­ly, you destroy value and damage your reputation. The moment of truth is during the service act. True, an im­prove­ment activity might help to avoid future cases of such damage. But that future improvement is of no use for the consumer who abandons the service pro­vi­der, given the poor service in the past.

Operational and Tactical Uses of Data

In the discussion above, the service provider uses some data about service delivery and management in an operational way. The data are inputs that determine the nature of the service de­li­vered. Service providers also use them to manage the flow of work. Thus, a tra­di­tional org­ani­za­tion, with lines of support based on tech­no­logy, may use case classification to manage the assignment of cases to one team or another.

Given the issues raised above, errors in the data may lead to delivering the wrong service or performing the service in an in­ef­fective or inefficient way. Thus, service providers use these same data in a tactical way to detect errors, to prioritize issues and to support future improvement activities.

In spite of the issues I have raised, I hold these oper­a­tional and tactical uses of service data to be ex­tremely important and do not dis­count them. However, the service provider will make best use of artificial in­tel­li­gence by applying it at the moments of truth during the service acts. This timely use of AI leads to greater efficiency, less waste and higher con­sumer satisfaction.

Artificial intelligence, such as is the state of the art today, depends heavily on the quality of the data that it models, the data that is the basis of its training. Rather than depending on a purely operational or tactical ap­proach to these data, a service provider should have a strategic approach to ac­quiring and managing those data if it wishes to benefit fully from the advantages of artificial intelligence. Good data become sine qua non for good artificial intelligence, rather than being a luxury—great if you have it, but you can muddle through if not.

Recommended AI Data Strategy

Various disciplines, such as bus­i­ness intelligence, data science or business process automation, use data stra­te­gies that also support artificial intelligence. Al­though the service provider might already use some of these strategies, it should focus on their importance for the successful use of AI. Here are some of the key strategies:

  • unifying all relevant data in a single data source
  • basing decisions on detailed data, not ag­gre­gated data
  • interfacing with tech­no­logy ma­nage­ment tools
  • automating data capture
  • using machine learning techniques to test cap­tured data plausibility
  • using a virtuous cycle of improvement

AI Data Strategy 1: Single Data Source

In the early day of service management practices (before ca. 2005), service providers managed their services using essentially two types of tools: the tools used to manage the technology and the tools used to manage the workflow. However, as service ma­nage­ment gained traction as a distinct discipline, software designers developed more and more tools to support the goals of well managed services.

This flowering of technology also led to the storing of service-related data in many different tools. To allow machine learning to benefit from those data, the service provider should consolidate them within a single data source. Given the large volumes of data that a service provider might have available, the so-called “big data” tools and techniques might be required to achieve acceptable levels of performance. This is true both for training an AI and for using an AI in an operational context.

Before the use of AI and statistical learning tech­niques, service providers ty­pi­cal­ly ag­gre­gated in­di­vi­dual data sources into databases used for reporting and as systems of record (see Fig. 7). As we will see, aggregates cannot be the basis for AI use.

Fig. 7: Typical reporting databases aggregate data from a partial set of sources
Detailed unified data store
Fig. 8: AI analysis depends on a single, unified, detailed data source

AI Data Strategy 2: Detailed, not Aggregated, Data

The complication of data sources described above led to the de­ve­lop­ment of tools to synthesize the data and provide high-level ana­ly­ti­cal and reporting tools. Often, these reporting tools were based on aggregated data, rather than on the low-level data collected as part of service operations. They were the basis for the analysis of trends and reporting on service level objective compliance.

Service providers assume that aggregation permits insights into the data leading to more useful levels of information and better decisions. Fur­ther­more, ag­gre­gated data is often the basis for reporting on systems of record, such as for financial statements. These data must be stable.

Although aggregation does provide certain analytical in­sights, it nonetheless in­tro­duces bias in describing data. This bias can destroy the potential for other types of insights. For example, if you report financial data ag­gre­gated according to a chart of accounts, you might have good visibility of the difference between the cost on sales and overhead costs, but you are not likely to have any visibility on the impact of cost reductions on sales, by customer segment.

In service management, it is common to aggregate data as counts of cases handled per reporting period. In problem management, you might report the number of open problems at the start and the close of January, as well as the count of problems resolved or canceled during that month. But this aggregation gives you no insight into how problems relate to each other or why one team might be successful in re­solv­ing many problems whereas another team seems to do nothing at all about problems.

In service delivery, it is common to report on the count of service acts, typically broken down by customer segmentation criteria. As important as that might be, these aggregates do not give a basis for assessing how and why the segmentation criteria might evolve over time.

AI Data Strategy 3: Automated Data Capture

One of the results of the segregation of service ma­nage­ment tools from and technology ma­nage­ment tools is that service management personnel must capture man­u­al­ly in service ma­nage­ment tools much of the data already available in tech­nology ma­nage­ment tools. Each time a human agent manually copies data, that agent’s biases may unconsciously filter the data; may introduce errors in the data; and fail to complete data entry, or even fail to capture the data at all.

While some service ma­nage­ment tools are provided with con­nec­tors that support the importing of data from other tools, these connectors tend to exist mostly for creating new records—especially in­ci­dent re­cords—based on events that mon­i­tor­ing tools detect. Tool architects do not generally design these con­nec­tors to query other systems for the purpose of completing a single field within a pre-existing record.

redundant manual capture of ITSM data
Fig. 9: Typically, technicians manually update ITSM records based on technology management tool data
Fig. 10: Automated data update of ITSM records directly from technology management tools

Service providers have dif­ficulty quantifying the effort required to redundantly cap­ture information man­u­al­ly. They can hardly mea­sure the biases and resulting errors. As a result, they bring few arguments to develop such interfaces to automate data cap­ture. Fur­ther­more, if the personnel lack clarity on how those data will be used, they are poorly motivated to ensure the quality of such data.

Machine learning, however, is able to analyze very large amounts of data about com­plex interactions. It can find correlations that human agents could only find by applying lengthy data science data techniques. The incentive for automatically capturing large amounts of data about how service systems work is to provide the basis for machine learning analysis.

AI Data Strategy 4: Plausibility Checks

However much tool in­te­gra­tion and automated data capture are in place, there will still be a large place for manual data capture. This is largely due to the un­struc­tured descriptions of events and requirements coming from the various service stakeholders, es­pec­i­ally the un­trained, un­initiated service con­sumers.

Support personnel, too, are known to record text that is in­complete, erroneous or other­­wise difficult to understand.  Although it is a significant chal­lenge, AI can help increase the plausibility of manually cap­tured data, making it more usable for subsequent analysis.

The more a service system is complex and tightly coupled the more it is a challenge to test the plausibility of cap­tured data. Take the example of analyzing the causes of a service incident or the risks of introducing a change to a service system. In a system with very few com­po­nents, where the flow of operational steps is not con­tinu­ous or is buffered between steps, analysts may easily identify which com­po­nent might be the location of a failure. For example, if there is no power to a computer, it is pretty simple in the vast majority of cases to identify whether the fault is in a power switch, an internal power supply, a cable or somewhere farther up­stream in the electrical sup­ply. However, suppose there is power to a computer but it appears to be frozen, not reacting to any key presses or mouse movements. This problem could be the result of a combination of many simple events or statuses, each of which in­di­vi­du­ally would not be a problem, would not cause a failure.

Now, suppose you want to capture a list of the com­ponents involved in a failure. In the power failure case, an analyst could identify with a high level of con­fi­dence which com­po­nents are plausibly involved. It would be extremely unlikely (albeit not im­pos­sible), that an external loudspeaker be the cause of the problem. If a user, by inattention, were to select such a component from a list, it should be possible to signal to that user that that component is probably in­cor­rectly entered.

In the case of a frozen computer, wherein many different components can in­ter­act in an unexpected way, it would be much more difficult to assess the plau­si­bility of any single com­po­nent as being involved in the problem.

So, we need to distinguish be­tween as­sess­ments based on past events (is it plausible because it has happened before?) and assessments based on system analysis (is it plausible because it coheres with the structure and the dynamics of the service system?). Assess­ment based on past events hardly needs a machine learning solution to deliver a response, insofar as the actors have reliably recorded structured data about events. Assess­ment based on system analysis is difficult, insofar as system structures are often im­per­fectly documented and system behavior is im­per­fectly understood. However, ana­lysts could exploit such algorithms such as Loopy Belief Pro­pa­ga­tion to calculate the probability of a node in a system being in a certain state, given what they know about the other nodes in that system.

How could a service provider use this information? Suppose an agent manually records data about an incident or a change. The management tool could assess the plausibility of those data display a plausibility signal, such as a color or a number on a plaus­i­bi­lity scale (say, 1 to 10). A poorly plausible data set does not mean the recorded data are incorrect. Rather, it is a signal that the agent might think some more about the accuracy of the recorded data. A highly plausible data set does not mean the recorded data is accurate; it only means that within the limits of what is known about the service system, there is no particular reason to doubt the accuracy of the recorded data.

To return to the power loss example, suppose an agent describes a failure in a computer wherein no power is available. Suppose he or she records that the failure involves the use of a certain application because the user reports having been using that application when the failure occurred. The tool would then assess the plaus­i­bi­lity of this in­for­ma­tion and display a warning sign. The warning does not mean that it is impossible for a locally running application to be the cause of a power outage. It only means that the re­la­tionship is so unlikely that it would be very inefficient to assign the incident to the administrator of that ap­pli­cation. Of course, if the historical record starts to show a pattern of power outages while that same application is in use, then the plausibility would cor­re­spon­dingly increase. The interest of using an AI to make this assess­ment is that it would be less likely subject to human biases. I suppose that most support agents would never give a second thought to the seemingly ridiculous idea that a business ap­pli­cation could cause a power outage.

AI Data Strategy 5: A Virtuous Cycle

Using AI to support service delivery and management can be the start of a virtuous cycle of improvement. When an initial pilot use of an AI-based tool shows very significant service ma­nage­ment performance im­prove­ments, there is a willingness to deploy that solution more widely. With wider de­ploy­ment comes greater breadth and depth in the data available to train and to improve the solution. And with an improved solution comes further use of AI. For a given AI application, the diversity and the volume of data sets used for training influence the degree to which the AI’s output is probably approximately cor­rect (PAC). As an AI demonstrates its value for a particular purpose, its use increases. As its use increases, more and more data becomes available for learning. And as the AI learns more and more, the virtuous cycle of improvement is closed.
AI data virtuous cycle
Fig. 11: A virtuous cycle fosters the quality of your data and the beneficial use of AI

This virtuous cycle serves to influence cultural change in the organization. If the organization was AI-skeptical, it will tend to increase trust in AI-based so­lu­tions. If the organization viewed the capture of data needed for good classification as little more than ad­mi­ni­stra­tive over­head, then the cycle will tend to convince actors of its value, both to the service consumers and to the service providers.

To get the virtuous cycle started, a service provider should trust to more than dumb luck and hap­pen­stance. If the data set used for initial training of the AI clas­si­fi­ca­tion tool is incomplete and of poor quality, then the trained tool is likely to yield un­sa­tis­factory results. Thus, it is important to encourage the strategy of high data quality as a precursor to im­ple­menting an AI tool.

Summary

Practices exacerbating the problem of cap­turing useful data have long plagued the management of services. These same practices will impact the po­ten­tial benefits of artificial in­tel­ligence in helping to deliver and manage services. By applying the AI data strategy described here, service providers will develop a culture of effective and efficient data cap­ture which, in turn, will support the beneficial use of AI.

Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International LicenseThe article AI Data Strategies for Service Management, by Robert S. Falkowitz, including all its contents, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Credits

All the diagrams are the work of the author

Summary
AI Data Strategy for Service Management
Article Name
AI Data Strategy for Service Management
Description
Is the data you record about managing services merely a by-product of other activities, just some administrative overhead? Do you want to benefit from artificial intelligence tools to improve your services? If so, you should consider establishing an AI data strategy in your organization.
Author
Robert S. Falkowitz
Publisher Name
Concentric Circle Consulting
Publisher Logo
Concentric Circle Consulting

Filed Under: Artificial Intelligence Tagged With: data, data capture, data strategy, strategy

Subscribe to our mailing list

Click here to be the first to learn of our events and publications
  • Email
  • Facebook
  • LinkedIn
  • Phone
  • Twitter
  • xing
  • YouTube

Reader Interactions

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

Kanban eLearning

Kanban training online

Recent Posts

  • The role of the problem manager
  • The Three Indicators
  • Visualization of Configurations

Tag Cloud

lean ITSM service request impact flow efficiency lead time manifesto for software development ITIL process knowledge management problem value leadership change management process definition cause Cost of Delay incident management tools priority rigidity kanban lean management resource liquidity waste risk value stream tools agile change control incident flow Incident Management automation urgency adaptive case management manifesto kanban board service manager bias knowledge work
  • Kanban eLearning
  • Services
  • Posts
  • Events
  • Publications
  • Subscribe
  • Rights & Duties
  • Personal Data

© 2014–2022 Concentric Circle Consulting · All Rights Reserved.
Concentric Circle Consulting Address
Log in

This site uses cookies . You accept those cookies when you continue to use this site. Cookie policyAllow cookiesNo 3rd party non-functional cookiesCookie policy
You can revoke your consent any time using the Revoke consent button.Change cookie settings