--- title: "Quick Tips: Why Simplifying Is Harder Than Adding" description: "Why processes only grow — and five ways to remove steps without gambling: check each reason, measure real paths, split standard from exception." image: https://blog.noreja.com/hubfs/blog/featured-images/2026-10-20-quick-tips-simplifying-processes.png --- [Skip to content](https://blog.noreja.com/en/why-simplifying-is-harder-than-adding#main-content) ![](https://blog.noreja.com/hs-fs/hubfs/blog/featured-images/2026-10-20-quick-tips-simplifying-processes.png?width=1820&height=1024&name=2026-10-20-quick-tips-simplifying-processes.png) Quick Tips GenAI BPM # Quick Tips: Why Simplifying Is Harder Than Adding ![Lukas Pfahlsberger](https://app.hubspot.com/settings/avatar/6b6ceb34347ba3ac2667e67af4e9f63f) Lukas Pfahlsberger October 20, 2026 Ask a team to improve a process and you will get suggestions: a new field to capture the missing information, an extra check before handover, a status update so everyone knows where things stand, a short weekly sync. All sensible. All additive. Almost nobody proposes removing something — and yet removal is usually where the improvement is. This is not a failure of imagination. Adding is safe: the cost is small, distributed and in the future, while the benefit is specific and immediate. Removing is exposed: the benefit is diffuse, and if anything goes wrong afterwards, someone made a decision that can be pointed at. So processes accumulate, each addition individually justified, until the whole is slower than anyone intended and nobody can say which part to take out. This edition of Quick Tips is about five practical ways to simplify a process without gambling. ## Why Simplification Attempts Usually Stall Consider an insurance team handling change requests for existing policies. Over six years the process grew from four steps to eleven. Each addition had a reason: a mis-priced case led to a second calculation check, a complaint led to a customer confirmation step, an audit finding led to a documentation requirement, a system migration left a manual reconciliation that was supposed to be temporary. The team knows the process is too heavy. Two attempts to streamline it produced a workshop, a list of candidates and no change. The attempts failed for a predictable reason. Nobody could prove a step was unnecessary, and in the absence of proof the safe answer is always "let's keep it for now". The discussion happens at the level of opinions — "I think that check catches things" against "I think it doesn't" — and opinion never beats caution. Meanwhile the step nobody defends stays too, because removing it requires someone to own that decision. What breaks the deadlock is evidence and a defined boundary: knowing what each step actually does, and knowing which cases it applies to. The five tips below are about producing both cheaply. ## Tip 1: Make Every Improvement Name What It Removes The simplest structural fix costs nothing: require every process change proposal to name what it takes out. Not as a rigid one-in-one-out rule, but as a question that must be answered — if we add this check, what does it replace, and if the answer is "nothing", why is the process net heavier now? This changes the conversation at the moment of addition, which is far cheaper than a cleanup two years later. It also surfaces something useful: often the new step is genuinely intended to replace an old one, but nobody says so, and both end up running. The old manual check that the new system control makes redundant does not disappear on its own — someone has to notice, and the question forces the noticing. Ask yourself: when your team last added a step to a process, was anything removed at the same time — and if not, was that a decision or an oversight? ## Tip 2: Ask Every Step for Its Reason, and Check Whether It Still Exists Most heavy processes contain steps whose original justification has expired. The system that produced unreliable data was replaced. The supplier who used to send incomplete deliveries is no longer under contract. The regulation changed. The step remains, because nothing in the organisation triggers a review when the reason behind a control disappears. So do the archaeology deliberately. For each step, write one sentence: why does this exist, and what would happen if it did not? Two answers are informative. "Because a specific thing went wrong in a specific year" gives you something checkable — is that failure still possible today? And "because we have always done it that way" is not a reason at all; it marks a candidate for the next tip. Be precise about the regulatory ones rather than assuming. Teams routinely believe a step is legally required when the requirement is actually to produce an outcome, not to perform that particular step. It is worth asking someone who knows, because "compliance" is the single most effective way to make a step permanently unexaminable. Ask yourself: for the three heaviest steps in your core process, can someone state the reason they exist — and is that reason still true? ## Tip 3: Look at What People Actually Do, Not at the Documented Process The fastest source of simplification candidates is the process as it is really executed. In most organisations, experienced people already skip steps that add nothing — quietly, case by case, without documenting it. That informal behaviour is data: it tells you which parts of the process the people closest to the work consider unnecessary, and they are usually right. The timestamps in your systems make this visible. Process mining reconstructs the actual paths, showing how many variants exist, which steps are skipped in practice and how often, and whether the cases that skipped them turned out worse. Platforms such as [noreja](https://topai.tools/t/noreja) add the causal view, which matters here: the question is not only whether a step is skipped but whether skipping it produced more errors, rework or complaints. That is the closest thing to a controlled experiment you will get for free. When the data shows that a step is skipped in a third of cases with no measurable difference in outcome, you no longer need to argue about whether it is necessary — the organisation has already run the test. Making the informal simplification official is then a low-risk decision rather than a leap. Ask yourself: do you know which steps of your process are routinely skipped in practice, and whether those cases end differently? ## Tip 4: Split the Standard Case from the Exception A large share of process weight comes from one design mistake: building a single path that can handle every case. Every rare situation adds a field, a check, a decision point — and all of it is carried by the routine cases too, which are the overwhelming majority. The alternative is to define the standard case explicitly and let it run short. Everything outside it takes a longer path, deliberately. That is not more complexity but less: two clear paths beat one path with eleven conditional branches, both to execute and to explain. The precondition is a boundary specific enough that nobody has to interpret it, and a genuine willingness to let the exception be slower rather than dragging its requirements back into the standard path. We covered how to keep exceptions from eroding the standard path in the edition on [handling exceptions without breaking flow](https://blog.noreja.com/en/handling-exceptions-without-breaking-flow?hsLang=en). Ask yourself: what share of your cases are routine, and how much of the process they pass through exists only for the ones that are not? ## Tip 5: Protect the Simplification, or It Will Grow Back Simplification is not a project with an end; it is a state that decays. Six months after a successful cleanup, two new checks have appeared, both justified by real incidents, and the process is heavier than the day the project finished. Nothing in the organisation resists that, which is why cleanups have to be repeated every few years. Two lightweight mechanisms hold the line. First, give every new requirement an owner and a review date — not permanent status by default. A check introduced after an incident can be set to expire in twelve months unless someone can show it caught something. Second, track one number that makes weight visible: steps in the process, average handling time, or number of fields in the main form. A metric that goes up when complexity goes up turns an invisible drift into a noticeable one. The same asymmetry underlies the whole problem: adding is cheap and removing is exposed, which is exactly what makes approval chains grow too — the mechanics of pricing a control and shifting oversight from the case to the pattern are covered in the edition on [when approvals cost more than they protect](https://blog.noreja.com/en/when-approvals-cost-more-than-they-protect?hsLang=en). Whatever you simplify, budget for the fact that the pressure to re-complicate never stops. Ask yourself: which number in your organisation would go up if your processes became more complex — and does anyone look at it? ## Food for Thought If you had to remove two steps from your most important process tomorrow, which would you choose — and what evidence would you want first? Which steps in your process exist because of an incident that could no longer happen today? How many of your "regulatory" requirements have been verified with someone who actually knows the regulation? What does your team already skip when nobody is watching, and what does that tell you? Who is allowed to add a step to a process in your organisation, and who is allowed to remove one? ## Conclusion: Simplification Needs Evidence, Not Courage Processes grow because addition is cheap and removal is exposed, and no amount of good intention changes that asymmetry. What changes it is making removal defensible: force each addition to name what it replaces, check whether each step's original reason still exists, use the real execution data to see what people already skip and how those cases end, separate the standard case from the exception so routine work stops carrying rare requirements, and put a mechanism in place that makes creeping weight visible. Do that, and simplification stops being an act of courage that one person has to own — it becomes an ordinary decision supported by evidence. A concrete starting point: pick your core process, list its steps, and write one sentence per step on why it exists. The ones you cannot finish are your shortlist — and that exercise takes an hour, not a project. [Contact us](https://outlook.office365.com/book/Kennenlernen@noreja.com/?ismsaljsauthenabled=true) ## FAQ #### Why is simplifying a process harder than adding to it? Because the incentives are asymmetric. Adding a step has a small, distributed, future cost and a specific immediate benefit. Removing one has a diffuse benefit and a concrete personal risk if something goes wrong afterwards. Without evidence, caution always wins the argument — so processes accumulate even when everyone agrees they are too heavy. #### How do you find out which steps can be removed? Three sources. Write one sentence per step on why it exists and check whether that reason still holds. Look at what people already skip in practice and whether those cases end differently. And separate the standard case from the exception, which usually reveals how much of the process exists only for rare situations. #### How does process mining support simplification? It shows the process as executed rather than as documented: how many variants exist, which steps are skipped and how often, and whether skipped cases produced more rework or complaints. That converts a debate about whether a step is necessary into an observation about what already happens — the organisation has effectively run the test. #### Why do simplified processes become complex again? Because nothing resists the drift. Each new incident produces a justified addition, and no mechanism reviews whether earlier additions still earn their place. Giving new requirements an owner and a review date, and tracking one number that rises with complexity, keeps the drift visible instead of silent. #### Is one-in-one-out a good rule for process changes? As a rigid rule it can force artificial removals. As a question it is valuable: every proposal should state what it replaces, and if the answer is "nothing", that should be a conscious decision. It frequently reveals that a new step was meant to supersede an old one that nobody switched off. ## Share this post [mailto:https%3A%2F%2Fblog.noreja.com%2Fen%2Fwhy-simplifying-is-harder-than-adding](mailto:https%3A%2F%2Fblog.noreja.com%2Fen%2Fwhy-simplifying-is-harder-than-adding) ## Keep reading ### [![](https://blog.noreja.com/hs-fs/hubfs/blog/featured-images/2026-10-13-business-case-campaign-approvals.png?width=1820&height=1024&name=2026-10-13-business-case-campaign-approvals.png) GenAI BPM Process Intelligence Business Case: How to Cut Campaign Approval Time](https://blog.noreja.com/en/cut-campaign-approval-time?hsLang=en) ### [![](https://blog.noreja.com/hs-fs/hubfs/blog/featured-images/.png-Aug-28-2026-07-39-57-5591-AM.png?width=1820&height=1024&name=.png-Aug-28-2026-07-39-57-5591-AM.png) Two-For-One GenAI BPM Two for One: When Approvals Cost More Than They Protect](https://blog.noreja.com/en/when-approvals-cost-more-than-they-protect?hsLang=en) [![noreja\_logo\_white](https://blog.noreja.com/hs-fs/hubfs/noreja_logo_white.png?width=300&height=78&name=noreja_logo_white.png "noreja_logo_white")](https://blog.noreja.com/?hsLang=en) [Privacy Policy](https://noreja.com/en/privacy) · [Legal](https://noreja.com/en/imprint) · © 2026 Noreja. All rights reserved. ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Lukas Pfahlsberger", "url" : "https://blog.noreja.com/en/author/lukas-pfahlsberger" }, "dateModified" : "2026-10-20T07:00:00.559Z", "datePublished" : "2026-10-20T07:00:00.000Z", "headline" : "Quick Tips: Why Simplifying Is Harder Than Adding", "image" : [ "https://blog.noreja.com/hubfs/blog/featured-images/2026-10-20-quick-tips-simplifying-processes.png" ], "mainEntityOfPage" : { "@id" : "https://blog.noreja.com/en/why-simplifying-is-harder-than-adding", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://blog.noreja.com/hubfs/noreja_logo_white-1.png" }, "name" : "Noreja Intelligecne GmbH" } } ```