Skip to main content

Author: Edmund Metera

BATimes_Mar15_2023

Your Next Process Model’s Degree of Abstraction

Written by Edmund Metera on . Posted in Articles.

Any process model is so much more than a flowchart. It is an abstraction of current or future real-world operations.

Process modeling is one of the core competencies of any capable business analyst. Both the International Institute of Business Analysis (IIBA) Business Analysis Standard[1], and the Project Management Institute (PMI) Guide to Business Analysis[2] call for certified business analysts to be capable of preparing and using process models.

Business analysts and process improvement analysts may prepare process models at key points of business process management, information technology, and regulatory compliance project methodologies. They may specify current or future functional, organizational, and information systems architectures, functional requirements, workflow designs, and even automated operations. What any process model needs to communicate will vary from one project to the next.  The highest quality process model examples provide clear, accurate process information of direct interest to their readers.

Informed business analysts know that one of the secrets to producing a high-quality process model is to establish a clear mission for each model. To be successful, you should mindfully establish the mission of your next process model within the business process management, information technology, or regulatory compliance project that the model will serve.  You will then tailor your elicitations of the model’s content and configuration to meet project needs. Part of your process model mission-setting elicitation agenda will include asking and answering this important question:

What is this model’s required degree of abstraction?[3]

There are three generally accepted degrees of abstraction to consider: conceptual, logical, and configuration.

 

A Conceptual Process Model  

A conceptual process model graphically presents the defining structure of what a process is.

Business analysts, project sponsors, project managers, domain subject matter experts, regulators, and other process stakeholders use conceptual process models, for the following purposes:

  • To make process governance and scoping decisions;
  • To gain agreement about and communicate the process’s defined scope and structure, unequivocally distinguishing that process from all others in their business;
  • To design enterprise architecture, to define technology solution architectures,
  • To be the sound foundation on which forthcoming detailed problem analysis or detailed process definition is scoped out or planned;
  • To support project management decisions (e.g. budgeting, scoping).
  • To further elicit and fit logical process details upon its sound contextual and structural foundation.

 

Some business analysts and systems analysts might interpret the term conceptual to mean “high level”. That would be an oversimplification and a mistake. To serve its purpose, a conceptual process model should unequivocally define the sound, stable structure of the process. Despite being the highest degree of abstraction, a high-quality conceptual process model is still precise.  It can clearly and graphically communicate all of these process-defining information:

  • The process’s name.
  • The process’s initiating event(s) that causes the process to be performed.
  • The process’s activities and their expected sequence of execution.
  • The process’s expected outcome(s).
  • The process’s customer(s).

 

Advertisement

 

A Logical Process Model

A logical process model elaborates contextually relevant details about how a process is required to operate, is designed to operate, or currently operates.

A high-quality logical process model could graphically, answer any of these types of how-elaborating questions:

  • The decomposition or summary of some of the process’s activities.
  • The rule-driven or decision-driven conditional work that may be performed.
  • The assigned responsibilities for performing the process’s activities.
  • The data or information required to be used and/or produced.
  • The causes of the process to be delayed or interrupted.
  • The processing errors that may occur while the process is executing, and how they will be resolved.
  • The process’s related performance or measurement data, and text-based operating procedures, documents, or other specifications.

There is a spectrum of uses for logical process models. Process owners and analysts use logical process models to determine what and where to measure an existing process’s performance or to design and communicate proposed process improvements. They also define requirements for, or the design of manual or automated procedures, or describe the design of workflows.

Competent business analysts and process analysts can anticipate, elicit and document a range of logical refinement types, using clear agendas and reusable modeling patterns[4]. They also know that no two logical process models need to communicate all of the same types of logical refinements. So they will consider the model’s mission within each project and tailor their modeling efforts to focus on eliciting and documenting the types of logical refinements that suit each model’s intended use within its project’s methodology.

 

A Process Configuration Model

A process configuration model communicates concrete implementation mechanisms such as software operations and user procedures or workflows.

A process configuration model is the lowest degree of abstraction. Business analysts and systems analysts typically prepare process configuration models in low-code and no-code software platforms. The platform consumes the process configuration model along with detailed process-related roles, security, forms, system interface, and data specifications to generate operating software, on top of an already well-rounded software product architecture. There is otherwise no or very little programmer intervention in translating the model into working software. When updates to requirements or defects emerge, the analyst revises the configuration model, and the platform regenerates and redeploys the software.

