How Should To-Be Principles for Business Processes Be Set? How to Write Them, Where They Come From, and Methods for Redesign

What happens between the current state and the target state

Business process work is usually described as a sequence: model the current process (as-is), model the target process (to-be), and plan how to close the gap. Yet how to get from the current process to the target process has rarely been spelled out, even in method books. Reijers and Limam Mansar (2005) point to this gap by quoting Sharp and McDermott: how to get from the as-is to the to-be is not explained, so during the break the famous ATAMO procedure is invoked, “And Then, A Miracle occurs.” The same paper counts that Hammer and Champy’s book, which popularized reengineering, devotes only 14 of more than 250 pages to designing the process itself, 11 of them to a case.

A clue for filling the gap already appears in a reengineering classic. Hammer (1990) described Ford’s accounts payable. Ford had operated under the rule “We pay when we receive the invoice.” No one had ever written it down, but the accounts payable process was organized around it. Ford replaced it with “We pay when we receive the goods.” Purchasing now enters each order into an online database, the receiving clerk checks arriving goods against it, and when they match, the payment is prepared automatically. The number of items to be matched fell from 14 to three, and according to Hammer, head count fell by 75%.

What practitioners call a to-be principle corresponds to “We pay when we receive the goods.” It is a rule, stated in words before any individual flow chart, that the target process must follow. What must such a rule contain to count as a principle, where does it come from, and how is it turned into concrete designs? This note answers those three questions from the academic literature and a standard.

Scope and method

The question is what a to-be principle is in business process work, how to set one, and what systematic methods and best practices exist. The active mode is academic, covering peer-reviewed articles, scholarly books, and conference papers with a confirmed peer-reviewed version. On the industry side, only the TOGAF Standard for enterprise architecture was used as a supplement. A source-researcher (profile: scholarly) returned 40 candidates, and a paper-screening agent confirmed their bibliographic details. From these, 16 sources that address the questions directly were selected, favoring those whose full text could be obtained. For the two without full text (Kettinger et al. 1997; Grover et al. 1995), the note uses only what Gross et al. (2019) report from the former and only the abstract of the latter, and says so in the text. The retrieval routes for every reference are recorded in source/review/to-be-process-principles/fulltext-manifest.json, and the supporting passage for each claim in the corpus’s verification log.

Four things are called “principles”

Within this search, “to-be principle” did not appear as an established term in the peer-reviewed literature. The nearest concepts fall into four groups, each in a different line of research.

• Architecture principles: enduring rules that guide future decisions about the target state of an organization’s information systems and business. Treated by the TOGAF Standard and by enterprise architecture research (Haki & Legner 2021).
• Design principles: prescriptive knowledge stating how an artifact should be built to achieve a given aim. Treated by design science research in information systems (Gregor et al. 2020).
• Redesign best practices: rules of thumb about how changing an existing process affects its performance, such as “eliminate unnecessary tasks.” Treated by business process redesign research (Reijers & Limam Mansar 2005).
• Principles of BPM: principles for running process management itself. The ten principles of vom Brocke et al. (2014) belong here.

The last group governs how an improvement initiative is run, not what the target process contains. The ten principles of vom Brocke et al. (2014) are context awareness, continuity, enablement, holism, institutionalization, involvement, joint understanding, purpose, simplicity, and technology appropriation, all of them norms for a BPM initiative. Mistaking them for to-be principles puts commitments about how to proceed, such as “involve stakeholders,” into the list of rules for the business.

The other three groups light up different sides of a to-be principle. Architecture principles show how to write and govern a principle. Design principles offer a schema for stating what a principle aims at, for whom, and through what mechanism. Redesign best practices supply the options at hand when a principle is turned into concrete process designs.

What must a principle contain?

The TOGAF Standard recommends writing each principle with four parts: Name, Statement, Rationale, and Implications. The name should capture the essence of the rule, be easy to remember, and mention no specific technology platform. The statement should avoid ambiguous words such as “support,” “consider,” and “open.” The rationale should give the business benefits of following the principle, its relation to other principles, and which principle takes precedence when they conflict. The implications should state the resources, costs, and tasks the business and IT need to follow the principle, so that readers can answer “How does this affect me?”

TOGAF judges a set of principles by five criteria. It should be understandable (quickly grasped throughout the organization, with a clear intent that minimizes violations), robust (precise enough to support consistent decisions even in controversial situations), complete, consistent (strict adherence to one principle does not violate the spirit of another), and stable (enduring, but with a process for adding, removing, or amending principles). It notes that many organizations limit the number to between 10 and 20. TOGAF also observes that a common first reaction to a principle is “this is obvious and does not need to be documented,” and recommends writing it anyway, since seeming self-evident is not the same as being followed.

