Intelligent Growth: How Much Process is Too Much Process?

This entry is for organizations at the beginning of their process journey. We will address more of the complex aspects of process transformation in a future post.

Because I spend a lot of time talking about operationalizing businesses it may seem I think there is always a process or technology fix for a company’s challenges but this is not the case. For smaller organizations in particular, over-designing operations can be just as damaging as letting things run as they are. It is important, therefore, to take a balanced approach to building your business processes and supporting tools.

Operating discipline is one of the first items companies need to address as they grow.

Discipline is a combination of the business processes, technology that automates and controls these processes, and the talent profiles and structure of the people responsible for executing the processes. You also need the management capabilities required to measure and lead a process-focused organization.

The goal of business processes is to create consistency in how your business runs and to make it more efficient and effective, more controllable, and more transparent.

The simplistic way people talk about this sometimes would lead you to believe that processes are only good if they make your business more efficient. This isn’t always the case. Good processes can slow things down to make them more predictable or more controllable. Bad processes can be quick and predictable but lack transparency. You need to weigh these factors differently based on your business, your scaling goals, and the specific processes at hand.

The challenge is figuring out how far to go now and what to save for laterHere are three key factors to consider when determining how far to go with your process transformation:

1. Efficiency and Effectiveness

Business processes should be designed to be as efficient as possible, but this only applies to entire process strings. You can design wonderful processes on a one-off basis that don’t work well together and lead to inefficiencies in the entire string. Efficiency needs to be looked at holistically, within an entire business process area. This means optimizing the processes independently first and then analyzing upstream and downstream impacts.

Build It

The process of creating a new customer and entering their first order may be spectacularly efficient but if it often results in incorrect products being shipped or incorrect shipping addresses, it’s inefficient and ineffective as a process string.

When you make processes more effective, you open up more automation possibilities. Good processes mean less rework and fewer iterations for a single execution. If you know the product on an order is going to be right by the time it hits fulfillment, then you can automate that fulfillment. If a person still needs to review it because 2 out of every 20 orders will need to be adjusted, you can’t automate it.

In this example, well defined processes make the order-to-fulfillment processes more efficient and more effective.

Keep It Lean

The way hotels react to customer complaints is highly variable and needs to be nimble. If a hotel staff is not empowered to react in real time to requests or complaints it substantially impacts the quality of service. Creating extensive processes around how to comp food, award extra points, or switch rooms would detract from the ability of the business to operate effectively.

In this example, efficiency and effectiveness is the absence of process, not presence of it.

2. Control

Like efficiency, control needs vary greatly from process to process. Some processes should have a high level of control – tax calculation and billing, for instance – and some shouldn't – like new product engineering. If a business process is a core management function, odds are it should be controlled. Processes linked to governmental compliance requirements will need a high level of definition and control. If there is a high level of human interaction or iterative work that is required, less control may be appropriate.

Build It

Journal entry approval always needs to be a highly controlled process. Ideally you have systems in place to automate a high percentage of your journal entries, but any manual entries will need a well-defined approval workflow and clear documentation requirements. At the end of the month, you can’t risk not understanding entries with significant financial impact that weren’t approved and have no evidence.

In this example, more control means more integrity in your financial reporting.

Keep It Lean

During product development, engineers will often need to buy a number of non-standard materials. Implementing formal approval processes for everything they need to purchase would slow the development process down. Creating broad levels of latitude to allow them to buy whatever they need, within reason, on-demand and without approval will lead to better, faster development.

In this example, less control leads to better (and faster) engineering results.

3. Transparency

For a process to be managed it needs to be transparent. Process management has become increasingly important for many organizations and is critical to companies that use methods like lean/six-sigma to constantly improve their operations. Key business processes should be decomposed and executed to a level so you can track and measure them in detail and manage them over time. Software to enable these processes will be required to produce meaningful reporting and analytics.

Build It

