Skip to main content

Tag: Agile

Impact of Artificial Intelligence on Business Analysts and BA Jobs

Written by Ananya Pani on . Posted in Articles.

Artificial Intelligence is no longer a buzzword, and it has been making waves in the tech industry. We are experiencing AI in our day-to-day life in the form of chatbots, Voice assistants in serving customers’ requests, forecasting market trends, detecting possible future ailments, and much more. In recent years, businesses have begun adopting AI to improve their operations and gain a competitive edge. But what does this mean for business analysts and BA jobs? With the rise of AI, will Business Analysts become obsolete, or will it create new opportunities? Let’s dive into how artificial intelligence affects business analysis and explore what the future holds for those in this field.

If you are a business analyst, you need to be skilled to leverage these technologies as an added advantage to your capabilities to deliver continued value to your organization.

So, are you geared to make the most of it or see it as a threat, or are apprehensive of losing your job to AI?

AI is your new superpower

As a business analyst, you have access to a wealth of data to help you make better decisions for your company. But what if you could tap into the power of artificial intelligence (AI) to supercharge your decision-making process?

With AI-powered business analytics tools, you can get insights that would otherwise be hidden in your data. For example, you can use predictive analytics to identify trends and patterns in your data and then use those insights to make better decisions about where to invest your resources.

AI can also help you automate repetitive tasks so that you can focus on more strategic work. For example, you can use natural language processing (NLP) to automatically generate reports from unstructured data sources like social media or customer feedback surveys. Using these opportunities helps us converse with customers about new possibilities.

In short, AI is your superpower when it comes to making better decisions for your business. So why not put AI to work for you?

 

Use AI to have more control over your time and use it more efficiently –

Let AI do all your routine, monotonous/repetitive jobs that free up more time and energy for Business Analysts.

Artificial Intelligence (AI) is increasingly being used to automate low-level tasks, freeing time and energy for Business Analysts. This allows Business Analysts to focus on more strategic tasks, such as identifying new opportunities, analyzing data, and improving processes. As AI continues to evolve, it is expected that even more mundane tasks will be automated, further freeing up time for Business Analysts to add value to their organizations. Let the easy and monotonous tasks be taken up by AI, leaving the complex and the more challenging tasks to humans. Having said that, it requires us to grow and sharpen our skills.

 

BAs add significant value to the organization with their cognitive abilities

BAs add significant value to the organization in many ways that AI can’t take up.

They:

  • Perform a pivotal role in bridging the gap between business and IT.
  • Help/collaborate with stakeholders in prioritizing the requirements, helping them refine the requirements, and eliciting them using various techniques.
  • Influence/assist stakeholders in moving towards the unified project goal by communicating effectively.
  • They understand the business domain and processes and translate them into technical requirements.
  • They often apply out of the box solution approaches to solve business problems where a straightforward solution may not be available.

All these skills are essential for the success of any project or organization but cannot be replaced by AI.

Here is a detailed analysis of skills/tasks that currently are not possible to be taken up by AI.

 

Advertisement

 

Problem-solving

BAs help in Problem-solving – For impediments faced in the process or by the team:

Artificial intelligence has altered the role of business analysts and BA jobs. In the past, BAs were responsible for gathering requirements and documenting them. However, with the advent of AI, business analysts now need to be able to solve problems that may arise during the process or by the team.

This is where AI can be beneficial. With its ability to identify patterns and correlations, AI can help business analysts understand why specific problems are occurring and how they can be solved. Additionally, AI can also help BAs predict future problems that may arise and recommend solutions accordingly. As a result, BAs are now able to provide more value to their organizations by helping to solve complex problems.

 

Out of box thinking

Organizations are under constant pressure to do more with less. As a result, they need their employees to be creative and come up with innovative solutions to problems. This is where out-of-the-box thinking comes in.

Business analysts are in a unique position to help with this. They are trained to think critically and creatively, and they have the analytical skills to back up their ideas. BAs can help organizations see problems from different perspectives and come up with new solutions that they may not have considered before.

AI is only going to increase the demand for out-of-the-box thinking. As AI capabilities continue to grow, businesses will need employees who can think outside the box to keep up. BAs who can provide this critical thinking will be in high demand.

 

Critical decision making

BAs help in coming up with the best possible solution from the various alternatives.