Gregor et al. (2020) compared how design principles for information systems are formulated and combined them into one schema. Its backbone is a single sentence: “For Implementer I to achieve or allow Aim A for User U in Context C, employ Mechanisms M involving Enactors E, because of Rationale R.” The implementer applies the abstract principle to a concrete setting, the user is the one whose aim is to be achieved, and the enactor performs actions within the mechanism. The schema makes the writer state whose aim the principle serves and whose actions make it work. Compared with TOGAF’s four parts, Gregor et al. add context and the roles of people, while TOGAF adds implications (costs and tasks). Taken together, a to-be principle card would carry seven items: name, statement, aim and beneficiaries, context of application, mechanism and the people who act, rationale and precedence, and implications. This combination is this note’s synthesis; neither source tested it.

Is a principle that fits the format therefore a principle? Haki and Legner (2021) ontologically analyzed 152 principles in the enterprise architecture literature and identified three kinds of things that are not principles (nonprinciples).

• Goals or outcomes phrased as principles: reasons for adopting principles (the expected results), which do not guide design decisions.
• Practices: guidance on how to run architecture work, which does not guide design decisions.
• Low-level governance means: standards (rules and courses of action for implementing principles) and guidelines (methodologies for implementation), which do not share the enduring nature principles should have.

After removing these and merging duplicates, 45 principles remained, which they grouped into nine meta-principles: integration, data consistency, standardization, compliance, reusability, modularity, usability, portability, and centralization. Haki and Legner argue that principles should not prescribe specific technologies, methods, or practices, but only provide the basis for purposeful design decisions. Applied to the Ford case, “cut accounts payable head count by 75%” is a goal, not a principle. “We pay when we receive the goods” gives direction to every design decision in ordering, receiving, and paying, and so it is a principle.

Where do principles come from?

Put purpose and performance goals first

The starting point is the organization’s purpose. TOGAF requires each principle to be clearly traceable to business objectives and key architecture drivers, and lists what influences principles: the enterprise’s mission and plans, its strategic initiatives, external constraints (market factors, customer expectations, legislation), current systems and technology, and emerging industry trends. The principle of purpose in vom Brocke et al. (2014) likewise holds that BPM should contribute to strategic value creation, and that pursuing it because it seems to be in vogue is likely to lead to failure. Rosemann (2006a) put the lack of strategic connections first among the pitfalls of process modeling.

The order of stages in process change methods also puts purpose first. The stage-activity framework of Kettinger et al. (1997) has six stages: envision, initiate, diagnose, redesign, reconstruct, and evaluate. Gross et al. (2019) mapped the activities of 98 methods onto it and extended it; the envision stage includes identifying key business goals and aligning process change with corporate strategy, and the initiate stage includes determining external customer requirements, setting performance goals, and envisioning the new process. Documenting and analyzing the existing process comes later, in the diagnose stage. In the same analysis, Gross et al. report that methods labeled “redesign” offer the fewest strategic activities in the envision stage, and only 36% of them offer activities for evaluating the redesigned process. Of the 98 methods, 49 were labeled reengineering, 33 improvement, 11 redesign, 3 innovation, and 2 optimization.

Performance goals can be made concrete along four axes. Reijers and Limam Mansar (2005) used Brand and van der Kolk’s devil’s quadrangle as their evaluation framework. Its four dimensions are time, cost, quality, and flexibility, and improving one often weakens another. Adding reconciliation tasks, for example, may improve quality but slow delivery. Reijers et al. argue that an organization’s key performance indicators and the performance targets of a redesign should be formulated as more precise applications of these four dimensions. The rationale and precedence of a principle (the rationale in TOGAF’s four parts) is where the choice between such trade-offs is recorded.

Study the current process to learn its purpose

Analyzing the current process has a role, but it should not be the only source of designs. Hammer (1990) wrote that a reengineering team must scrutinize the existing process until it really understands what the process is trying to accomplish. The point, however, is not to learn where a form travels but why the form exists in the first place. The team keeps asking “Why?” and “What if?” to separate what is fundamental from what is superficial.

Rosemann (2006a, 2006b) collected pitfalls from focus groups and interviews on large modeling projects, several of which concern the current process. One is lack of imagination: proceeding only through “understand the current process, find ways to improve it, plan action” concentrates the project on overcoming problems rather than reaching new strategic goals. Rosemann’s conclusion is that a good understanding of the existing process is important, but it should never be the only source of ideas for the new process. Another is getting lost in detail: the more detailed a model, the longer it takes to design, review, and maintain, and the sooner it becomes outdated. Unless the process is to be automated, a focus on the 80 percent case, in both probability and resource consumption, is often sufficient, and the level of detail should be set in light of the objectives. Rosemann also warns modelers to capture as-is models rather than “as-if” models when interviewing business representatives. For staffing, he names three kinds of people to bring in: those who know the current process, those who provide direction (objective, timeframe, constraints, how success is measured), and those who create ideas.