Manufacturing companies have important requirements about transparency because so much of their cost is directly related to production. Manufacturers should have processes decomposed to the point of being able to measure the effectiveness and timing of each step of the production process. This allows them to constantly lower the cost of their operations and understand which levers in the production process correlate most to product quality. More definition leads to more transparency that allows management to make decisions of substantial benefit to the business.

In this example, process definition also has wide-ranging impacts on product consistency, cost of quality, employee training, production capacity, etc.

Keep It Lean

I have come across several organizations that enforce too much process on how their sales reps interact with prospects. Understanding sales success at some logical milestones may have management value, but too much process limits the ability of reps to react to customer needs. You don’t want processes to intrude into the customer experience to the point where they turn sales reps – your human face to the customer – into automatons that have difficulty gaining trust. This is especially true when the transparency management gains only leads them towards decisions they would have difficulty executing anyway.

In this example, a reasonable level of detail in sales processes is appropriate but you should guard against over-engineering them.

Strive for Balance

There is no single answer for how much process is right for your business. The answer will change as you grow in employees, customers, transactions, and revenue. At RCG, we recommend sitting down with someone who can help you structure your roadmap to process transformation. This person can help you make your process discipline appropriate for your current size and also for where you hope to be in 2, 3, or 5 years. They can also help prepare your organization for the day-to-day impact they will feel with increased process definition.




Subscribe to Ronan Consulting Group - Steve's Blog by Email

Three ways to think differently in 2015, Part 2 of 3: Beyond Enablement

Beyond Enablement

On Tuesday we looked at using your exception-handling process to conceive and drive strategic improvement. Today, we will look at how pre-planned projects should be positioned to maximize their strategic value.

Something I used to tell people is that technology is not a good in-and-of itself, instead it is valuable as an “enabler” for improving something. As a result of my years doing massive transformation projects, I no longer believe this is an adequate explanation. While it’s true that a new tool or redesigned process can enable improvement or growth, if that’s the only thing it’s doing you’re missing major opportunities. If you’re going to go to the effort of doing a substantial project, it should actually propel you forward – not just enable something.

The issue with "enablement"

Some years ago I had a client who brought my team in to analyze, plan and ultimately implement a large systems transformation project. The core of the project would be replacement of a very old, cobbled-together ERP system that was no longer supported, but it would also include a number of enhancements to various boundary systems like CRM, data management, and warehouse management systems. In addition to core benefits like saving on support, less downtime and some replacement savings, the business case included a number of high-value opportunities like such as a) Automating inventory replenishment to match projected demand; b) Enhanced project profitability reporting; and c) When it was being sold to the business, executives and ultimately the board, the main selling point that the project would “enable” change in the enterprise. This was a mistake.

This messaging was interpreted to mean the project would enable them to operate their business a little better because the technology was newer, but wouldn’t substantially change the nature of their operations. As a result, as leadership responded to issues, new requirements, staffing shortages and budget constraints, higher-value “transformational” pieces of the project were shelved and it gradually devolved into a systems replacement project. This resulted in several high-value pieces of the business case going unrealized (they never tracked actual results to the business case either, but that is a post for another day). The project was successfully implemented and everything that was ultimately designed worked really well, but there was still a lot of value on the table. So what should we have done differently?

Why is the language important?

When I think of successful technology investments, I want them to drive the strategy forward. What we should have said was the project would help “drive strategic improvements into multiple areas of the business” or that it would “propel the change that was required for them to react to new market conditions.” Although it sounds like an overstatement, either of these would have been absolutely true. Most importantly, it would have changed how the executives and business leaders reacted to project exceptions:

  • They would have been more eager to put their best people and most influential leaders in key positions since they would be setting and executing strategically important parts of the business
  • They would have been more aggressive about insisting on changes to their processes and job responsibilities
  • The project would have received more visible and more powerful executive
  • There would have been more accountability for justifying the cost of the project by measuring actual benefits

