When you introduce a workflow, business processes become clearly visualized as a workflow diagram. The diagram and settings document exactly who does what and in what order, thereby capturing the individual expertise of the people responsible in a structured system.
This approach is proven to be effective. Even if an employee is transferred, cases continue to flow without stopping because the system knows what needs to be done next. The issue of tasks depending on specific individuals is resolved through workflow implementation.
However, after operating an app for a few years a common situation arises where an update to the app is requested, but the person who created it is no longer around so nobody knows if it’s safe to modify it.
The workflow diagram exists. All settings are visible. Yet, it cannot be modified. So what’s the problem?
What the Workflow Diagram Doesn’t Tell You
For example, imagine a Purchase Request app with a branch set up like this:
- If the amount is less than 100,000 JPY, send to Manager Approval
- If the amount is 100,000 JPY or more, send to Director Approval
By looking at the settings, what will happen is perfectly clear. There is no ambiguity.
However, why the threshold is set at 100,000 JPY is written nowhere.
- Is it specified that way in internal company regulations?
- Was it simply decided by the manager in charge at the time?
- Was the threshold lowered to prevent a recurrence of a past issue?
- Was it aligned with the threshold of another app?
A successor does not know this. Because they don’t know, they cannot make a judgment. Even if asked whether it is acceptable to raise the amount to 200,000 JPY, they cannot give an answer. Uncertain of what might break if they change it, everyone settles on the conclusion to leave it untouched.
Normal Operation Hiding the Problem
Even in this state, the app continues to run normally.
Every day, cases are started, approved, and completed. Because nobody appears to have any trouble, it is not recognized as a problem.
The issue only surfaces the moment a change becomes necessary—whether due to revised regulations, an organizational restructuring, or new requirements from a business partner. Only then do you realize that the application cannot be modified by anyone; it has become an indispensable system, carrying years of operational history that cannot simply be halted.
The Same Problem in Software Development
“The code exists, but there are no specifications”. In the software development world, this story has been played out repeatedly for a long time.
Code completely describes what happens (what) and how to do it (how). However, it does not describe why it was done that way (why). And during maintenance, what is needed is almost always the “why”.
So why do specifications get lost? It’s not because they weren’t written. In many cases, they were written at the start. The problem is that they were placed somewhere else.
Documentation stored elsewhere does not get updated when the implementation changes. Eventually, discrepancies arise between the documentation and the actual implementation, and the documentation begins to contain inaccuracies. Inaccurate documentation stops being read, and unread documentation stops being updated. Once this happens, the document is useless even if it exists.
A widely adopted solution in software development is to keep documentation right next to the code. Inline code comments, documentation managed alongside the code repository, and change logs left with every revision. When placed where the person making changes will definitely see them, discrepancies are noticed immediately.
The situation is identical for workflow apps. If you store design intent in a spreadsheet or a design doc in a shared folder, the exact same problem will happen.
Why This Happens Easily with Workflow Apps
Furthermore, the ability to build apps without specialized technical knowledge actually exacerbates this issue.
The person building the app is not a developer. Having business department staff build their own apps provides immense value. At the same time, that person has not received professional training on recording design intent. They simply don’t have the habit.
Apps can be built by a single person. In a development team, you are always required to explain why you built it a certain way during code reviews. Being asked for explanations creates a motivation to document things. Workflow apps are completed individually, so that opportunity never arises. The period during which design intent exists solely in one person’s mind continues uninterrupted for years.
The frequency of changes is low. If it were code rewritten daily, you would still remember the intent from six months ago. Workflow apps, once created, are often left untouched for years. When opened after six months, even the original creator cannot recall why they designed it a certain way.
What Was Solved vs. What Remained
To summarize, introducing workflows removed the reliance on specific individuals for execution – shifting that responsibility away from numerous staff members. In return, however, it concentrated design dependency onto a single app administrator.
The former is a far greater achievement. But if the latter is left unaddressed, the lifespan of the app becomes dictated by the tenure of that app administrator.
Fortunately, addressing this requires no new tools. Questetra BPM Suite is already equipped with fields for documenting design intent. The fields are there—what hasn’t been established is what to write and where.
Next Time
In the next article, we will cover how to build that consensus: how to distinguish the usage of app names, step names, item names, and notes, as well as notes vs. version notes—organized along two axes.