You must adopt and adhere exactly to a chosen low-code or no-code platform’s process modeling syntax. You can learn that by taking the training offered by the low-code or no-code platform’s vendor. Along with a process configuration model, you would specify, in detail:

  • System users, their assigned roles, and their responsibilities to perform the configured process flow.
  • The sequence of execution of configurable functional components, of an automated end-to-end workflow.
  • The configurable functional components involved in the process flow configuration. These are typically the user interfaces (e.g. forms, reports) system integrations (e.g. APIs), and the data attributes used in an automated process workflow.

Since process configuration models are precisely translated into operating software and business operations, any errors or omissions in the modeling become errors or omissions in the generated software and business operations.  It stands to reason that to be a successful business analyst or systems analyst in a low-code or no-code environment, you must design process configuration models based on sufficiently detailed logical requirements, that you have elicited and understood.

 

How to Choose Your Next Process Model’s Degree of Abstraction

Follow these guidelines to choose what the required degree of abstraction of your next process model will be:

Use conceptual process models to get agreement about and communicate what the process is. What is the scope? What causes it to be performed? What are the activities and their expected sequence? What is or are the expected outcome(s)? Use conceptual process models for planning, scoping, and architecture definition.

Use logical process models to get agreement and communicate how a process works or is required to work. Be prepared to elicit and document the answers to logical details such as: What are the detailed or summary activities? Who is responsible for what? What happens if? What happens when? What decisions will be made? What information is produced or used? Remember to elicit and include the details that are relevant to your model’s intended audience: those who participate in the lifecycle of your business process management or information technology project. Keep your model’s intended audience in mind when eliciting and documenting details. Use appropriately detailed logical process models for detailed functional requirements or design.

Use process configuration models to specify the configuration of concrete software modules, physical devices, and/or manual operating procedures that implement a process.

You typically use process configuration models in no-code or low-code software generation. To gain the benefits, you must specify very precise and accurate process implementation details, and exactly follow the process configuration modeling syntax.

 

Conclusion

A process model is not just a flowchart. It communicates what are, or will be, real-world operations. It may play a crucial role in the success or failure of your next business process management, information technology, or regulatory compliance project.

The most competent business analysts and process analysts clarify what their model’s required degree of abstraction will be, at the start of their analysis. They then focus their own and their project stakeholders’ efforts and time on the types of model content and format that will best suit each project’s unique needs.

You are welcome to learn more or share your comments and experiences about Your Next Process Model’s Degree of Abstraction via the Contact Us page at www.ProcessModelingAdvisor.com.

Copyright 2023, Edmund Metera
[1] The Business Analysis Standard (IIBA, November, 2022)
[2] PMI Guide to Business Analysis (PMI Inc, 2017)
[3] The Universal Process Modeling Procedure: The Practical Guide to High-Quality Business Process Models (Metera, 2018, 2022)
[4] The Universal Process Modeling Procedure: The Practical Guide To High-Quality Business Process Models Using BPMN (Metera, 2022)
BATimes_Dec22_2022

An Introduction to Business Process Normalization

Written by Edmund Metera on . Posted in Articles.

Business Process Normalization[1] is an analysis technique that leads to sound, modern business process and workflow structures.

Business analysts, process analysts, systems analysts, and process owners use Business Process Normalization to more effectively elicit, perceive, unequivocally define, and model sound, modern business process structures, and workflow configurations. Proficiency with this analysis technique benefits their process management, digital transformation, and regulatory compliance projects.

 

What is a Business Process Anyways?

For decades, business analysts, process analysts, and their projects’ stakeholders have tried to define business processes according to various characteristics. Business processes have been said to transform inputs into outputs. They can be decomposed into smaller parts.  They start. They “flow”.  They end. They have customers. They can cross organizational boundaries. They can be automated. They can be manual. They are measurable. While all those statements may be true, none of them are sufficient enough to elicit, perceive, and unequivocally define and produce high-quality business process structures.

