Building Resilient Operations

When I was still relatively early in my career, and took the helm of a manufacturing operations organization, the predominant model for operations was that they should be stable, crank-turning efforts delivering consistently. Operational processes within that model were relatively fixed, quickly institutionalized, and incrementally improved. That is not the world we live in today.

Don’t get me wrong. There is still a place for stable processes. Pharmaceutical and medical device manufacturing, air traffic control systems, satellite manufacturing, auto manufacturing and any other life and/or mission critical activities require highly stable, repeatable, and monitorable processes. That said, those types of processes are the exceptions rather than the rule these days.

We live in a world of disruption. We are simultaneously experiencing globalization and localization across all sectors. New business models are emerging while others are sun-setting. New technology, [hello ChatGPT], are setting flames to old ways of doing work. Customer preferences are radically changing as younger generations become the dominant spenders and power users. The regulation tapestry shifts daily with local and regional requirements reverberating globally. Operational stability in an unstable world requires a different kind of thinking.

What do we mean by ‘Operations’?

Operations include a set of activities designed to be the working mechanism to harvest value. In less academic terms, operations are a set of aligned efforts that deliver value to an organization. In the business world ‘operations’ generally harvest value from the businesses assets.

Those operations vary widely, depending on functional needs. Operations for Human Resources ensure organizational resourcing needs are fulfilled with well-fit, productive people. Manufacturing operations deliver products as needed to meet customer demand. Sales operations ensure that the sales funnel is managed to maximize sales completions from the potential available prospects. Product Operations ensure the team executes on the most valuable portfolio of products to launch. Corporate business operations ensure that available internal performance date, trend information, and organizational health feedback is spun into insights that support leadership decision making. Each of these operational efforts have very different objectives and conditions of satisfaction. Yet, all operations have some common ground.

All operations are built to meet a value-add objective. Whatever flows into the operation will be worth more as an operational output. Operations provide a transformation or transformations of raw input into a significantly more valuable output. Operational performance is measurable, both in terms of output, for example widgets produced, and process performance, such as the effort, effectiveness, resources, and time required. Finally, operations are constructed via one or more processes, often a bundle of interacting processes, working to deliver the required output. To effectively explore operations, ‘process’ must be addressed. However, before we explore ‘process’, we are going to take a slight detour to consider an organization’s appetite for process.

What Aspects are Common to All Operations?

While operations are customized to specific purposes, they all have common features. Those common features include:

Task / Transaction Management

At the core of operations are its processes. In its simplest form, an operational process is a series of tasks required to complete an action. More complex process structures may have multiple, parallel interactive processes. Regardless of the process structure, the tasks work in concert to capture, track, and deliver the desired outcome. For example, a hiring process results in hiring the right person for a role. That process is broken down into multiple tasks, such as:

• Crafting and posting the job specification.
• Capturing candidate applications.
• Vetting and selecting the candidates to screen.
• Screen the candidates.
• Interview the candidates.
• Select the preferred candidate.
• Presenting the offer to the selected candidate.
• Negotiating terms.
• Hire and onboard the new employee.

Each of these key steps can be split into multiple, narrower tasks. The capturing the candidate application requires providing an application that requires the applicant to provide all of the information required to assess candidate qualifications in a way to compare between candidates. The well rendered process identifies the best possible candidate and closes the deal on the hire.

The Power of Transactions. Those tasks are embedded with transactions. Anyone that has applied to a job recently has likely found the description online. If interested in the role, they would click the ‘Apply’ button. This action creates a transaction of their interest. That transaction is now a data point that can be analyzed later to answer the question, “How many people started the application process?” We will discuss the analytics more later. As an activity moves through a task, transactions are captured both to progress the actions of the task and for data capture. In the example set up here, transactions and the data are captured through a software application.

Performance Monitoring, Analytics & Reporting

As the transactions amass, we are able to analyze the data. We have two types of performance we can monitor — process output performance and process performance.

Output performance for the hiring process may include things like how long it takes from posting to hire, number of finalists which the hiring manager would be willing to hire, how many offers were not accepted, and what critical information emerged in the interview process that were not captured in the application. Process performance may look at the duration of each activity within the task and level of internal effort required to complete activities.

This analyzed data can be reported for different purposes. The hiring organization will be interested in the output performance. The recruiting organization will be interested in the process performance to identify areas of improvement.

Process Types

Processes are customized to and serve specific purposes. They come in three general forms — continuous, event driven, and project driven.

