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.
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.
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
Example of artifacts only within a flow: Project management plan
Example of mixing attributes and artifacts within a flow: User access request
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.