There will be about as many points of view and opinions about what any business process is as there are stakeholders in that process, at least at the start of the process analysis.  As always, business analysts and process analysts need to be able to consistently perceive processes and facilitate the journey of business process elicitation, definition, and modeling, with their stakeholders. However, the pace and the technologies of modern, digital transformation, low-code and no-code projects demand that business process and workflow elicitation, and definition be done in an efficient, competent way, instead of ad-hoc questioning and trial and error.

 

Times have changed

Traditional procedural notions and flowcharting notations have become archaic. They were invented in the days of procedural language programming – in the last millennium.  Those notions don’t always work in today’s business and technical environments. Today’s distributed business structures (has anyone been working remotely recently?), technologies like the Internet of Things (IoT) and Edge, mobility, and cloud computing services have radically modernized the business process landscape.  Today, a high-quality business process structure is one that has been conceived, structured, and can be readily configured as a modern, collaborating network of event-driven, outcome-oriented services, not just as a sequential procedure.

 

The Universal Business Process Definition

Let’s look at housing. Any house, no matter its scale, degree of abstraction, location, building materials, and all its unique details, etc. must have a foundation, walls, and a roof to be a house. If it’s missing any of those, it is not acceptable as a house.  And for obvious productivity and quality reasons, those basic structural elements are established first, before it is practical to invest time and money in a home’s other architectural, engineering or construction refinements.

The same is true for business processes and workflow structures.  Any business process must have a sound, cohesive structure of basic elements to be considered a business process. Its basic structural elements should be elicited and consensus reached, before pursuing all of a process’s possible details and refinements. Even after all desired process refinements have been applied, the process will still have its defining structural elements. This holds true for any process structure or model at any degree of abstraction (i.e conceptual, logical, or configuration), a process’ scale, or the unique details about a business process or workflow.

So, what are the basic business process-defining elements? Paraphrasing the Universal Business Process Definition[2], any business process (i.e., business activity for that matter) is 1) a repeatable collection of work activities, 2) initiated in response to a business event that, 3) achieves an expected outcome, 4) for a customer of that process. These four common-sense rules define all processes, workflows, and activities regardless of a process’ or activity’s scale, the process model’s degree of abstraction, the overarching project methodology, the modeling participants, and the organizations and the technologies that will implement the process or workflow.

 

Uses of the Business Universal Business Process Definition

Business analysts and process analysts use the Universal Business Process Definition’s four common-sense rules throughout their business process modeling journey and they work out and arrive at high-quality, robust, predictable, and operational business process structures. They use it to guide their elicitation agendas with business stakeholders.  They use it to frame their observations of business processes. They use it to normalize what they and their stakeholders have named as candidate processes. They use it to resolve ambiguity among stakeholders and to organize business activities into the optimal, modern business process and workflow structures. This is akin to understanding and applying the Business Normal Forms[3], long used by business analysts and systems analysts to work out and optimally organize data attributes into entities and to produce high-quality relational data structures.

The resulting business process structures are high-quality structures because they have been elicited, perceived, and defined by asking and answering the right questions.  They can be implemented equally well as traditional sequential procedures or as today’s, distributed business structures and networked technical (like cloud services) architectures. As event-driven, outcome-oriented business process structures, they are consistent with modern networked, collaborative business relationships and cloud technologies.

 

Advertisement

 

Business Process Normalization

Business Process Normalization is the analysis technique of testing the contextual meaning of a candidate business process according to the Universal Business Process Definition’s four rules.

A business analyst or process analyst need not ask a lot of questions to normalize a business process or workflow. They only need to ask a few focused questions (four in fact) and doggedly pursue and gain consensus to the four, sometimes-elusive, answers. The assumed basic structure of a business process will either be affirmed or restructured by the answers to the normalization questions. If any of the four tests have not yet been satisfactorily answered, then the analyst will need to elicit more clarity to satisfactorily answer the four process-defining tests.

Once all four tests have been sufficiently answered, the process has been normalized. Ambiguities have been resolved. A sound, fundamental business process or workflow structure has been understood.  The answers to the four tests can then be used to write a contextually accurate, unequivocal, plain-language process definition. No two processes will likely have the same definition within the same domain of analysis. The normalized process’s defining structure will be the foundation of a contextually accurate, high-quality business process model, configured business procedure, or automated workflow.

 