On starting from the existing process versus a clean sheet, Reijers and Limam Mansar (2005) write that the literature debates the choice, but in practice taking the existing process as a starting point is the most common way to develop a new one. Grisold et al. (2022) frame the distinction as exploitative and explorative BPM. Exploitative BPM follows an inside-out logic, improving or reengineering existing processes; explorative BPM follows an outside-in logic, creating processes with new value propositions from business and technology opportunities. Their Five Diamond Method consists of one overarching diamond and four diamonds for purpose, business, technology, and integration, alternating divergent and convergent thinking to bring opportunities into processes. It was evaluated in a pilot study and two real-world applications.

How are to-be designs generated from principles?

Composing a method from six decision areas

Vanwersch et al. (2016) systematically reviewed 61 studies up to 2011 on methods for moving from as-is insights to to-be alternatives. They identified six methodological decision areas: aim, actors, input, output, technique, and tool. Input was the most frequently addressed (93% of the studies) and tool the least (51%). Techniques fall into three categories.

• Unstructured techniques: creativity techniques such as brainstorming, which give neither a procedure from as-is insights to to-be ideas nor guidance on the kinds of alternatives to consider.
• Semi-structured techniques: give a work procedure from as-is insights to to-be ideas, but no guidance on the kinds of alternatives.
• Structured techniques: give both the procedure and guidance on the kinds of alternatives. Rule-based and repository-based techniques are examples.

Vanwersch et al. also note that for rule-based techniques, information systems researchers look at the “BPR best practices” literature while management science researchers look at TRIZ inventive principles, and the two rarely meet.

Redesign best practices

The leading structured technique is the set of 29 best practices compiled by Reijers and Limam Mansar (2005). They grouped them into seven classes (customers, business process operation, business process behavior, organization, information, technology, and external environment) and qualitatively evaluated each one’s effect on time, cost, quality, and flexibility. Reijers et al. acknowledge that many best practices lack adequate quantitative support. They also note that applying several at once can partly neutralize their effects, citing work by Seidmann and Sundararajan that used mathematical models to show that the popular combination of empowerment and triage is sub-optimal in many cases.

Limam Mansar and Reijers (2007) surveyed experienced redesign practitioners in the UK and the Netherlands in 2003 and 2004 and confirmed that a “top ten” of best practices is widely used. The shares who reported using them were 94% for task elimination, 94% for integral technology (lifting physical constraints with new technology), 89% for task composition, and 88% each for parallelism, specialist-generalist, and resequencing. Integration with the processes of customers or suppliers, empowerment, and numerical involvement (minimizing the departments and people involved) were at 76%, and order assignment (letting one worker perform as many steps as possible for a single order) at 53%. The practitioners, however, rated the effects more positively than the authors had estimated, and the authors list the design of the survey instrument as a possible cause of the gap.

Hammer’s (1990) seven principles are at the root of this line. Organize around outcomes, not tasks; have those who use the output of the process perform the process; subsume information-processing work into the real work that produces the information; treat geographically dispersed resources as though they were centralized; link parallel activities instead of integrating their results; put the decision point where the work is performed and build control into the process; and capture information once and at the source. Hammer offered them as principles that companies had already discovered, to keep reengineering from being haphazard.

Widening the range with a design space

Gross et al. (2021) start from the problem that redesign methods give limited support for actually creating to-be processes. They built the Business Process Design Space (BPD-Space), gathering what can be changed in a process into 19 design dimensions grouped in six layers: customer, product/service, business process, organization, information, and technology. Each dimension comes with possible characteristics, guiding questions, and real-world examples. It was built and evaluated through a literature review, semi-structured interviews with process experts, and three real-world applications. Where best practices offer moves for how to change a process, the design space maps where it can be changed.

Failures that occur even with principles

Principles and designs do not by themselves change the business. Rosemann (2006b) writes that a wave of satisfaction follows the creation of a to-be model, but a model remains a model and only implementation matters. The same paper names to-be models centered solely on new IT as a pitfall, since that attitude can become an excuse not to look for non-IT solutions and to change nothing until the new system arrives. Overrating best practices is another pitfall: a successful company’s processes are not necessarily why it is successful, and reference models tend to lack case references and context factors.