Continuous — The hiring process above is an example of a continuous process. The process is ‘permanent’ in that it is in place and common for all hiring. Anytime the organization makes a hire, it uses that process to complete the tasks and capture the transactions. The collected data is analyzed and reported out on an established frequency. As the name indicates, these processes are established and are continuously available for use and tracking.

Event Driven — These types of processes are custom to specific events and likely flex from event to event. An example of this sort of process might be quarterly business reviews. Quarterly business reviews have a general structure that requires capturing organization performance information, curating it, and then framing it for leadership review. However, the specific types of performance information, the packaging, and method of review will vary from quarterly review to review. Because these processes are likely to flex it is difficult to automate them. So we tend to keep these types of processes simple, manual, and run by an experienced, process expert.

Project Driven — Project driven processes track project work. While project processes customize somewhat to support the specific project, they have a specific rhythm and phases which are common across all projects including concept, design, test, launch, land. While the work within the phases varies from project to project, phase exit requirements can be established in common and therefore partially automated to create a project information repository and support performance reporting.

Continuous Improvement

Regardless of process type, we can always make it better. We are always looking for ways to make the output more valuable, accelerate the process throughput, reduce the effort required to navigate the process, and improve the experience for those engaging the process. To understand what we need to do to improve the process we need to define process issues. There are two methods we can use to clarify process improvement opportunities — process analytics and retrospectives.

Process Analytics — Using the collected performance data that we discussed above, we analyze process performance seeking opportunities for delivering better value, faster with less effort.

Retrospectives — A retrospective is a formal assessment used for capturing feedback on processes or completed projects focused on what can be approved. In addition to capturing process performance issues, retrospectives provide insight into user experience.

Ideally, we love to capture both the objective feedback from process analytics and subjective feedback captured in the retrospective to establish a robust picture of process performance and users experience to prioritize holistic improvements.

Engagement

Processes operate in a world of people — Beyond the process owner there are those that provide inputs, those that analyze the data, and those that benefit from the output of the process. Those stakeholders require engagement to effectively interact with the process. So we need to ensure they know how to engage the process. For cyclical activities we need to remind them when its time to engage.

Guidance — We need to provide guidance in the form of guidelines, training, and user support. The more complex and high stakes the process, the more involved this guidance will be with various forms of training, detailed guidance and frequently-asked-questions [FAQs], and potentially a tiered support structure.

Communications — In addition to guidance, we need to communicate expectations for cyclical efforts, such as a quarterly business review, such as when it starts, ends and what actions are expected. Finally, if we make process changes, clear communications of what those changes are and expected impacts to the various users.

Operations, an Allergen & Process, a Four Letter Word

Opinions vary on the value of ‘process’ depending on one’s point of view. Whereas a quality assurance lead looks at process as providing control, repeatability, and monitorability, all good things, most entrepreneurs see it as an unnecessary investment and hindrance. If operations add value to an organization, why are so many organizational leaders allergic to operations and treat ‘process’ as a four letter word? Why, in a world of productivity applications and automated transactional tools, do most executive teams manage operational efforts via documents, slides, spreadsheets, and human glue?

Operations, and their associated processes have a darkside. They are a blade that cuts both ways. Operations require structure to work. That structure guides the effort to create the value you are seeking. That same structure limits flexibility.

In an environment in which an organization’s ability to rapidly pivot toward opportunities or away from threats, limiting flexibility can be anything from annoying to an existential challenge. Leaders in entrepreneurships, startup companies, and companies in high growth avoid ‘process’ like the plague. They treasure and guard flexibility at the cost to structure. How can they do that and be successful? There are a few good reasons.

For small organizations, people are the process.

Studies have shown that organizations of under 150 people can operate tightly as if a single organism. For organizations of 50 or less the people-to-people connections are intimate and familiar. Work is self organizing and utterly synergistic. ‘Processes’ grow organically, communications are casual, and requirements are natively understood, even if those within the process can’t articulate them. If you visualize processes as colleagues holding hands to get the work done, then a pivot means turning in a new direction and grabbing a new set of hands. Why develop structures when it is more efficient and less constricting to avoid them?

For growing organizations, there’s a premium on production and sales.

Start ups exemplify this concept of being entirely focused on building products and/or services and getting them into paying customers’ collective hands. They are pure production machines for which any level of overhead, [such as operations], takes resources away from the hungry hungry hippo that is the start-up. Why pay for operations geeks when they need more engineers and sales folks?