Benefits of Business Process Normalization

The benefits of using the four-part Universal Business Process Definition’s rules and the Business Process Normalization technique are that they are relevant for today, it is efficient, it boosts contextual quality, it minimizes redundant and non-value-adding activities, it aids in well-written process descriptions, and it improves the potential for reusable business services.

 

  • Relevant for Modern Business Structures and Technologies. Processes that have been normalized according to the Universal Business Process Definition are event-driven and outcome-oriented. They are structured so that they can be readily implemented across enterprises’ geographies and boundaries. They are easily modeled using modern notations, like BPMN. They can be readily translated into modern networks of collaborating services (such as SaaS services in the cloud), just as well as traditional sequential procedures and workflow designs.

 

  • Efficient – Whenever discovering and defining business processes among a group of stakeholders, it’s more effective to be asking the right questions than a lot of questions. The Universal Business Process Definition frames the elicitation and normalization agenda with four simple questions. The process modeling work comes down to doggedly pursuing and getting consensus to the questions’ answers among the right business stakeholders.

 

  • Boosts Contextual Quality – Assuming that everyone will understand the same meaning for the name of a business process is insufficient. By normalizing a business process according to the Universal Business Process Definition’s four rules, the contextual knowledge and consensus about that process become unequivocal among readers of that definition.

 

  • Minimizes Process Redundancy. An enterprise may have different processes that do the same thing. They are just named differently.  Any two candidate business processes that, through process normalization, answer Business Process Normalization’s four tests with the same answers are very justifiably two different names for the same process.  They should be closely re-examined to decide if one of them can be, in due course, feasibly eliminated.

 

  • Minimizes Non-value-adding Activities. People, departments, and enterprises tend to propose or perform activities that they do, instead of what is needing to be done. The value of their activities toward achieving a process’ or workflow’s expected business outcome may be unclear. According to the Universal Business Process Definition, a process includes the activities that lead to a process’s expected outcome. Candidate activities that are not needed to achieve a process’s outcome should be closely re-examined and either be discarded, or they may belong in another process.

 

  • Aides in Well-Written Business Process Descriptions. The answers to the four business process normalization questions can be simply written in plain-language sentences to form consistently written, clearly written, and contextually meaningful, process descriptions. (Examples of such process descriptions can be found here.)

 

  • Improves Potential for Reusable Services – According to the Universal Business Process Definition, activities are themselves perceived and defined as event-driven and outcome-oriented processes. Each is defined in part and bounded by its initiating event and expected outcome. Because of this event and outcome-oriented structure, activities have the potential to be recognized as reusable services, which may be reused in more than one larger process.

 

 

Learn more …

You can establish or improve your business process modeling competence and learn the Business Process Normalization technique, by reading:

 

 

 

  • Find related topics at ProcessModelingAdvisor.com. The site’s purpose is to help you establish or improve your business process modeling competence. It includes articles, process model examples using BPMN, checklists, and access to out-of-the-box IIBA-endorsed and bespoke business process modeling training.

 

 

Copyright 2022, Edmund Metera
[1] Universal Process Modeling Procedure – The Practical Guide to High-Quality Business Process Models Using BPMN (Metera)
[2] Universal Process Modeling Procedure – The Practical Guide to High-Quality Business Process Models Using BPMN (Metera)
[3] The Data Modeling Handbook (Reingruber and Gregory)

 

BATimes_Dec1_2022

The Beautiful Game as a Modern, Event-Driven Business Process Structure

Written by Edmund Metera on . Posted in Articles.

The Beautiful Game

Whether you call it football or soccer, “the Beautiful Game” as it is widely known, has simple rules of play. But playing soccer is another matter. It is a highly dynamic, agile process. In the flow of a single match, an eleven-player professional team can make more than 500 passes and there can be dozens of game stoppages.

In the eyes of process analysts, quality improvement professionals, and business analysts, who still rely on the more than 100 years-old, strictly procedural notions of a process and on flowcharting notations that were also invented in the last century, IT IS IMPOSSIBLE to perceive and model something like playing soccer as a sequential process.

The Modern Business Process Modeling Solution

