How to Capture Objects Within a Business Process Model

How do you document objects in a process model? To fully reap the benefits of proper process documentation, it can be vital to ensure that objects are captured. Down the line, analysts should be able to rather quickly gather insights, such as, where are specific documents produced within a sequence of activities? What roles are responsible for certain pieces of information? Developers should be able to put together a conceptual model, if required.

The term “object” in this case refers to data that is used to complete an activity or data that is created as the outcome of an activity. This can be used interchangeably with terms like deliverable, work product, work product part, artifact, attribute, among others. In simple terms, what information is input to an activity and what information is output as a result?

Terminology will likely change depending on who (organization or team) and what (software application, operational procedures, etc.) is being modeled. If objects are represented correctly and accurately within a process model, they can be used to assemble a high level data flow visualization.

General Guidelines

Don’t include the state of the object in its name

The state, or status, of an object at a given point in a process flow should not be included in the name itself, rather it should be included as an attribute of the object. If data is being mined from the process at a later point in time, it’s easier to find all references to object A, than dealing with translating and consolidating multiple versions of object A based on a state used in the name.

Object State Within Process Model

Be able to provide an example

Providing an example is an excellent way to give the consumer of the process a better context of the object. It also ensure that the content being modeled is realistic and not something made up. When developing new systems, features, etc. it is useful to utilize prototyping or mock-up tools to give developers and engineers a better idea of what their customers are expecting. Something as simple as an Excel file with header names and sample data can provide value.

Artifacts vs. Attributes

When speaking on the granularity in which objects are modeled in a process, the terms artifact and attribute can be used to distinguish between two levels of classification. Attribute is used to represent a singular value. For example, a name or an address. An Artifact is a summation of attributes. For example, something like a user profile containing multiple pieces of information around an individual person.

Usage of artifacts and attributes can vary in a process model depending on what the model represents and who the intended audience or customers are. 


Example of attributes only within a flow: Data feed between two applications

Application consuming data flow

Example of artifacts only within a flow: Project management plan

Project Management Plan Workflow

Example of mixing attributes and artifacts within a flow: User access request 

User Access Request Process Flow


You can document objects in a business process model as inputs and outputs of activities. A way to handle granularity of objects in a model is to classify each as being either an artifact or an attribute. It’s possible to include both artifacts and attributes in a single process model when it makes sense for the consumer. When documented correctly, groups should have a better understanding of how data is flowing throughout their processes.

How Do You Document Roles and Responsibilities?

How can you best document roles and responsibilities in such a way that provides value to those involved? To start, we need to understand what value can be provided by creating such a document. Then, we can make a decision on the best way to represent it. Whether we are are dealing with an established business unit within a large firm, or we’re discussing a project team in a growing company. There’s good reason to provide clarity in documentation to all parties involved in the business processes. 

Why do it?

For ongoing operations: When a new hire enters the company or an existing employee transfers to a new position, how do they know what the position entails?

    • Value: ensure work is executed consistently across people performing the same role

For new developments: When a project team is formed, how does each member know where they fit in at?

    • Value: plan is laid out ahead of time to assess workloads and avoid conflicts during project execution

It’s important to keep in mind that roles and responsibilities are just one aspect of an overall business process model. Documenting them should be done in a way that can be easily linked into other forms of documentation.


The involvement level, or responsibility, that an individual role has on a given activity can be described in many different ways. Wikipedia has a nice article breaking down numerous alternatives. For the following examples, let’s use RASI (responsible, approving, supporting, informed).

      • Responsible (R): Who is ultimately responsible for the completion of the activity? If deliverables are late or not completed, who is getting a phone call?
      • Approving (A): Does someone need to approve of the work completed in the activity in order for the outputs to be used in subsequent activities?
      • Supporting (S): Who can help out? Possibly a subject matter expert, or additional labor?
      • Informed (I): Who needs to know that the activity has been completed?

Let’s take a look at two different methods, or formats of documenting roles and responsibilities. The first is a Responsibility Matrix (the variation RACI Chart is often used in project management), and the second is a Role Responsible Sheet. Both examples will cover the operational process of a hypothetical pizza company.

Roles and Responsibilities Documentation Example 1: Responsibility Matrix

A responsibility matrix is a great resource for showing how roles and activities are related. Roles are listed across the horizontal axis at the top of the table and activities are listed down the vertical axis in the first column on the left. The intersection points between the activities and roles represents the involvement level of the role in the activity, denoted by the designated letter. If an intersection cell is blank, the role has no involvement in the activity.

In the following example, we can interpret from the row labeled “Make Pizza”, that the administrator and manager provide support (S) for this activity, while the Chef is responsible (R), and the delivery driver is informed (I).


  • Quickly tell by role what involvement is needed for each activity
  • Provides a process(es) at a glace view


  • No clear way to show activity dependencies
  • Limited information for specific roles involved in process

Roles and Responsibilities Documentation Example 2: Role Responsible Sheet