High incremental revenues and cash flow hide inefficiency.

Even in large companies, leadership, high on the supply of a never ending, rapidly increasing, incremental revenues may be dismissive of process. Their attitude is “don’t mess with something that works. The companies grew without process. “So what if we are a bit inefficient. Look at our profit. We don’t want to screw that up with structure.”

I personally have experienced this version twice in my career. First, Sun Microsystems continued to operate as a start up well past its revenue peak in the early 2000s. When revenue growth began to decrease and then drop off the company ambitiously sought to completely rebuild core processes to drive efficiency and improve delivery. I was a director at Sun focused on that effort. Unfortunately, it was too late and too little. We managed to improve engine room efficiency in time for the Titanic to hit the iceberg. Sun was acquired by Oracle in 2010.

More recently, I worked at Google. Google experienced a triple hit in 2023. Google was already shoring up Search to try to capture younger users that cut their teeth on other platforms. Younger users were not regularly visiting Google the way the older generations had. Then post-covid usage drop off was compounded by the launch of GPT Chat. Suddenly the cash cow represented by Google Search and Ads was under distress. Cost reduction and tight focus on value delivery became the call of the day. At the time of this writing Google is in the throws of restructuring to deal with itself as a mature vs. growing enterprise.

Resilient Process Design

Historically, process management has been fairly internally focused. By that I mean that the process owner, once they have a working process in place, focuses on process improvement to take less time, less effort, more efficient, more stable. Unless they receive complaints, they do not necessarily consider the ecosystem in which the process operates. Flux-proof, durable process design considers all aspects of a process and does not end at launch.

Assessing Process Factors

What factors make a process valuable and work well? The simplest way to think about process is in three aspects — initiation, transformation, and outcome.

Initiation — What triggers the process to begin adding value. For a hiring process a candidate submitting their application triggers the evaluation process. For product manufacturing a product build order initiates the manufacturing build process. For online purchases, submitting a purchase order starts the delivery process. For a quarterly business review, the trigger might be as simple as an email with an information capture and synthesis schedule. The initiation prompts the beginning of the transformation process which successfully delivers the expected outcome.

Transformation — Simply put, the transformation includes all effort required to produce the expected outcome. The transformation creates a chain of value additions which ends when the expected value is delivered. That value chain can be very short. For example, when bartering, the process might be initiated when one child says, “I’ll trade you my peanut butter sandwich for your cookies. It ends when the other child says, “Sounds good. Here you go.” The transformation effort for that barter is miniscule. On the other end of the spectrum would be that ‘establishing a democracy’ in a new country. The transformation demanded by effort would take years, require multiple development work streams that would mutually influence each other, regular evaluation and feedback, and the creation of a democratic culture and multiple political and legal institutions to make it work.

Outcome

The outcome culminates when the expected value is delivered from the process. I’ve used the term ‘expected outcome’ a number of times. Expected is the operational term. A process will always deliver an outcome. However, the value of that output is completely dependent on the expectations. Expectations are a tricky beast. Expectations can be an individual set of requirements. The person that orders online has both expectations about the product and form of delivery. If those expectations are met, then the customer is satisfied. On the other end of that spectrum would be delivering that democracy. Every citizen of that country will have their own expectations about what that democracy will look like. Those expectations will vary and even be in conflict. Measuring the outcome value is quite difficult when every constituent values the outcome differently.

Beyond these aspects there are other considerations. What’s going on in the ecosystem around the process and how does it impact the initiation, transformation and outcome. What about the transformation itself? What steps are required to generate the transformation? What tasks within those steps are required? What variations must be considered? We’ll touch on those in a bit. But first, let’s first dive into those transformations.

Process, the Heart of Any Operation

In its simplest form, a process is a series of steps in which tasks are performed.

Each step has a mandate to provide additional value, or it should not be there. The image above represents an extraordinarily simple process. But the concepts are universal. If the processes in your operation are multitudinous, complex, and interdependent, the value-add concept holds true. If a step is not adding value both by providing transformation and to the desired process output, it should not be there. However, even if you have developed the most efficient transformation process to deliver your desired output, that may not be sufficient. External organizational pressures and internal culture will demand more out of your process than years past. You will need to design for flux.

Design Resilience Considerations

Process design requires elegant composition, extensive testing and incorporation of user feedback and other learnings to make it deliver value with the least, most focused effort. That does not stop at launch. In fact, resilient process design requires iterating on these considerations for as long as the process is operational. Better ideas will emerge. User tastes and needs will change. Organizational leaders will rotate. New technologies may change the game.