Evolving to technology projects that "drive"

When I think about these projects now, I look at them in four ways:

In the pictures below, the orange dot represents the area the project will impact. The other dots represent four related but distinct areas of the business.

Replacement projects

Some system is outdated or incredibly unreliable so it needs to be replaced or upgraded. See my post from Tuesday on how to make this project more of a game changer. I won’t re-hash this again today

Enablement projects

How does the new solution improve its focus area?

Example: If you’re replacing a project accounting solution, does it make the function of project accounting easier and more accurate?

Improvement projects

This is sort of the “enablement” bucket. Am I improving this immediate area and making it easier for other areas to improve as well?

Blog 1.6.15 tech drives improvement_1.png

Example: When I implement a new project accounting solution, can I make it so the project values are visible to my receivables department and then train them to prioritize billing and cash collections by backlog and revenue? 

Projects that drive strategy

These projects drive the implementation of high-level strategy into the business and force the organization to implement, track, and improve on this strategy. These would achieve holistic transformation across the business and, in addition to achieving its core mission, force meaningful change in other important areas

Example: if your business is a products business but sees most of its future growth on the services side, when I do the project accounting project in points 2 and 3, do I change the expectations of my accounting department to not only track costs for engineering projects but also be able to report on profitability, labor time and expense, automatic estimate-to-complete, etc.? Then can I also change how projects are sold, staffed and billed based on historical data to make them more profitable and improve their quality?

Now is the time to re-frame the conversation

Technology is now going to be part of all strategic decisions you make. This year, all executives should understand how it interacts with your overarching strategy to make sure you're getting the most value out of your investments. Each investment has the ability to drive you forward; not simply to enable incremental improvement.

Last in the series, coming on Friday 1/8: Technology and talent: How tools should improve your people

Subscribe to Ronan Consulting Group - Steve's Blog by Email

Three ways to think differently in 2015, Part 1 of 3: Strategic Reactions

Happy new year and welcome to our first blog entry!

This week I will look at three new ways of thinking about something you will undoubtedly spend time and money on this year: technology.

  1. Strategic reactions: Exception handling as a means of driving strategy – 1/6/15
  2. “Enabling” vs. “Driving”: The issue with treating technology as an “enabler” – 1/8/15
  3. Technology and talent: Improving the experience of work through every technology project – 1/9/15

Strategic reactions: Exception handling as a means of driving strategy

The way the discourse around technology operations unfolds is always similar: you can either spend money reacting to problems (IT Operator) or growing the business (Strategic Driver). The problem with this reductive conversation is it understates three realities:

  • Even if you're driving strategy, you will still need to react to issues;
  • Technology will probably drive the implementation of your strategy whether it's incidental or intentional; and
  • Most businesses do not bifurcate responsibility for technology operations and technology strategy.

It is unlikely you have the luxury of technology that runs itself without any exceptions and therefore be allowed to fanatically pursue all your strategic goals. On the other side, you will necessarily need to engage in a technology project over the next 12 months to either keep up or to "enable"/“drive” strategic business improvements (more on this on Thursday). The question is how do you do execute the latter while managing the former?

Framework: Visualizing Reactions and Strategy

A more constructive conversation, in my mind, is one of tradeoffs that recognizes the strategic potential of any solution. Consultants sometimes use "process maturity" analysis to help executives understand where on the scale of reactive to strategic their technology decisions fall. This approach is that it implies a binary relationship between solving problems and driving strategy. This does not reflect the reality of how technology, which is now pervasive in every direction of your business, needs to work. You will have more issues to deal with in the next 12 months than you will have projects to drive: this is a guarantee. Great executives will make this work for their strategy. 

I am a proponent of speaking in terms of gradients rather than discrete scales. There are necessary tradeoffs you will need to make, sometimes prioritizing strategy and sometimes prioritizing operations. That’s ok. Is it possible to make some of those operating decisions also drive strategy, either in the short or the long term? Frequently you will find they can.

