Helpful development and architecture advice for .NET developers

© Nick Chamberlain, LLC

EventStorming's Coincidence with Business Process Improvement

The purpose and implementation of EventStorming doesn’t only exist inside of Domain-Driven Design. Although the name “EventStorming” does tie itself to DDD, it has foundations in process improvement that have nothing to do with DDD and these are not new.

Parallels with business process improvement and LEAN

One technique that I’ve personally seen is business process improvement exercises used in Manufacturing to discover bottlenecks. Here, the same issue applies - Domain Experts aren’t fully aware of the bottlenecks outside of their processes. They live in a silo. While one process works well in their division - say the Accounting Department, the interaction with their division that includes this process is potentially a bottleneck for an outside division, like Sales.

Manufacturing

Pretend we’re a team of management consultants brought into a manufacturing firm to identify some bottlenecks and try to discover some ways to remove them that only involves simple process improvements - not software or tools.

How would you approach it? The COO said you have free reign, and has informed management that they must make themselves available at your request. So we get a list of email addresses - all management from each division of the company:

The first step that comes to mind is to have a meeting with each individual manager, the ones we have email addresses for. So we set up meetings, one for each department. We ask a set of questions about how they perform their essential duties.

Me: “Take me through the steps of booking a Quote for a customer…”

Sales Manager: “Well, once we get the go-ahead from the Customer we book the Quote in CRM. Then, we send it over to Finance to do a credit check. We wait for this and once it comes back, we go ahead and make sure the Quote gets to the Manufacturing department and the parts get built to the spec, making sure the factory reads the special requests that the Customer made…”

This conversation goes on, while focusing on the simple task of “Booking a Quote” that really defines the core function that this particular Sales Team is responsible for. Then, we talk to the Finance Team:

Me: “Take me through what happens when a Salesperson Books a Quote…”

Finance Manager: “Well, we have to do a credit check on the Customer, just to make sure they can pay their Invoice when we send it after they receive their Shipment. Once they pass their credit check, we give the Salesperson the OK that the Quote can be converted to an Order…”

Everyone goes in to a lot of detail about their own internal processes and their interactions with other departments and your team takes detailed notes.

Is this information useful for discovering bottlenecks? How quickly can you process all of this information and tell the COO that each manager needs to do X and Y and have their team do things differently to iron out these bottlenecks that hurt the bottom line? It’d be tough. Bottlenecks tend to happen at the boundaries of these divisions of the company. When speaking to a single manager, you may be finding inefficiencies in their processes, but are you finding the bottlenecks that are truly killing the bottom-line?

Better bottleneck discovery

What are the kinds of things that cause bottlenecks in a business process?

There is a common thread here - that bottlenecks tend to happen at boundaries. In our discussion with the Sales Team, there were dependencies on external units that may have been bottlenecks, but how can you know for sure? Does Finance absolutely have to do credit checks on Customers? Finance explained that they just “do credit checks.” Do they do credit checks because they’re the only ones qualified to do so?

What about the interaction Sales has with the Manufacturing group? Must they constantly check the status of their Customer’s Shipment due to some process happening on the plant floor that isn’t as solid as it should be? If you were to ask Manufacturing if this process is working smoothly, what would they say?

The point is that silos exist between business units, and bottlenecks tend to appear at the boundaries of these silos. How can we really get to the root cause of the big, business impacting bottlenecks if we only interview one manager at a time? If we act only on the inefficiencies within the silos, we could be missing the most important inefficiencies going on at the business level.

When we look back at our task of discovering bottlenecks in the business, how can we revamp the process to discover the problems worth solving?

Gather everyone in one place and brain dump

When I was first exposed to LEAN/Six Sigma, I had already heard of EventStorming and immediately started to see a parallel. Members from every area of the business were gathered in a conference room. These members included salespeople, accountants, quality assurance, mechanics, etc. and were, for the most part not part of leadership in the organization.

In this case, the group was focused on what was already chosen as a group of bottlenecks in very specific business processes - Converting a quote to a sales order. The focus was kept small because the entire day was to be spent analyzing this single business process and how it could be improved.

So instead of above, where the management consultants had individual meetings with leadership inside of departmental silos - the group was intentionally chosen to be a sample of people directly involved in the business process across departmental boundaries.

They were given a stack of stickie notes and sharpies and a simple command “map out exactly what happens from start to finish when a quote gets booked.”

The team quickly started putting stickies on the wall: “Take down Customer info,” “Get price from quoting system,” “Check inventory,” etc…

They then started connecting the different parts of the process in terms of conditions that had to be met before continuing, different scenarios that could happen if the Quote was an edge-case.

They also drew the organizational boundaries that they were crossing during this process “Convert a quote to a sales order”.

Finally, they started talking about “unnecessary back and forth,” “paper shuffling,” “why do we have to send { blank } to you to get approval?”….

After this exercise, they were tasked with finding small parts of this process that they could do differently that would improve it. The possibilities seemed endless, and further analysis was done to nail down to a handful of improvements.

Ultimately, it was the unnecessary back and forth between Sales and Finance to do a simple credit checks for a Customer that was a quick and easy win for the group. They proposed it to their team and leadership, and the Sales team began doing credit checks on their own. Another, even bigger quick win - the Sales Support Team was pretty much unnecessary as a division on its own, it had been imagined over time. They quickly absorbed this team into the Sales team and cross trained them to work directly inside Sales. They measured that there were improvements and there clearly were.

Summary

Skeptics of DDD and it’s counterparts may look at EventStorming as cargo-culting but I believe it’s simply grabbing concepts that have already been successful and applying them to software to make the goal of DDD quicker to achieve - getting the software closer to the business.

It also shows how focusing on smaller bottlenecks and processes should be part of the EventStorming process. EventStorming is likely to bring out more than just a focused set of things to work on, and focusing on a smaller business process might help prioritize which problem the software team needs to be working on.

Using stickie notes and gathering a broad range of domain experts has been successful in the LEAN/Six Sigma business process improvement paradigm. With EventStorming, we are just building on the idea that getting different perspectives all in the same room and allowing people to brainstorm quickly without the impedance of diagramming software and PowerPoints results in much deeper understandings of the business as a whole.

Tweet
comments powered by Disqus