Formal Business Process Management practices have been around for at least 30 years.

When I was a kid, maybe 10 years old, my Mom, who worked in a County Welfare department explained to me what Time Studies were. A person would be responsible for accounting for the work that other people were doing, by observing and documenting the work. Who was doing the work? How long did each step take on average? What was the output of the work? What was the volume?

30 years years later, many organizations still lack this basic discipline of documenting and modeling the work that goes on in the organization. It is natural that the knowledge of what activities occur in an organization are embodied in the people doing the work. Yet, there is talk of "institutional knowledge" and what is lost when experienced people leave an organization. This refers to that embodied knowledge that may not be made explicit anywhere, and perhaps some knowledge cannot be made explicit.

Organizations are abstractions. Organizations are a group of people and typically exist as a legal entity in one or more jurisdictions. It is possible to model the people in an organization on an org chart, which is sometimes also called an Organogram.

--

It is also possible to model the Services an organization provides.

In software development, the term "API" refers to "Application Programming Interface." An API is how people can use and interact with a piece of software. An API describes the interface, the affordances, of a piece of software.

Similarly, an organization can be thought of as having an interface.

In a coffee shop, the interface includes the building, the line, the menu, the counter. The experience includes waiting in line, placing an order, getting the coffee, and drinking the coffee.

These things might be obvious. And that is okay.

---

In a larger organization, the interface is revealed by examining where inputs occur and where outputs are produced. Inputs can be phone calls to a purchasing department or an form submission on a website. Outputs can be a product shipped to your house, or access to a digital good.

Again, I'm describing the inputs and outputs from an organization, the interface.

---

And so, public agencies exist, and they all have or could have org charts. They also could have Service Inventories. And for each Service in a Service Inventory, they could have a model of that service.

Common types of Service Models include:

• Business Process Models
• Service Blueprints
• Journey Maps
• Swimlane diagrams
• Sequence diagrams
• An informal sketch of boxes and arrows

Like how a map is not the territory, a model is not the service.

And like how no map is fully accurate, some models are useful.

---

Service models can be useful, in a similar way to maps, because:

• a model can be used to distill and share understanding across multiple people
• a model can be refined over time
• opportunities to measure a service can be identified
• additional information can be layered onto a model

---

• Identify the Service
• List the people and systems involved
• List the events that occur, in the order they occur, to the best of your ability. Know that you can always adjust later, so don't be intimated trying to achieve perfection.
• Identify starting and ending states
• Identify conditions between events. If this, then that. Or, only when X is greater than Y.
• Identify sub-processes.

Ultimately, designing a service shares many similarities with designing software, so Domain Driven Design is a good concept and practice to be aware of.