The Difference Between Thorough and Complete in Business Process Modeling
Apr/01/2024 Filed in: Process Engineering
A business process flowchart alone does not represent a thorough business process model. A thorough business process model is one that illustrates and specifies all of the relevant details of a process. While a good flowchart can communicate many process details, other types of content can detail or present information more effectively, efficiently, or purpose-driven.
The type of audience or consumer of the business process model is the criteria for determining what is relevant. If one of the objectives of the business process model is to provide value for the widest range of audiences, then an illustration and specification framework should be used to guide the business process model developers.
Complete is most often used to describe an end state; a state of being. It implies done, finished, to have progressed from a starting point to a stopping point. It’s challenged or proven with a “yes-or-no” measurement. Either the person has stopped working or not. Either the end has been reached, or not. Either the job is complete, or not.
Thus, a flowchart could be considered “complete” if it only shows a starting event (“trigger”), a series of tasks, and an ending event. In the purest sense, the level of detail (thoroughness) is irrelevant to completeness.
If we study the dictionary definitions, synonyms, and antonyms of the words thorough and complete, we can distill them down to some working references in the context of business process modeling.
I often think of complete as a state of being, a status, a condition, situation or milestone. Whereas, I think of thorough as a measure of quality, depth, extent, or scope.
One comparison I read makes a lot of sense:
As an example of thoroughness in business process modeling is the information that can be specified in a Logical Business Data Dictionary. In the Process1st Business Process Blueprint documentation framework, the Logical Business Data Dictionary is a set of tables that identify and specify every business data object, each business data object’s properties (fields) and the full set of allowed values for each business data object property.
The type of audience or consumer of the business process model is the criteria for determining what is relevant. If one of the objectives of the business process model is to provide value for the widest range of audiences, then an illustration and specification framework should be used to guide the business process model developers.
Complete is most often used to describe an end state; a state of being. It implies done, finished, to have progressed from a starting point to a stopping point. It’s challenged or proven with a “yes-or-no” measurement. Either the person has stopped working or not. Either the end has been reached, or not. Either the job is complete, or not.
Thus, a flowchart could be considered “complete” if it only shows a starting event (“trigger”), a series of tasks, and an ending event. In the purest sense, the level of detail (thoroughness) is irrelevant to completeness.
If we study the dictionary definitions, synonyms, and antonyms of the words thorough and complete, we can distill them down to some working references in the context of business process modeling.
I often think of complete as a state of being, a status, a condition, situation or milestone. Whereas, I think of thorough as a measure of quality, depth, extent, or scope.
One comparison I read makes a lot of sense:
“One difference is that “thorough” is most often used to modify verbs, while “complete” can be used to modify both verbs and nouns. Example: “He gave the kitchen a thorough/complete cleaning.” Here, either is OK. But you (usually) would not use “thorough” to modify a noun. Example: “My son has a complete set of Pokémon cards.” You would not use “thorough” for this sentence.”
As an example of thoroughness in business process modeling is the information that can be specified in a Logical Business Data Dictionary. In the Process1st Business Process Blueprint documentation framework, the Logical Business Data Dictionary is a set of tables that identify and specify every business data object, each business data object’s properties (fields) and the full set of allowed values for each business data object property.