How CIOs Use IT Design Patterns Enterprise-Wide to Elevate Employee Experience

Posted by on March 13, 2020

IT Design Patterns

Employee experience is a pressing topic today among IT and business leaders who have recognized that the path to better customer experience (and, ultimately, profitability) starts with truly engaged employees. Top performing organizations have made this connection and are looking for ways to improve daily work experiences by removing barriers to productive work wherever and whenever possible. There are a lot of facets to employee experience, but for this discussion, I want to focus on a cluster of IT processes that can be automated and applied across virtually every business function for a dramatic effect on the daily work experiences of your employees.

Over my 25 years in IT as a developer, architect, consultant, solutions engineer, tech sales manager, and product marketer, I have directed the execution of countless processes and workstreams, ranging from the most basic to incredibly sophisticated, across both app dev and IT ops. Some of these, like waterfall, seemed inefficient and eventually were replaced with Agile processes that put more focus on incremental delivery of customer value. Other processes, like the five I’m about to discuss, have stood the test of time—and for good reason.  

These five processes (incident, request, knowledge, change, and asset) are nearly ubiquitous within IT Ops, and, more specifically, within the service desk environment. Introduced and popularized in the 1980s with the emergence of ITIL, these processes deserve special focus not simply because of their longevity, but also because of their profound relevance and broad applicability to nearly every line of business within the enterprise. As such, throughout this article, I’ll refer to these processes as “design patterns,” which are “solutions to software design problems that occur consistently in real-world application development and present a reusable framework of designs and interactions of objects.”

Why should you, as an executive IT leader, care about these IT design patterns, particularly if they were developed in the last millennia? Because each of these patterns, when applied to the right processes and workflows, can have a significant impact on employee productivity and engagement—two important hallmarks of a healthy business. And when applied together, that effect is multiplied. So if elevating (if not revolutionizing) the employee experience is among your own organizational initiatives, read on. 

Design Pattern 1: Incident

The incident or event pattern is about handling unplanned interruptions in work across the business. In ITIL, an incident is defined as an unplanned interruption or reduction in quality of an IT service.

But when you apply that pattern more broadly, you can see it everywhere. A burned out lightbulb and a broken chair are facilities “incidents.” An issue with an employee might be called an HR case, but the pattern of submitting the case with related information, along with type or category, and then routing that case to the appropriate person in HR to handle based on function, geography, or departmental coverage would share many characteristics. In the world of security, there are some specific rules to follow, but security events, and in some cases security incidents, share many similarities as well.

Another important dimension for this pattern are the KPIs and metrics such as MTTR (mean time to resolution), which allow teams to measure and improve efficiency in handling and resolving those incidents.

Design Pattern 2: Request

The request process relates to the capturing, tracking, and fulfillment of employee requests for materials, systems, or information to aid in their daily work. Common IT requests include laptops, mobile devices, software, or other IT related tools to make work “flow.” More mature organizations put all of these items in a service catalog and make it simple for employees to make those requests. Other departments have similar flows such as ordering a chair, requesting the hire or onboarding of a new employee, a legal contract review, an update to an HR form—the list goes on and on.

Once again, there are similarities in the process flow including a form that captures specific information, an approval flow, maybe a filtered view of services depending on location or role, potentially a charge-back or cost, and a typical service-level agreement (SLA) timeframe for the fulfillment of the request. Finally, many of these request types may reside in a service catalog offered through a self-service portal. In addition, many of these processes can be accelerated and streamlined through workflow automation.

Design Pattern 3: Knowledge

The knowledge pattern involves capturing and sharing knowledge in a structured way such that employees can locate step-by-step guidance  to help them resolve or work around common challenges or incidents. Since knowledge workers spend about 20 percent of their time looking for information needed to be productive, the knowledge practice is extremely valuable if managed correctly.

The key is making it easy to create, validate, share, find, and use knowledge articles. Crowdsourcing can be a great way to ensure knowledge articles are actually useful and stay fresh through voting, likes, ratings, and comments. Knowledge should also be easily filtered or personalized based on role, location, country, and more. A flexible knowledge base allows IT, HR, and many other departments to easily structure and share information with employees, improving their self-service experience.

Design Pattern 4: Change

The change pattern manages the risk, coordination, scheduling, and execution of changes to processes, systems, and more. ITIL change management offers a very rich set of change processes and practices that have been tested and refined over decades. This pattern is very helpful in other departments outside of IT to ensure that there is a systematic way of governing and controlling change. One concept that may be applicable in many areas is a Change Advisory Board (CAB), which is a group of qualified people that review and approve changes.

Design Pattern 5: Asset

The asset process handles the lifecycle of physical or non-physical items needed to do work. In IT, this typically refers to both IT hardware and software which need to be tracked for financial, security, and other reasons. This pattern extends across the organization and can be useful in many ways. For instance, a trucking company might use this pattern to manage systems onboard trucks or even loads. A hospital might use this system to track medical devices. A school district could use asset management to track their stoves and refrigerators in their school kitchens. In all instances, there may also be a maintenance cycle that includes periodic preventative maintenance. Also, many times the maintenance may be handled by an external service provider and a system of tracking maintenance requests or incidents is important to manage.

Relationships Between the Patterns 

Another important aspect of these patterns are the relationships between them. For instance, if there is something wrong with my chair or laptop (asset), I may want to submit an incident to get it fixed—this denotes a meaningful relationship between an asset and an incident. Let’s examine some of the common relationships between these patterns: 

Incident and Asset

  • When an incident is submitted against an asset and there are several other incidents submitted against that asset, this could lead to a problem analysis of the asset that may warrant replacement or repair.

  • Incident history on assets may also lead to predictive data on when an asset might fail or patterns of failure.

Incident and Knowledge

  • Knowledge articles are very useful in speeding the time to resolution on common incident types.

  • Knowledge articles can be created from incident resolution notes and procedures.

Incident and Change

  • Several similar incidents may lead to the need to make changes to a system or asset.

Request and Asset

  • Requests are many times for the purchase of new assets, and common asset types are generally available in the service catalog.

Change and Asset

  • Changes are generally related to changes to one or more assets.

  • Assets could have multiple changes scheduled on them and indicates the need for coordination.


Because these patterns originate from IT, in most cases, IT understands them and has rich process frameworks to guide and govern them. And executive IT leaders who recognize the power of these design patterns can (and should!) build on these already well-understood and widely embraced processes.

In order to fully embrace such opportunities, IT leaders can play a key role in ensuring their service management platform can be extended beyond IT to facilitate and adapt these patterns across the enterprise as part of their efforts to improve employee engagement and everyday work experiences. 

To these ends, Cherwell Service Management provides a rich set of out-of-the-box capabilities for automating these patterns within IT, as well as across every conceivable line of business. Furthermore, Cherwell offers specific purpose-built solutions for HR, facilities, security, and other functional areas that embody these patterns and can be easily instantiated on the Cherwell CORE platform and “codelessly” modified to suit your unique use cases. Finally, with Cherwell, implementing new instances of these process types across the business can be completed in hours—not weeks or months—by ordinary IT staff wearing the mantle of citizen developers, due to its rapid, no-code development platform.

Learn more about the benefits of adopting a no-code service management platform in the article, “Cracking the Code to Faster Innovation.”

Read the Article

The Gartner 2020 Magic Quadrant is now available

Get Cherwell’s industry-leading tips, guidance, and case studies for better serivce management to help your business deliver, right in your inbox.

*Please complete email field