BAs help organizations to make sense of all the data they collect and to use it to make better decisions. With the help of artificial intelligence (AI), BAs can now do even more to improve decision-making. AI can help BAs to identify patterns and correlations that they might not be able to see with their human eyes. AI can also help to automate some of the tedious tasks that BAs have to do, such as gathering data from multiple sources. This frees up the BA’s time so that they can focus on more strategic tasks.

AI is also helping BAs to come up with better solutions from the various alternatives available. With AI, BAs can test out different scenarios and see which one is most likely to succeed. This helps organizations to make better decisions and to avoid costly mistakes.

Overall, AI is having a positive impact on the job of the BA. With AI, BAs are able to do their jobs more effectively and efficiently.

 

Stakeholder collaboration –

BAs play a critical role in validating and prioritizing needs.

In any business, it is essential to have a good understanding of what your stakeholders want and need from you. This can be difficult to do without the help of a business analyst. Business analysts are experts in stakeholder collaboration. They can help you validate and prioritize the needs of your stakeholders. This is important because it ensures that you are meeting the needs of your stakeholders and that your business is able to run smoothly.

 

Bridging the gap between tech and users

As the adoption of artificial intelligence (AI) continues to grow in businesses around the world, the role of the business analyst (BA) is evolving. BAs are uniquely positioned to help bridge the gap between technical teams and users, and workshops are one way they can do this.

Workshops help BAs understand the needs of users and translate them into requirements for technical teams. They also help technical teams understand the capabilities of AI and how it can be used to solve business problems. By facilitating communication between these two groups, BAs can ensure that AI is deployed effectively and efficiently.

What’s more, as AI becomes more complex, the need for BAs who can navigate its increasingly murky waters will only grow. With their deep understanding of both business and technology, BAs are essential partners in helping organizations realize the full potential of AI.

 

Data analysis –

Deriving intelligent insights from the data to facilitate business decisions.

A Business Analyst (BA) is responsible for analyzing an organization or business domain and documenting its business or processes or systems, assessing the business model or its integration with technology. They also help in data analysis and derive intelligent insights from the data to facilitate business decisions. Data analysts use statistical techniques to examine data and draw conclusions from it. They help businesses to make better decisions by taking into account a wide range of factors, including cost, time, resources, risk, and objectives. The role of a BA has become even more critical in recent years as organizations strive to become more data-driven in their decision-making.

With the advent of artificial intelligence (AI), there is ample opportunity for BAs to leverage AI technologies to improve their efficiency and effectiveness in data analysis. AI can help BAs to automate repetitive tasks such as data collection and cleansing so that they can focus on more strategic tasks such as identifying trends and patterns in data. AI-powered tools can also help BAs to make better recommendations by providing them with real-time insights based on large volumes of data.

In order to take advantage of these opportunities, BAs need to upskill themselves in AI technologies. There are many online courses and resources available that can help BAs get started with learning about AI.

 

Ethical and responsible use of confidential customer information

As business analysts, we are constantly working with confidential customer information. It is our responsibility to use this information ethically and responsibly.

Here are some ways that we can do this:

  • Be transparent about how we will use the customer information.
  • Get explicit consent from the customer before using their data.
  • Keep the customer information secure and protect it from unauthorized access.
  • Only use the customer information for the purpose it was collected for.
  • Dispose of the customer information securely when we no longer need it.By following these guidelines, we can ensure that we are using confidential customer information in an ethical and responsible manner.

To sum it up, keep your skills chiseled, use your cognitive skills to deliver value, keep your learning on, and leverage technology to keep you in demand.

BATimes_May10_2023

Building a House: Analogy for the Business Analysis Role

Written by Nicola Myers on . Posted in Articles.

Two years ago, my friend asked me what my job role was, and I said that I was a business analyst in Information Technology (IT). However, after all this time, she still doesn’t understand what my job entails. To assist friends of other business analysts around the world, I have written this article to explain what we do. I can’t wait until she reads my article!

 

Let us propose a world where business analysts are architects, the developers are builders, the inspector is the quality assurance team, and our software client would like to build a house.

Usually, the builders would start building the lounge. This sounds good because they are off to a flying start and the walls are going up, but the builders do not know how many bedrooms the house will need, where the best location for the bedrooms is, or even why they are building the building at all. The kitchen might even end up with four sinks and no oven, or the kitchen might not even exist. Finding out that this is not what the customer wanted when the house is half built is expensive to fix, will not meet the deadline, and worst of all, the house will not be what the customer wants at all!