In this example, a role responsible sheet is shown for the “administrator” role. This is the same role that is represented in the first column of the responsibility matrix in the first example. Everything in this form is specific to the role that it’s filled out for, so additional fields could be added beyond relationships to activities. To show some of the flexibility, we’ve added an “Objects Produced” and a “Training Required” field, specific to the role.

Role Responsibility Sheet


  • Tailored view for an individual person
  • Can include additional information for roles that isn’t available in other documentation sources


  • Difficult to integrate with other documents for a “bigger picture” perspective


It’s important to have some form of documentation for roles and their respective responsibilities. This will help to ensure, among other benefits, that consistent work is being done between multiple people performing the same role, workloads are being assessed more accurately, and employee conflicts are being avoided. Roles can be and are expressed in many forms of process documentation. However, tools such as responsibility matrices and role responsible sheets scale well relative to graphical, process-flow, styled charts.

Why Should Business Processes Be Documented?

Knowledge Transfer, Training, and Collaborative Continuous Improvement 

The rate at which employees are voluntarily quitting their jobs has steadily increased since the last economic recession, according to the Bureau of Labor Statistics Job Openings and Labor Turnover Survey. With this increase in turnover rates , it is important that the knowledge of skilled workers leaves their brains and is stored somewhere in a format that can be picked up and quickly consumed by new hires (or internal candidates new to the role).

United States Job Quits Rate vs Job Openings Rate, source: Bureau of Labor Statistics, visualization detail:

 The Feedback Loop

Once the process documentation is developed, it is critical that it is stored and presented in such a way that is accessible for process operators. This should allow for a feedback loop from the operators that are trained using the documentation to the guardians of the documents. These two ideas have a direct correlation towards continuous improvement efforts. The more accessible the process documentation is, the more operators will use it in training and later as reference material, leading to more feedback. Thus providing the opportunity for improvements based on user input.

Process Documentation Feedback Flow

Information System Development

Dealing with multiple stakeholders who are all speaking separate languages (figuratively) can be frustrating at the initiation of a software development project, all the way through closure. This pain can be alleviated with business processes that allow for all stakeholders to come together in discussing requirements. Process models can show who should be doing what and when should they be doing it, leaving as little in the “grey area” as possible.

In a study by PMI (Project Management Institute) in 2017, it was noted that 39% of projects failed due to “inaccurate requirements gathering”. This was the second highest cause of failure behind changes in organizational priorities (something that would generally be out of the project team’s hands). One way to combat against this risk is to use process models as requirements documents. Well-documented process models should provide an overview of data flows and system expectations.

Process Documentation in System Development Lifecycle (SDLC)


Clear process documentation allows for performance assessments to be generated rather quickly. Metrics should be used to measure the success of the process as outlined. Operators of the process must provide evidence of their execution to the documentation, which ensures the methods defined by experts are followed. This should prevent missed steps and lead to an overall increase in the quality of the given product or service.

It can be a tough sell to convince some that they should take the time to define their work and others to strictly follow it, but when taking a step back, it is easy to see a direct correlation between process and product.

Audit and Compliance

Depending on the industry, firm’s may be subject to strict regulations requiring proof of compliance to industry standards, such as those published by ISO (International Organization for Standardization).  According to ISO, consumers can be sure that
“products are safe, reliable and of good quality” when companies are compliant with standards. When business processes are defined in a consistent manner, it becomes much simpler to map to these standards or reference models.

Reference Model Gap Analysis Example

What is a Business Process?


Business Process Model Elements

In a broad sense, the term process can be described as a set of related activities needed to be completed to achieve a specific goal or outcome. A process becomes a business process when the activities are performed by business unit(s) within an organization in support of the firm’s goals and objectives.

Everything that we do as individuals can be broken down into a process, from simple tasks such as requesting a change to an existing product to complex undertakings like orchestrating the development of a new software application. Let’s take the first example given and attempt to decompose it into something tangible.


Actions taken that produce value in reaching a goal. When starting to outline a process, the first step should be to identify what the objective or desired outcome is. This ensures that as the model is built, unwanted activities can be cut out and as a result money can be saved. As activities are actions, they should be labeled as such with a leading verb. I.e. create, develop, submit, review.

Business Process Model Activity Flow

Roles and Responsibilities

Who are all of the individuals involved in the execution of activities in the process. Who is ultimately responsible for the completion of the activity? Who needs to know about it? Who can help out? Answering each of these questions is important to building a strong process model. It ensures all “players” be included as the processes are rolled out and executed. In turn, the operators performing the processes are able to provide the feedback needed for continuous improvement efforts.

Business Process Model Example Roles


Objects in the context of process can be any piece(s) of data that is used to complete an activity or data that is created as the outcome of an activity. What forms need to be filled in throughout the lifecycle of the process? What are the documents that provide evidence of the work being completed?

Putting it Together: Business Process Model

A business process model is the result of putting all of the elements (activities, roles, objects) together that make up a process in a graphical representation. There are many different forms and business process modeling standards such as BPMN (Business Process Model and Notation), however the idea behind each is relatively similar. Create something that is easily comprehended among stakeholders of the process.


Business Process Model Example

Video Summary and Example Walkthrough