A Process Map In ASCII Is a Thing

Intro

It started in 2003, I was implementing Axapta or Microsoft Dynamics AX a bit later, and we were modeling the processes in eEPC notation using ARIS Toolset, which was expensive, about 10k USD per user. And it was great for managing changes and documenting the logic, the document flow, although I had some suspicions when we printed the maps on A0 (otherwise they were unreadable) or had 5 levels of decomposition. Could it be simpler – that was the question, but it did the job. About 5 years later I moved on to management consulting, these guys were more cost-aware, so we used eEPC in ARIS Express or flow charts in MS Visio with different notations and yes, in any case it was simpler and still got the job done. In my last effort to model something I chose BPMN 2.0 and Camunda Modeler, because it was free and it was real process modeling with a strict and compact notation.

In Germany companies try to comply with ISO 9001, which says that business processes should be documented, and the simplest form of process flow is used with almost no branches, and it somewhat works for small companies, although I never saw anyone actually using it as a reference. And two times we started ERP implementation it turned out that these process maps hide some important details, to say the least.

Anyway, I had a practical task to write an instruction for us and for a service provider, how we work together. I was discussing some options with an AI chatbot, and the chatbot drew what are called ASCII- or plain-text process maps. Actually it was not the first time, but that time it hit me: I could use it in the document. And yes, I use it a lot myself, I also used it to explain what is going on in conversations with different parties involved and my point is that no one asked a single question – it was that level of simplicity.

The map

Just to illustrate what I mean let's take a look at an example for a "Purchase-to-Pay" process:

Requisition Creation [Requester] (Purchase Requisition)
  |
PR Approval [Approver] (Approved Purchase Requisition)
  |
PO Generation [Procurement Specialist] (Purchase Order)
  |
PO Issued to Vendor [Procurement Specialist] (Purchase Order)
  |
Goods / Service Receipt [Warehouse] (Goods Receipt Note)
  +-> Issues Found [Warehouse] (Return / Dispute Note)
  +-> Accepted
        |
      Invoice Receipt & Matching [Accounting] (Supplier Invoice)
        +-> Mismatch / Hold [Buyer] (Exception Report)
        +-> Verified (3-Way Match Record)
              |
            Payment Processing [Finance] (Payment Advice)

TL;DR: use the following with any chatbot along with the description to get a similar result:

Use [Roles], (Docs), and +-> for branches

The good

I'd name one critical advantage, the accessibility, but it's not that simple, so let's take a look at different perspectives:

Now let's take a look at the drawbacks.

The bad

I learned the hard way why the roles, interfaces and documents are important – in fact, a document/information flow can be way more important than functions and branching logic. Having this discipline in mind using ASCII-based process maps is easy, but this may not be the case:

Conclusion

There's a surprisingly wide range of online or offline tools to make ASCII process maps, although I would probably write something different. I liked the freedom from any tool I got. It's the same as any text-based format, you can edit it as long as you have a text editor. Some text editors, like Neovim, can make editing these process maps especially convenient, but we will not dig into this rabbit hole. If you are able to set a task for an AI chatbot, it can be very fast as well, and I personally have no problem with showing this process map to a company management at any level. But yes, these maps are not fancy.