SIPOCs are an established tool in architecture. They are used to understand a process and help answer its elementary questions: who is involved, and which data is exchanged, and why. These questions mean that the business side, i.e. process owners and users, is often involved. A side effect of this group of users is that the tooling has to be as simple as possible. Discussion and capturing knowledge and expectations are the focus. Complicated tools are out. As a result, capturing a SIPOC is a simple affair: 5 defined columns. Nothing more. You can do it offline on paper in a workshop. Or in Excel. In Word. A wiki is also a popular choice.
What does a SIPOC consist of?
- A title and description
- The SIPOC columns
- Comments, files, a logbook
And with that we already have the basic problem of most SIPOCs: it’s chaos. Information chaos.
Creating SIPOCs is easy
One often assumes the chaos comes from different people, each with their own view, working together to capture the information for a SIPOC: different perspectives, different altitudes. Yes, the level of abstraction matters. And yes, that is certainly a factor that influences how a SIPOC is created. If, for a SIPOC on a sale, the process consultants focus on concrete payment steps - is payment made in cash, by card, digitally, should an e-receipt be issued, the postcode captured, a loyalty card handed out - while the users ask themselves instead whether the payment happens online or physically in a store, then there are different views of the process. But this resolves fairly quickly. To write something down, you need the same process, the same steps and the same understanding. Establishing that is, after all, also the job of the SIPOC.
So the chaos does not arise because different people were brought together, or because this non-homogeneous group doesn’t necessarily speak the same language or even share the same understanding of the process. The chaos comes from the fact that a SIPOC is, by nature, easy to create. Having several SIPOCs for one process is not unusual. That’s fine as long as they are based on different altitudes and views. Going from abstract to concrete and having 2, 3 or more SIPOCs along the way is nothing out of the ordinary. But if there are several SIPOCs on the same level of abstraction, that is a problem. Far too often, a new SIPOC is simply created. After all, it’s an easy thing to do. The result is the question of which one is valid. The latest? If so, why wasn’t its predecessor updated? Or removed?
Building on what exists means having it available: findable, with context.
… reusing them is not
Why adapt an existing SIPOC? Or even search for one first? Often it isn’t even known that a SIPOC for the process already exists. Especially when the old project team has been dissolved, the old storage location is inaccessible because no authorization is in place, or - worst case - it was deleted altogether. Another classic: the SIPOC exists, but where? On the external consultant’s hard drive? Under the name of a process that was replaced 10 years ago, or only under its code name? Hidden in a SharePoint page, in the Nth sub-level? In a wiki? But the pages have been moved several times over the years and not all the links work anymore? Especially in complex projects and larger companies, the necessary information can easily be found 10 directory levels deep. Search then favors other information. Or another classic: the important information is in an archive. One you need a specific authorization for. And the data has already been moved to another archive system. The SIPOC is then a GIF that was converted to a PDF … which is password-protected and can only be displayed with a special viewer.
Organizations do make an effort to create and preserve information. Sadly, reality shows all too often that information can get lost … and does.
Quality
On top of that come further problems that lie in the nature of a SIPOC. Naming is not consistent. Purchasing is called Purchasing once, then Procurement, or Dept-Purch., or the internal designation FB-EK-III is used. For a single SIPOC that’s not a big deal, but if you want to understand several, it is a problem. It is of course also good for understanding to see which business objects are used and how they relate to each other. Indirectly they are captured through the Input and Output columns. An explicit list is usually missing, though. And here too, consistent naming helps. It is equally helpful to see in which SIPOCs the suppliers and customers appear. If you can see at a glance that a customer appears in 5 SIPOCs, that gives you good insight into how the processes are connected. These problems cannot be solved by storing SIPOCs somewhere. That requires structured capture.
Transparency
What can help here? Unfortunately, there is no single solution. Teams will always change. Projects and information will continue to be archived. Someone will always insist that the important information disappears into an archive. People will keep doing duplicate work because they don’t know that someone before them already captured the data. What you can do, however, is try to capture the information outside of this cycle. For one, in a separate tool. Of course a wiki is nice, an Excel is easy to share, a SharePoint page is easy to share.
A specialized piece of software, a tool you can run under its own name and URL. With the SIPOCs captured centrally and (hopefully) accessible and findable for everyone. That is what’s needed. Not a nested wiki. The standard approach is to buy such a tool. In the end you get it as part of a possibly far too extensive and complex EA suite. And then fear the lock-in again. Or the dreaded license hurdle: nice tool, but you need an architect license to access it. And you’re back at the access problem mentioned at the start.
And nobody knows whether the license will be renewed after 3 years. An alternative: the company develops something of its own, or uses open source software.
Make is the new buy
The possibilities we have today thanks to AI open up new options. A specialized piece of software for a narrowly defined purpose 🔗 can be built in a short time and is tailored to your own requirements. Since you can hand your company’s QA guidelines to the AI 🔗, it is also ensured that the tool is not only runnable but also maintainable.
Thanks to AI, every company or reasonably capable (enterprise) architect 🔗 can have it built themselves 🔗. Such a tool can then do everything you miss in other solutions. Export the data of a SIPOC as text, as Markdown. Have information captured manually by people, or automatically by other tools. Something like this can help break the vicious circle. Don’t create anew what already exists. Reuse and improve what is there. On top of that, thanks to AI, such a tool is no longer something you have to buy through a complex procurement process or get as part of a possibly far too extensive and complex EA suite.
SIPOC Management App
For example, the SIPOC Management App 🔗 that I developed with Claude. You can simply use this app, or use it as a basis for inspiration. What matters is that you take a few of the app’s features into account:
- People can create a SIPOC manually. Drag & drop of elements as well as connections from input/output to supplier/customer are possible.
- Suppliers, customers and business objects can be created centrally and reused in a SIPOC.
- Markdown support. Export to (or import from) Markdown and have the information available as plain text. No proprietary format, and editable with any text editor.
- An overview of which SIPOCs use a given business object, for example.
- Comments are possible.
- Easy to use: browser, AI, local, central
- An AI can manage a SIPOC through the integrated MCP server.
The last point in particular offers tremendous added value. An analysis by the AI can be very interesting. You first capture the process understanding with the selected people. Then you let the AI go through the process documents and create the SIPOC from them. Or you let the AI analyze an existing application and create the SIPOCs it finds. In theory, the SIPOCs should match in all cases. Maybe not 100%, but not just very roughly either. And if the SIPOC generated from the application in productive use doesn’t match the documentation or the people’s understanding at all, then you have a problem. Because what is executed is not the documentation or the wish formulated in it. It is what is implemented. If a supplier or customer is missing here, if a business object was not recognized by the AI at all: why? Answering that question can trigger more process optimization than the management’s last projects on this topic.
Information
You can run the app locally or in Docker. The SIPOCs are stored in a DB in the backend. The frontend is available through a browser. After starting, open the app here: http://localhost:4200 🔗