The most effective business processes are not only structurally sound and efficient but also highly dynamic and agile.  A high-quality business process structure today is one that has been conceived, structured, and can be readily configured as a network of specialized, collaborating, event-driven, and outcome-oriented services, not just as a sequential procedure.

If a business analyst, process analyst, quality analyst, or manager adopts that modern business process paradigm and a modeling notation that is aligned with how today’s business relationships and processes work, then perceiving and modeling something as dynamic and agile as the beautiful game as a process, IS NOT ONLY POSSIBLE, BUT ELEGANT.

Universal Business Process Definition[1]

The Universal Business Process Definition is not constrained to a strictly procedural notion of a process. It is an event and outcome-oriented business process paradigm. The Universal Business Process Definition’s four common-sense rules define all processes, workflows, and activities, regardless of a process’s scale, the overarching project methodology, the model’s required degree of abstraction, the modeling participants, and the organizations and the technologies that will implement the process or workflow.

The Universal Business Process Definition, and the Business Process Normalization technique are defined in the Universal Process Modeling Procedure (UPMP), published by ProcessModelingAdvisor.com.

Business Process Modeling and Notation[2]

Business Process Modeling and Notation (BPMN) is a graphical notation for illustrating modern business process elements.  It overcomes the limitations of the last century’s procedural flowcharting and process mapping notations.

BPMN was defined by the Business Process Modeling Initiative (BPMI) and is maintained by the Object Modeling Group (OMG). BPMI states that the goal of BPMN is:

“To provide a notation that is readily understandable by all business users.”

BPMN is the best-suited notation for illustrating modern business process and workflow structures. It includes sequential flowcharting elements, but BPMN also includes symbols for illustrating concepts that are relevant to today’s dynamically collaborating systems and business processes. Namely, events and messaging.

 

Advertisement

 

The Beautiful Game as an Example

We don’t need process models about playing soccer. We’d rather be playing or spectating. But we’ve all observed enough about playing soccer to use it as a commonly understood example.  Playing soccer happens to be similar to how modern-day business processes and operating relationships work. Let’s use soccer to demonstrate how to apply a modern business process modeling paradigm and modeling notation to discover and illustrate a sound, modern business process structure.

Event-Driven Business Process Flow

A contextually and structurally sound model of the Play Soccer process can be discovered by answering the Universal Basic Business Process Flow Elicitation Agenda[3] and the Universal Event and Outcome-Oriented Business Process Flow Elicitation Agenda[4], found in The Universal Process Modeling Procedure.

This basic, event and outcome-oriented (non-procedural) BPMN process flow diagram communicates the normal, dynamic flow of Play Soccer as a set of collaborating, specialized activities.

The Play Soccer process is initiated by a kick-off at center field. It is comprised of 4 activities: Tend Goal, Defend, Play Midfield, Play Striker. Activities are performed by the players of two teams. The expected outcome of Play Soccer is that a match has been played to its allotted time limit, according to its rules.

A free kick from center starts a match.  Once the match starts all players in their assigned positions maneuver freely, whether they possess the ball or not.  The expected succession of the keeper’s, defenders’, midfielders’, and strikers’ activities is determined dynamically, by the players, while the match is played, by receiving or intercepting passes, stopping shots, and by making passes or taking shots.

The player with the ball will pass the ball to any one of up to 10 other teammates or take a shot; Either the intended teammate will receive a pass, or an opposing player will intercept a pass or stop a shot, to possess the ball. Any player that possessed the ball will then maneuver (according to their assigned position level and their own skill) and then pass the ball to any one of up to 10 other teammates or take a shot. This succession of activities continues, until a stoppage in play.

The success of the expected outcome (pass made or shot taken) of one Play Soccer activity will determine the initiating event (pass received/intercepted or shot stopped) of another Play Soccer activity. The actual flow of a game is determined dynamically, by the players who are assigned to perform Play Soccer’s activities.

This basic, event and outcome-oriented process view of Play Soccer is contextually and structurally sound, but still basic. It is upon this solid, defining structure that one can elicit, add and communicate logical details that are relevant to how the Play Soccer process will “flow” and, that this model’s readers likely expect to see. What about conditional activities, like throw-ins, corner kicks, penalty kicks, substitutions, fouls, out-of-bounds, injuries), and delays (like injury time-outs, and half-time)?

 