Big changes within your ecosystem mark an obvious moment for reviewing and potentially refreshing your process. The induction of a new executive, deploying a new strategy, finding out that customer demand is shifting, process failure are all big events that demand an obvious process review. But in order to address the potential of multiple, incremental changes that may have a cumulative, interactive effect, it’s wise to establish a sensible cadence of process efficacy reviews. You cannot establish a resilient process without learning from it.

Operations Development Considerations

Institutionalization

What do I mean by institutionalization? If you have ever spent time in Boston, you have experienced the benefits and disadvantages of institutionalization. Boston developed organically livestock paths turned into roads. The roads were eventually paved, while homes and businesses sprung up along the routes. Today’s Boston is a twisting winding rat’s nest of roads which can be confusing to newcomers. Veteran Bostonians have acclimated to the road system and have adjusted their behavior and developed habits to effectively use them. The road grid is quaint and colorful but makes for some of the most inefficient navigation in the U.S. If you are running an organization, you don’t want to attempt to do business on livestock trails.

In terms of this discussion, institutionalization means building structure around the process to make it repeatable, efficient, easy to engage, monitorable, and make the expected output value focused. These qualities sound good, but the downside for adding this sort of structure is loss of flexibility and the cost of both the structural improvements and then ongoing costs of making changes. So, choosing how and when to add the structure is critical to ongoing success.

Anyone that has used Amazon to purchase items has benefited from radical institutionalization. A user can easily find items that they want to purchase, purchase them with little effort, and receive them that day or as soon as humanly possible. Amazon has automated every aspect of the customer interface and delivery process to serve up vendor offerings. They make them incredibly easy for customers to find, and then automatically engage the warehouse in which it is stored to transport it to the customer’s desired location. That’s the benefit of a highly institutionalized process.

While automation works well for Amazon operations, automation is not always a good idea. Unstable processes and/or processes for which demand changes are poor candidates for automation. Before you make institutionalization decisions, I recommend the following steps.

• Generate process designs that incorporate all user input using clever process architecture.
• Pilot the process with the least structural development possible. Early design can be rapidly improved by rapid design / fix sprints.
• Stabilize the process to the degree you can given its purpose, output requirements, and feedback.
• Identify opportunities for institutionalization
• Use a light hand for structuring. Start first with templatizing tasks while monitoring user performance adoption, and experience.
• For highly repeatable, highly adopted tasks, identify tools that support that effort and develop an implementation program. [Get ready to spend money on the tool and the implementation experts.]
• Develop a change management effort to ensure rapid adoption.

A quick example of a mixed process is a quarterly business review [QBR]. These reviews are done to give the organizational leader a snapshot of organizational performance. A well run, mature QBR will provide insight into operational performance, status on major initiatives, state of resources including people and budget, and clarity on emerging opportunities and risks. The structure typically includes key performance indicators [metrics], commitment updates and emerging insights. Each type of insight demands a different level of structure.

• KPIs are always a target for automation. When the same metrics are reviewed repeatedly, the data can be systematically captured and delivered to a developed dashboard without human intervention.
• The commitment updates can be easily templatized but require a fair amount of human input. This activity has limited institutionalization potential.
• Emerging insights — learnings, emerging opportunities and risks, resisted structure. It’s hard to structure what you don’t know.

What are the Takeaways?

We live in a rapidly evolving economic, business, technology, and regulatory environment. Organizations have strong, sometimes existential, reasons for remaining flexible. They need to be able to rapidly pivot to pursue opportunities and avoid threats. Resilient operations designs must anticipate changes and easily adjust. That complicates operational design.

That said, operations have a critical role to play in taking raw input and transforming it into much needed high value outcomes in the fastest least effortful way possible. The process architect needs to balance the internal process requirements, the potential external shifts, and the need for flexibility. No easy task.

Operations design / build must consider highly repeatable activities, activities that can be lightly structured, and activities that will arrive with surprising timing and form.

Executing your design / build process should start lightly, with as many iterations as is possible to understand what is stable, lightly variable, and completely variable. Final processes are a misnomer. But you can get clear on your various levels of stability and instability and build accordingly.

Finally, schedule regular retrospectives to assess how well the processes are working and what has changed. If you follow these basic concepts you will establish and manage resilient processes that will stand the test of time.

Find more articles from Sarah at: www.operations-architect.com.