According to its abstract, Grover et al. (1995) had participants from 105 organizations rate the severity of 64 reengineering implementation problems, and concluded that change management is central to success. Resolving problems of technological competence and planning was necessary but not sufficient. The principle of simplicity in vom Brocke et al. (2014) also warns against over-engineering BPM initiatives.

Where do principles sit when AI is added?

Dumas et al. (2023), in a manifesto setting out research challenges for AI-augmented business process management systems (ABPMSs), introduced the concept of a frame. The system’s lifecycle starts when an agent equips it with initial goals and constraints. The constraints can include predefined procedures, norms, regulatory constraints, commonsense rules, and best practices, and are likely to refer to key performance indicators. The system acts autonomously within the frame and may reframe itself when it acquires new knowledge. Dumas et al. call it meta-framing when designers determine which parts of the frame the system may modify and which can only be changed by human instruction. This is a vision paper setting out research challenges, not an empirical test.

To-be principles are strong candidates for the content of such a frame. In that case, a principle’s rationale and precedence would guide the system when it chooses between competing goals, and deciding which principles remain under human control would be a meta-framing decision. This mapping is this note’s interpretation; Dumas et al. do not say it in terms of principles.

Work has also begun on revising process models through conversation with large language models. Klievtsova et al. (2026) proposed an approach that takes a user’s natural-language change request, identifies change patterns from the literature, rephrases the request to match a pattern’s meaning, and then applies it to the model. In their evaluation, some patterns were hard for both the model and users to understand, and clear change descriptions from users were essential. They recommend a hybrid approach that applies well-handled patterns directly and asks follow-up questions for the rest.

As a procedure

Ordering the findings above yields eight steps for setting to-be principles. The order and combination of steps are this note’s synthesis, and no study in this search tested the procedure as a whole.

What has not yet been established

Within this search, no study compared whether writing principles itself improves to-be designs. TOGAF’s four parts and five criteria are recommendations of a standard, and Haki and Legner’s case studies trace the path from principles to outcomes in three companies.

Evidence on the effects of redesign best practices is also thin. Reijers et al. themselves acknowledge the lack of quantitative support, the usage survey dates from 2003 and 2004, and the effects rest on respondents’ ratings.

Nor did the search find guidance on how deeply to study the current process beyond Rosemann’s “80 percent case.”

On the AI side, the available sources are visions and method proposals, and none yet shows how to-be designs change when principles are given as a frame. If Ford’s “We pay when we receive the goods” were handed to an AI system, who holds the authority to rewrite that rule has so far received a name, meta-framing, and little more.

Related notes

• An Academic Map of Methods for Reframing Problems: From Abduction-2 to Problem Structuring: Hammer’s replacement of a rule can be read as an instance of reframing a problem.
• Settling a Business App's UI on One Design: What Narrows the Options, How to Compare Them, and Who Decides: the materials and steps for settling on one UI for a business application, which come after the to-be process is decided.
• Which standard can design and new-business work actually sit on?: which standards cover the stages of design and new business work.

References

All accessed 2026-09-30.

How to write principles

• The Open Group (2022). The TOGAF Standard, 10th Edition: ADM Techniques, Chapter 2 “Architecture Principles”. https://pubs.opengroup.org/togaf-standard/adm-techniques/chap02.html (viewed via the Wayback Machine capture of 2024-09-11)
• Haki, K., & Legner, C. (2021). The Mechanics of Enterprise Architecture Principles. Journal of the Association for Information Systems, 22(5), 1334–1375. https://doi.org/10.17705/1jais.00696 (author version https://api.unil.ch/iris/server/api/core/bitstreams/66889670-2b96-4f9f-a1ff-d7a260316b23/content )
• Gregor, S., Chandra Kruse, L., & Seidel, S. (2020). Research Perspectives: The Anatomy of a Design Principle. Journal of the Association for Information Systems, 21(6), 1622–1652. https://doi.org/10.17705/1jais.00649 (author version https://www.uni-kassel.de/fb07/index.php?eID=dumpFile&t=f&f=4900&token=8829a7e90fbfde2645262e72c8fb56b6a0863e54 )

Where principles come from and the role of the current process