Logically Refined Business Process Flow

The logical details about the periodic conditions, activities, and delays in the execution of the Play Soccer process can be straightforwardly discovered by asking and answering simple agendas that are defined in The Universal Process Modeling Procedure[5]. This refined BPMN process flow diagram communicates the conditional activities and delays that are expected to periodically occur throughout the dynamic flow of Play Soccer.

The BPMN process diagram shows that game events, not a sequential procedure determine what and when certain activities are performed in the Play Soccer process.

Even with all those refinements made, the contextually accurate and sound basic structure of the Play Soccer process, that we previously established, has not changed. These refinements can be graphically included or excluded, without any rework of the basic contextual meaning or basic diagrammatic structure of Play Soccer.

Activity dependencies are contextually accurate, without depicting a sequential procedure and sequential flows. Dynamic, alternate activities, paths, and timings throughout the process are accounted for in the model. Undue model complexity, and the analyst’s time that would have been spent on it, has been avoided. Process navigation decisions, and alternate flow paths are in fact modelled, but need not be explicitly illustrated as sequence flows.

Conclusion

The Beautiful Game serves us as a beautiful example of a process that is a set of dynamically collaborating sets of specialized services. It is not a sequential procedure.  Modern business processes are not just sequential procedures either.

The Universal Process Modeling Procedure, with its Universal Business Process Definition and elicitation agendas, provides a modern process modeling paradigm, capable of event-driven as well as sequential business process elicitation and modeling. BPMN is a modern process modeling notation, that includes the graphical elements to represent business event-driven, not just sequential process flows.

With these tools in-hand, process analysts, quality improvement professionals, and business analysts, are capable of eliciting, perceiving, normalizing, defining and graphically illustrating structurally sound, modern business process structures.

Copyright 2022, Edmund Metera

[1] Universal Process Modeling Procedure – The Practical Guide to High-Quality Business Process Models Using BPMN (Metera, 2018, 2022) www.ProcessModelingAdvisor.com
[2] Object Modeling Group, www.OMG.org
[3] Universal Process Modeling Procedure, Step 3 – Define Basic Business Process Flow (Metera, 2018, 2022)
[4] Universal Process Modeling Procedure, How to Specify Event/Outcome Oriented Business Process Flow (Metera, 2018, 2022)
[5] Universal Process Modeling Procedure, Step 5 – Refine Business Process Flow(s) (Metera, 2018, 2022)
BATimes_Sep8_2022

Best of BATimes: A Checklist For Business Analysis Planning

Written by Edmund Metera on . Posted in Articles.

Use the Universal Business Analysis Planning Checklist as You Plan Your Business Analysis Approach.

Every project is a unique, temporary endeavor.

 

The business process management, regulatory compliance and digital transformation projects that business analysts may play a role in all come with different goals, scopes, teams, timelines, budgets dependencies and risks.  Though many projects follow similar methodologies they are all tailored for project scope constraints and to take advantage of available resources, opportunities and lessons learned from prior work.

Each business analyst also comes with a unique set of skills and experiences. Almost all business analysts have great communications skills and at least some experience-based business domain knowledge. That’s why they became business analysts in the first place. Every business analyst has uniquely acquired knowledge of business analysis techniques and business domains through personal study, practice and experience. Many have also been trained in elicitation, requirements management, modeling, measurement, analysis and documentation techniques. An ever-growing number have received professional certifications, such as the IIBA Certified Business Analysis Professional (CBAP) or the PMI Professional in Business Analysis (PMI-PBA).

What is Business Analysis Planning?

The most skilled business analysts are not only competent in many business analysis techniques but also consciously tailor their business analysis approach for each project that they engage in.  They have learned to consider key project dynamics along with their own competencies and to tailor their planned business activities and deliverables to suit each project’s unique dynamics. Regardless of your own level of business analysis experience, maturity, and whether you are formally trained, certified or not, you can still consciously assess each project’s dynamics and tailor your forthcoming business analysis work to get the most productivity and value out of your business analysis efforts in each project.