A far better idea is to include an architect on the team.

 

Firstly, the architect will sit with the customer and find out the high-level goals of the building, for example, the customer would like a family house in a quiet suburb because currently they live in a noisy complex. They are also expecting a second child. The business analyst (BA) is gathering context on the problem and the customer’s vision.

Right from the start the architect explains the process that will be followed, builds a trusting relationship with the customer, and starts to manage the expectations of the customer, for example, steering the customer away from a water slide in the lounge which could take an extra six weeks. This is change management, which should happen as early as possible and should set the tone for the rest of the project. It should also be noted that the business analyst is the ambassador of user needs and so is the team member that focuses on them.

The architect will then dive into the details and obtain the customer’s requirements, draw diagrams, and can even print a 3D model of the house. It will become clear to the architect and the customer exactly where the main bedroom will be, how large it is, how many windows it will have and so much more. This is the Business Analyst (BA) conducting requirement elicitation, drawing up wireframes, and prototyping the solution. The BA will also choose the best way to engage with the customer, such as through prototyping in workshops or sticky notes on a virtual whiteboard.

 

Advertisement

 

To double-check that the architect and the customer are on the same page, the architect will draw up some basic design criteria that the building must meet, for the example given that the room is the older child’s room, when the builders are building the walls, then they must build two windows. This is writing acceptance criteria.

A very important step is that the architect will confirm their findings with the customer to make sure everything is covered and covered correctly. This is the validation and sign-off stage. Note that architects can suggest solutions to fill in the gaps, for example, they can suggest that the house should face north, but it is ultimately it is the customer who makes the decision.

 

Our builders are brilliant in their field, but they are better at building than communicating. This means that the BA needs to translate what the customer needs so that they fully understand what to do. BAs bridge the gap between the business and technical sides. The architect explains “what” needs to be done, the builders decide “how” it will be done, for example, the builders will use wheelbarrows.

The architect will sit with an interior designer and discuss the finer details to make the house as well designed as possible, for example how to place the cupboards in the kitchen to make the layout practical. This represents the interaction of the BA with the user experience experts to make sure the software is intuitive and a positive experience.

 

Now the builders know what to do, the building continues nicely, with a few hiccups along the way such as the bricks weren’t delivered on time. The architect will work closely with the builders every day and if the builders have any questions or are unclear on anything then the architect needs to go back to the customer for answers.

Each day the entire team, with the customer, will stand on the pavement and have a quick meeting to let the other team members know what they did yesterday, what they are doing today, and if there are any blockers or dependency issues. This is a daily standup meeting.

 

Every second week, the team sit around a table on Friday afternoon with some drinks and discuss how the project is going. They say what has worked well and what could have gone better. They decide what to keep doing and what new ways can be put in place to improve the way they are doing their work. This is a retrospective meeting used with an agile approach.

Once a section of the building is complete, then the architect will walk around the building with the building inspector. The inspector will check every detail to ensure the house is built to code and is safe while the architect will ensure that the building is what the customer actually wanted. Sometimes the builders can get really enthusiastic, go off course, and place a central fountain in the kitchen and forget the sink. This is a verification process step.

The house is completed, with a few bumps along the way, but the customer is thrilled (hopefully) and can’t wait to move in.

 

In conclusion, call us business analysts, business architects, solution designers, or craftsmen but understand that we undertake many daily tasks and play a vital role in the development of successful software projects. We may not build the building but direct it (builders like to build theme parks) and save the customer a lot of money. Hopefully, my friend will understand what I do now!

BATimes_Apr19_2023

Agile Requirements Management Part 3 – A Collaborative Data Model

Written by Steve Farrall on . Posted in Articles.

In this article I want to explore how to integrate data requirements with product features and user stories; the result is some very useful traceability to where a particular data entity or attribute is being used across a product.

A conceptual data model is an integral part of the analysis process, it allows the analyst to better understand the overall requirement and how the various elements are related to each other. This enables the correct features to be identified to support the requirement and may well identify some gaps in the requirement where data is not being setup ready for the next process to collect and consume.

The data model will then naturally provide the start point for the database design and will ensure that all the features and associated user stories are all be singing from the same hymn sheet. The sprint teams will benefit from a shared understanding of the data that they are being tasked to manage.

 

 

The Tool

 