• Hammer, M. (1990). Reengineering Work: Don’t Automate, Obliterate. Harvard Business Review, July–August 1990. https://hbr.org/1990/07/reengineering-work-dont-automate-obliterate (full text https://folk.idi.ntnu.no/thomasos/paper/hammer_reengineering.pdf )
• vom Brocke, J., Schmiedel, T., Recker, J., Trkman, P., Mertens, W., & Viaene, S. (2014). Ten Principles of Good Business Process Management. Business Process Management Journal, 20(4), 530–548. https://doi.org/10.1108/BPMJ-06-2013-0074 (author version https://lirias.kuleuven.be/retrieve/c62d2d2a-4763-4e24-be1a-fe9d58425245 )
• Kettinger, W. J., Teng, J. T. C., & Guha, S. (1997). Business Process Change: A Study of Methodologies, Techniques, and Tools. MIS Quarterly, 21(1), 55–78. https://doi.org/10.2307/249742
• Gross, S., Malinova, M., & Mendling, J. (2019). Navigating Through the Maze of Business Process Change Methods. Proceedings of the 52nd Hawaii International Conference on System Sciences (HICSS), 6270–6279. https://doi.org/10.24251/HICSS.2019.754 (full text https://hdl.handle.net/10125/60061 )
• Rosemann, M. (2006a). Potential Pitfalls of Process Modeling: Part A. Business Process Management Journal, 12(2), 249–254. https://doi.org/10.1108/14637150610657567
• Rosemann, M. (2006b). Potential Pitfalls of Process Modeling: Part B. Business Process Management Journal, 12(3), 377–384. https://doi.org/10.1108/14637150610668024 (full text of parts A and B https://scholar.archive.org/work/zjgbw4zje5cz7dzt4di67lnsku/access/wayback/http://bpm-training.com/wp-content/uploads/2010/04/Rosemann-2006.-Potential-Pitfalls-of-Process-Modeling.pdf )
• Grisold, T., Groß, S., Stelzl, K., vom Brocke, J., Mendling, J., Röglinger, M., & Rosemann, M. (2022). The Five Diamond Method for Explorative Business Process Management. Business & Information Systems Engineering, 64(2), 149–166. https://doi.org/10.1007/s12599-021-00703-1 (full text https://pmc.ncbi.nlm.nih.gov/articles/PMC8185488/ )

Redesign methods and best practices

• Reijers, H. A., & Limam Mansar, S. (2005). Best Practices in Business Process Redesign: An Overview and Qualitative Evaluation of Successful Redesign Heuristics. Omega, 33(4), 283–306. https://doi.org/10.1016/j.omega.2004.04.012 (author version https://hreijers.win.tue.nl/H.A.%20Reijers%20Bestanden/BPRpractices.pdf )
• Limam Mansar, S., & Reijers, H. A. (2007). Best Practices in Business Process Redesign: Use and Impact. Business Process Management Journal, 13(2), 193–213. https://doi.org/10.1108/14637150710740455 (author version https://hreijers.win.tue.nl/H.A.%20Reijers%20Bestanden/impact.PDF )
• Vanwersch, R. J. B., Shahzad, K., Vanderfeesten, I., Vanhaecht, K., Grefen, P., Pintelon, L., Mendling, J., van Merode, G. G., & Reijers, H. A. (2016). A Critical Evaluation and Framework of Business Process Improvement Methods. Business & Information Systems Engineering, 58(1), 43–53. https://doi.org/10.1007/s12599-015-0417-x (full text https://pure.tue.nl/ws/files/15733410/art_3A10.1007_2Fs12599_015_0417_x.pdf )
• Gross, S., Stelzl, K., Grisold, T., Mendling, J., Röglinger, M., & vom Brocke, J. (2021). The Business Process Design Space for Exploring Process Redesign Alternatives. Business Process Management Journal, 27(8), 25–56. https://doi.org/10.1108/BPMJ-03-2020-0116 (full text https://www.fim-rc.de/Paperbibliothek/Veroeffentlicht/1073/wi-1073.pdf )

Implementation failures

• Grover, V., Jeong, S. R., Kettinger, W. J., & Teng, J. T. C. (1995). The Implementation of Business Process Reengineering. Journal of Management Information Systems, 12(1), 109–144. https://doi.org/10.1080/07421222.1995.11518072

AI

• Dumas, M., Fournier, F., Limonad, L., Marrella, A., Montali, M., Rehse, J.-R., Accorsi, R., Calvanese, D., De Giacomo, G., Fahland, D., Gal, A., La Rosa, M., Völzer, H., & Weber, I. (2023). AI-augmented Business Process Management Systems: A Research Manifesto. ACM Transactions on Management Information Systems, 14(1), Article 11. https://doi.org/10.1145/3576047 (author version https://arxiv.org/abs/2201.12855 )
• Klievtsova, N., Kampik, T., Mangler, J., & Rinderle-Ma, S. (2026). Conversational Process Model Redesign. International Journal of Cooperative Information Systems, 35(1), 2650004. https://doi.org/10.1142/S0218843026500048 (author version https://arxiv.org/abs/2505.05453 )