The most significant project dynamics include:

  • The methodology, or sequence of stages or major milestones, and the business analysis products or outcomes that are expected by the end of each stage/milestone (and before starting the next).
  • The budget and schedule, not only to meet them, but to take advantage of contingency or schedule slack opportunities, to increase the value, quality or to learn.
  • The key project stakeholders and relationships that are new and changed and forming, to take a proactive role in fostering and building relationships with and among that team.
  • The types and combinations of elicitation techniques that will be best suited for producing or validating business analysis deliverables.
  • The business domain knowledge and experiences of the diverse key project stakeholders, including your own unique set of business analysis competencies.

The Universal Business Analysis Planning Checklist

You can be more effective in planning your business analysis approach if you follow a consistent, clear agenda that considers the common project dynamics.

The Universal Business Analysis Approach Planning Checklist covers the most common project dynamics. You can use this as an agenda to elicit and discover a comprehensive view of a project’s key dynamics, its opportunities and use what you discover to adapt/tailor your business analysis approach.

As an exercise, think of a project that you have recently worked on, you are currently working on, or will soon be working on.  Answer questions in the following checklist for yourself.

Project Life Cycle

  • What are the planned stages of this project?
  • What stage are we currently in?
  • What is the business analysis deliverable (or set of deliverables) that I am responsible for producing in this stage?
  • What is the intended use of my business analysis deliverable(s) and who will use it?

Schedule And Effort Budget

  • How much effort can I spend and by what target date am I expected to produce my business analysis deliverable(s)?
  • Is that about what I also estimate it will take?
  • Is either my effort or date estimate higher than the effort budget or target date? If so, how might I adapt my effort, scope, activities or configuration of my deliverable(s)?

Project Stakeholders And Relationships

    • What are the key roles is on the project team and who is in them?
      • Does this project have an executive sponsor, project owner or product owner, project manager, specialists and business subject matter experts?
      • What are the names and titles the persons in these project roles?
    • Are significantly new relationships being are created in this project?
      • Who’s new to each other on this team?
      • Are there local and who’s remote team members?
    • What are peoples’ responsibilities?
      • Who is responsible for producing, accepting or needs to be consulted or informed of each of the project’s key deliverables, particularly the business analysis deliverable(s)?

 

Advertisement

 

Elicitation Techniques

  • Which elicitation techniques are available to me use?
    • Documentation Reviews – What documentation or prior work products are available to review?
    • Interviews and Workshops – Who can I interview or include in a workshop, and what questions would I need to ask?
    • Observations – Where and what kinds of observations may be needed and how could I arrange for them?
    • System reviews – What system(s) are available to review and for what information?
    • Surveys – Who could I engage in a survey and using what types of questions?
  • What are my own business analysis competencies?
    • Considering this project’s stakeholders and relationships, the elicitation techniques available to me, and my own core competencies, which elicitation techniques are best suited gather and validate my business analysis information?

Organizational Assets

  • What specialized tools for elicitation, documentation and modeling are available to me?
    • Collaboration tools, facilities, survey tools?
    • Diagramming or modeling software?
  • What prior business analysis work (e.g., documents, models) that I can draw from?
  • Does my organization offer training in the subject business domain?

Competencies And Knowledge

  • Who on the project team has what expert business domain knowledge?
  • What is my own business domain knowledge?
  • What are my strongest core business analysis competencies?
  • Where can you take advantage the team’s diversity of knowledge and competencies?
  • Who are the best stakeholders in this project to engage in elicitation of content or validation of business analysis deliverables and what is or are the best elicitation techniques to use?

On reflection, are you able to answer these questions for yourself? When you go into your project workplace, who will you include in this conversation?

Conclusion:

Business analysis planning is a recognized business analysis activity. The IIBA Body of Knowledge (BoK) includes the Plan Business Analysis Approach activity within its Business Analysis Planning and Management process. The BoK also lays out the scope of what should be covered by a Business Analysis Approach as “The set of processes, templates, and activities that will be used to perform business analysis in a specific context.”

The time and formality that you apply to business analysis planning is up to you. At the financial institution where I work as a project and program manager, our business analysts typically tailor and document a business analysis plan for each new project to which they are assigned.