Initially my thoughts were that a true data modelling tool with a built-in dictionary were needed, having used these kinds of tools in previous projects.

As the choice of tool was limited, we explored whether Confluence might provide a useful stand in solution; we were already using Confluence to manage the requirements and user stories, so this looked like a natural plug-in to our existing Confluence wiki.

 

 

 

Develop the Model

For convenience, a separate data modelling space was setup to hold all the diagrams and page content for the data model which could then be referenced across the Wiki pages to add understanding to the requirements.

The Confluence service we were using came with the Gliffy diagramming tool; this allowed us to create entity relationship diagrams (class models).  As the model was quite large, it was split into distinct data domains, this is easily managed by creating a view (diagram) for each domain.

 

 

 

Create Data Entities

In order to make the Confluence data model more like a true tool-based model, hyperlinks were included in the diagrams attached to drawing objects like an entity or domain; click on a high-level domain in the diagram view and the attached URL will then launch the associated domain view diagram, allowing a drill down to the detailed entity level.

 

 

Once down at the entity level, the next step is to setup each entity as a separate Confluence page; the last click at the entity level will arrive on a page that can be enriched with content for collaboration with the team.

Each data entity is loaded as a separate Confluence page; this approach also means that you can link to individual features and user stories using the page URL but also provides a ready-made folder to hold related content like data attributes.

 

Advertisement

 

Tip – Setup Data Domains

Setup a domain hierarchy in Confluence to file the entities appropriately, this will facilitate creating views of subsets of the model using the ancestor filter option in the reporting macro.

 

Trace Data Requirements

 

Now we have the model available in Confluence with each entity loaded as a separate page the data requirement can be integrated into the requirements wiki traced to the product features and included in user stories as a URL link to the relevant pages.

 

Tip – Identify Data Usage

The more comprehensive the application of this approach the greater value will be realised; if you go down to attribute pages then it will be possible to drill down to where data items are being processed.

 

 

Setup Data Attributes

 

Defining the data attributes is a useful activity to ensure that the system will include all the required data and manage it in a consistent manner.

Data attributes can be simple and self-explanatory items, the name alone can be enough to understand the purpose intended; however, it is often the case that the meaning can be very subtle and having an attribute page available to record an explanation is very useful.

Data attributes are setup as child pages to the parent data entity page to provide a natural filing plan but they can be referenced anywhere and shared in conversations with team members to clarify their purpose and ensure consistent data usage.

Tip – Attribute Names

Page names must be unique within a Confluence space, so it is a good idea to fully qualify the page name with the entity name as a prefix to avoid any duplication issues across different entities.

 

 

Integrate Data Requirements

 

This is where the data model becomes integrated and collaborative, a big advantage over separate modelling tools.

Whenever a user story is referencing a data requirement then the URL to the entity page can be plugged into the story as part of the narrative. For example, the narrative “Create a Customer record for the order received” can replace the plain text “customer” with a URL to the customer entity page instead. Once this approach is adopted the data usage can easily be discovered; starting from the entity page under the page information details all the incoming and outgoing links to the page will be shown, revealing where the data is used and with a single click the reader can jump straight to the story page.

Tip – Business Rules

Including attribute links in business rules will ensure the sprint teams are looking in the right place when implementing the user stories. For example, check the “order delivery date” has not be missed; otherwise, an alert must be triggered to follow-up on the delay with the customer.

 

Conclusion

Confluence may not appear to be the obvious tool to consider for managing data requirements; however, the fact that it can be integrated with the product features and user stories is quite powerful. The ability to see where individual data attributes are being used facilitates impact analysis and support; the business rules can be expressed precisely and facilitate the development of an integrated system.

It will require careful management to ensure changes can flow through the process and can easily be identified but this is true of all these kinds of tools.

Last but not least is a the record of feedback and comments added to the pages in Confluence, explaining why certain decisions were made and how data attributes introduced are being used by the system. This record will be invaluable for assurance and support queries to understand the how and why a piece of data is being used by the system.

 

BATimes_Mar30_2023

Agile Requirements Management: The Art of Collaboration

Written by Steve Farrall on . Posted in Articles.

In this article I want to expand on how to manage requirements, particularly focused on delivering user stories to development teams ready for sprint refinement sessions. The starting line is a set of requirements that have already been formulated and issued, for example as part of a tendering process for a new service or upgrade to an existing service.

The Tool