So rather than a straight-line or x/y axis maturity matrix, I prefer this visual: 

  • Dark blue represents basic operations, or “running the trains on time.” This makes your business work pretty well without substantially improving underlying functions 
  • Light blue represents incremental improvements that will either add up to something significant when combined with future improvements or will make it easier to do something big in the future. This can include adding functionality or reducing complexity.
  • Orange changes the game. This represents fixing a problem in a manner that transforms another function and allows you to achieve a strategic imperative.
Blog 1.6.15 Reaction Strategy Gradient.png


As an example, let’s take a seemingly minor problem that may arise for many companies this year: 

Your accounts receivable (AR) department receives a payment from a customer but it’s missing an invoice number. They go to apply the payment against an invoice and find there are two records for similarly named customers, each with open invoices. What should they do?

For simplicity’s sake, let’s say there are five issues this raises (in reality there are more):

a)    Immediate functional problem: cannot apply the cash
b)    Future functional problem: this will happen again in AR if the customer record issue is not resolved
c)    Operational problem: the operational efficiency of all processes associated with duplicate customer data will suffer inefficiency and potentially ineffectiveness
d)    Cross-functional problem: if these records exist in other systems (e.g. CRM, order management, etc.) then upstream processes will be affected
e)    Strategic problem: Meaningful customer analytics are severely compromised or not possible

First, you will need to figure out which invoice to apply the payment to, solving problem (a). This will probably require the AR department to contact the customer and do a little research. This is simple operations for them now. They’re going to do this anyway, regardless of our conversation. But now the question is how to address (b), (c), (d) and (e).

Pure dark blue: Combine the customer records into one, consolidate the invoices to that single customer, and resolve any data conflicts that arise (e.g. duplicate invoices, multiple shipping sites, missing DUNS numbers, etc.). This addresses (b).

Dark blue moving to light blue: Consolidate the master records for this customer and then, thinking this may be an issue for other customers as well, run reports and figure out if there were other records this applied to. This address (b) more thoroughly, begins to address (c), and makes solving (d) easier and, therefore, more realistic.

Purer light blue: Look at other systems that use that data like your CRM systems to see if the same issue needs to be resolved there. This will address (c) and make it possible to address the rest of (d).

Light Blue moving to orange: Create a customer data management responsibility where someone in the business is responsible for proactively monitoring customer data, resolving issues, and over time working with a technology partner to automate duplicate identification, merges, etc. This address (b) and (c) completely and may substantially address (d) although this will also introduce some new process complexity that will need to be analyzed.

Orange: Implement a data management solution that can manage the customer data across all functions. This will improve the sales team’s ability to accurately identify and track leads, allow integration between social media and customer transactions, provide efficient lead-to-order-to-invoice-to-cash conversion, and serve as the foundation for great customer-based analytics. Odds are, customer-based marketing and spending analytics are on your strategic radar. This will address (e) and, in doing so, drive new ways of thinking, analysis and decision into all customer-related business operations. 

As you can tell, there are unlimited variations of each of these approaches and they all have different complexity, levels of effort, costs, and time horizons. But as an executive you need to make sure the business operates at all, operates at least reasonably efficiently and reasonably well, all while furthering your strategic goals. Maybe you do all of the dark blue things now because they are low effort and low cost, but begin the process of planning and prioritizing a project to address the orange potential.

The main point is, you’re reacting to an issue in a manner that furthers your strategy and demonstrating to the business, through step-wise improvements, that bigger investments in previously ignored, seemingly commoditized areas can result in game-changing improvement.

You never let a serious crisis go to waste. And what I mean by that it's an opportunity to do things you think you could not do before.

Up Thursday: Moving from an “enabler” mindset to a “driver” mindset for technology decisions. A.k.a. Making Technology Investments Matter.


Subscribe to Ronan Consulting Group - Steve's Blog by Email