I think of business analysis planning as a form of insurance. Spend a little time upfront to assure that the bulk of the rest of your business analysis efforts will be as well spent and effective as possible. Expect the benefits of tailoring a business analysis plan for every project to be that:

  1. It will help you to align your own core business analysis competencies to each project, and
  2. You and the project will gain the most value from your business analysis efforts.

That’s a value-adding proposition.

You are welcome to contribute comments about project dynamics that impact business analysis plans or about the checklist presented through the Contact Us page at www.ProcessModelingAdvisor.com.

No-Code and Low-Code Platforms Demand Process Modeling Competence

Written by Edmund Metera on . Posted in Articles.

Thanks to infrastructure as a service (IaaS) and software as a service (SaaS) architectures, the utility of and business case for model-driven, no-code, and low-code platforms have become more compelling than ever. More and more enterprises are entrusting their digital transformation, regulatory compliance, and business process management objectives to model-driven, no-code, or low-code business application platforms.

These model-driven platforms also raise the bar for the business process modeling skills of the business analysts, systems analysts, and process owners who use them.

Advertisement

No/Low Code Platforms are Gaining Momentum

As implied by the name, no-code or low-code platforms can deliver solutions at reduced cost, complexity, and cycle time with less programming. The work of business analysts, business subject matter experts, and process owners can significantly displace the need for programmers.

No-code and low-code Platforms have always been very good at what they are designed to do: UI development, process automation, reusable data, and third-party service integrations. Many of these platforms also have the tools that will improve the overall control and management of software and business processes.

Thanks to the cloud’s IaaS and SaaS architectures, no/low-code platforms, and their applications are now much more robust and sustainable than they used to be. Many no/low-code generation platforms are themselves Software as a Service (SaaS). Their compatibilities with their surrounding infrastructures and other digital services in the cloud are secured, managed, and maintained by their vendors, outside of the concern of their client enterprise’s premises.

Process Modeling Becomes a Crucial Skill

A business process or workflow model is typically integral and its quality is crucial in no-code or low-code platforms. The process model is a configuration model, used by the platform to generate application software.

Here are some examples of no-code and low-code platforms that have built-in process/workflow modeling tools:

 

Establish or Improve Your Process Modeling Competency

Any business process model’s quality can be measured by its syntactical quality and its contextual quality factors. Syntactical quality means modeling the business process right. Contextual quality means modeling the right business process.

To achieve syntactical quality in a no-code or low-code environment, you must adhere to and use the graphical notation and configuration item types required by that no-code or low-code platform’s process modeling tool. That’s easy enough to do. You just need to supplement your existing analysis skills by taking the tutorials or training from the no-code or low-code platform’s vendor and adhering to that platform’s chosen syntax for things like events, tasks, sequence flow, etc.

To achieve contextual quality, you must accurately enough reflect the real business and have enough key stakeholder buy-in. No process modeling tool can do that for you.  Achieving contextual quality relies upon the analyst’s process modeling competence. It means having a proven process modeling approach for process elicitation and modeling, asking the right questions, being able to clearly perceive, normalize and define processes and activities, sufficiently engaging key stakeholders at the right times, and sufficiently validating your process model, by the time the model is finished and before the code is generated.

Contextually high-quality process/workflow models will in turn generate high-quality no-code or low-code workflow applications for your business. A poor-quality process model will lead directly to business process/workflow configuration errors.

You should bring a business process modeling competence as your table stakes. In a fast-paced, model-driven environment, relying on an ad-hoc process modeling approach will be insufficient. You will not have the time, and the business may not have the patience, to figure out how to produce a high-quality business process model as you are pursuing one. If you don’t already have sufficient, confident business process modeling skills, you can establish or improve them before jumping on board a model-driven no-code or low-code platform.

One way that you can establish or improve your business process modeling competence is by adopting the Universal Process Modeling Procedure. The Universal Process Modeling Procedure, is a defined, and widely used approach for producing high-quality business process models. It is a 6-step business process modeling procedure. It provides a razor-sharp elicitation agenda at each step. Its event-driven, outcome-oriented Universal Process Definition empowers business analysts, process analysts, and process owners to elicit, perceive, normalize and define any business process or activity. It guides you in validating your completed business process model’s quality using standardized syntactical and contextual quality criteria before you finish and implement your process model.

  • 1
  • 2