We adopted the Confluence wiki collaboration tool as it is well integrated with the preferred Jira sprint management tool from the same supplier, Atlassian. The objective was to build a knowledge base for the product that is sharable and retains useful insights posted by stakeholders and the project team; this will facilitate future enhancements but also be invaluable in answering the inevitable question – “Why did we do that?”

 

The start point is to load each requirement as a separate Confluence page; this approach means that you can link to individual requirements using the page URL but also provides a ready-made folder to hold related content. This has an initial overhead in loading the requirement pages but provides lots of advantages downstream, so its well worth the effort; we managed to load in excess of 800 requirements for one contract.

You may be thinking why not use a table embedded in Confluence page to hold all the requirements but this is hard to manage and you cannot easily address each requirement.

 

Tip – Setup Subject Areas

Setup a subject area hierarchy in Confluence and file requirements appropriately, this will facilitate creating views of subsets of requirements using the ancestor filter option in the reporting macro.

 

Trace Requirements

Add at least one trace for each requirement, one for each feature impacted by the change or new feature that will need to be developed.

In parallel, features can be added to the wiki, again as separate pages – one per feature; it does not matter that the feature page has little content at this stage, the aim is to have a place holder that is ready to receive content and will allow everything to start to become joined up.

If the feature is already in place, then you can just plug in the link in the trace page and you are ready to move forward.

Tip – Identify Impacts

Each impact will need a separate trace, however traces can be grouped together for delivery as a single story. Trace pages are filed as child pages to the parent requirement, so everything is kept together.

 

Advertisement

 

Validate the Solution

Validate the proposed feature changes with the Product Owner and SME’s, this is achieved using workshops and reviewing the trace page content and adding clarifications to pages during the sessions, so everything is up to date and immediately available to the team.

The sort of points to consider are – does the Product Owner agree with the introduction of a new feature or a change to an existing feature, are there better options to consider such as buying a third part add-in; these kinds of questions need to be answered before moving into a more detailed analysis of the requirements.

 

Tip – Agree Solution

Stories to be written are agreed before they are actually written to reduce the risk of wasted effort.

At this stage a story title may be added as a reminder to the author of what needs to be covered, this will then be replaced with the URL to the story page once it has been created.

 

The Collaboration Solution

I’m guessing by now people will be wondering how on earth will all those requirement, feature and trace pages be manageable once they have been loaded into Confluence.

This is where you can use a feature of Confluence known as the Decision macro, at first glance it does not appear to offer much – the ability to create logs of decisions to manage, so each decision is a separate page but you get a consolidated view that pulls them together – a bit like a spreadsheet.

The next step is to realise that requirements, traces and features are really just decisions – a decision to request a feature in a product, to deliver a product feature using an agile user story etc. The nice thing about decision pages is that they can be customised, we devised templates for each type of decision – requirement, trace, feature etc. So now we have logs of all our requirements, traces and features but each can be managed separately as a Confluence wiki page.

 

Tip – Setup Filters

Logs can become quite large, so the solution we adopted was to use the requirement subject areas to create filtered views that only included traces for a particular branch.

 

Create User Stories

Write the user story content to fulfil the requirements including the detailed process flows and business rules.

As stories may relate to multiple requirements they are filed in a separate branch and not under a specific requirement, they are still linked back to the requirement via the trace pages.

 

Tip – Story Content

Add as little or as much content to ensure that the requirement will be met including process flows and business rules.

This is more effective than trying to develop business rules once sprints have started.

User stories may be grouped together where a lot of stories need to be managed.

 

Validate User Stories

Check the proposed changes with SME’s, are the business rules correct, you may include mock-ups of user interfaces to facilitate the process and give context to the proposed changes.

 

Tip – Workshops

Workshops can be used to present user stories prior to development to mitigate the risk of the wrong solution being delivered.

 

Conclusion

Finally, we created a Jira ticket for each story and link it to the Confluence story page; Confluence is a better tool for content than Jira but they are both only one click away from each other. Click on the Jira link in the story page and you are taken to the Jira ticket and similarly you can navigate back from Jira to the Confluence story.

In fact, you can navigate right back to the requirement(s) behind each story, all the links will be setup and ready to use with no additional effort.

Don’t forget to update your feature pages with the story releases – cut and paste job mainly; otherwise, you will need to read through all the stories for a given feature, in chronological sequence, just to find out what it is currently meant to be doing in production!

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)