Most organizations today have projects – either in progress or already completed – to define and document the business processes for their different activities. This documentation is often a base for IT when they develop and maintain the operational systems, and also explains to the business community how to conduct business.

Today, processes are defined mainly for operational activities and less so for decision support or business intelligence (BI). Until now, the purpose of BI has been to provide maximum freedom to the business analysts, without defining processes on how to conduct business analyses. These BI activities have been on a level above the operational activities in the sense that a company can survive for some time without analyzing its activities. However, if the operational systems are switched off, the business usually stops immediately.

There is a growing movement by BI users to standardize BI processes as well. The purpose of spreading the process thinking to the BI area is often different compared to the traditional operational business. Whereas operational processes are there to ensure that the business runs correctly, the purpose of BI processes is rather to improve and ease information exchange between the members of the business community.

No matter what the business processes are – whether they are for order entry, a production process, an analytical process or something else – they need to be reviewed regularly. These reviews will tell if the processes are adapted to the business activities and, in particular, if the systems handling the processes are developed properly for this work. The reviews will tell, on a more detailed level, if the existing processes are correctly implemented, having the quality and acceptance required in order for the business to run correctly. It may be that the processes have been redefined but the IT department has not had time to adapt the systems correctly. This may result in problems for the business community, forcing them to find their own tricks and fixes in order to enter data into the operational systems. IT is usually not informed about these data entries that do not conform to the business processes defined in the system. A liberal adherence to fixed business processes may eventually cause quality problems in the systems used for implementing these processes.

Therefore, business process quality reviews need to be conducted regularly. These reviews will show how adapted the systems are for the different business processes, regardless of whether they are used for sales orders, procurement, BI, etc. A poor adherence to defined business processes may cause all kinds of problems – poor stock inventory, bad planning for future activities, and unhappy customers and employees.

Conducting Business Process Quality Analyses

Business process quality analyses can be relatively easy, especially when the processes are already known and documented. If this is not the case, the analyses can be a tool for defining the processes used by the organization and thereby aid in creation of the documentation. The business process quality analyses should be automated, saved, reused and versioned in order to be optimal for the present and the future.

The first step recommended when conducting a process quality analysis is to break the process into its smaller components ­ its business rules. Several business rules (for example, a rule stating that product X can only be sold with product Y) constitute a business process such as order entry. The business rules are hopefully documented with the process, even though it is often difficult to define all the business rules because they can be quite numerous. They are, however, the basis for a correct process management.

Business Rule Types

Business rules, whether they state what can be done or what is not allowed, may be of three kinds:

  1. Known and implemented in a system. When this is the case, there are usually warning messages when data not conforming to these business rules is entered into the systems. In some cases, the entry may even be blocked.
  2. Known, but not implemented. This is typically the situation when the business develops faster than the IT systems that support the business. In these cases, there are no automatic warnings when data that does not conform to these known business rules is entered into the system.
  3. Unknown and, therefore, not knowingly implemented in the IT systems that support the business. For these informal rules, there are certainly not any automatic data entry controls in the systems. Also, these unknown rules usually only work as long as they are not conflicting with the restrictions of known and implemented business rules. An unknown rule may be something taken for granted by the business community and, therefore, not even formally considered (e.g., a rule that no product is sold with more than a 50 percent discount). These business rules may also indicate an important aspect of how business is actually conducted, regardless of what is stated in the formally defined business rules.

Whatever the type of business rule, it may not be certain that it is correctly followed by the business community or by the IT systems. The business rule may, in reality, allow for erroneous transactions.

Business Rule Analysis Types

The purpose of business process quality analyses is to find the business rules in a process and also to see if the business rules are being implemented correctly. There are two kinds of business rule analyses:

  1. Directed business rule analyses, where errors are sought in known business rules. SQL queries are elaborated to find transactions with data values that do not conform to the defined business rules. Each SQL query should correspond to a single and complete business rule, and each known business rule should be represented by a SQL query. These analyses must also take into account the context of the data. Data values for a data category may be correct when combined with some other data category, but not allowed when combined with another data category. A practical example would be that salesperson 1 can sell product X only in region BBB, whereas salesperson 2 can sell product X outside region BBB.
  2. Undirected business rule analyses, where the analyses will find the unknown business rules. These unknown rules may be permitted from a business point of view and used by the business community. The undirected analyses cannot be done with SQL, as one does not know what to look for. This type of analysis is instead done with rule-detection software which automatically finds business rules in a data set, even if these rules are unknown. Once the unknown business rules have been identified, SQL queries are defined to find any exceptions to the unknown rules that are nevertheless accepted by the business. In other words, the unknown business rules are now known, and faulty transactions are identified as in the directed business rule analyses. Some rule detection software can also find exceptions and possible errors to unknown business rules.

Even though rule detection software can be used for both the directed and the undirected business rule analyses, it is strongly recommended that SQL be used for the directed analyses. This will be useful later for putting automatic controls in place, something that is done most easily with SQL. Rule detection software comes in all flavors and prices, but there is good basic software that starts at prices as low as $1,400. This kind of software is very good not only for finding unknown business rules, but also helpful when documenting a process containing unknown and undocumented rules.
In order to present the results of the business process analyses, the different types of business rules can be placed in the process quality quadrant as shown in Figure 1. All found business rules have been numbered or coded. Business rules that are not completely followed by the business community or the IT systems are noted in red, whether they were known or not when the analyses were conducted. On the other hand, well-followed business rules with no faulty transactions are noted in green. The more business rules in green in the upper right square, the better the quality for the implemented complete process. This shows that the organization's systems are well-adapted to the business process and also that the included business rules are followed.


Figure 1: Process Quality Quadrant

Furthermore, it is not possible to knowingly implement unknown business rules; therefore, the upper left square in the process quality quadrant is grayed out. The process quality quadrant will tell if the process's business rules are known and correctly implemented; however, it will not tell if the process is sound from a business perspective (for example, optimizing product quality, profit or customer satisfaction).

Maintaining Business Process Quality

Once the business rules analyses have been done, the results must be analyzed to decide how to make the corrections. All known and accepted business rules have to be implemented and documented, and nonconforming data has to be corrected. It also must be decided whether or not to keep the business rules not previously defined or known. If they are kept, the IT systems and documentation must be updated.

Whether or not the business rules are followed also depends on the ease of use of the system. If the user interface is unclear, making it difficult to enter data correctly, the business community will try shortcuts when working with the system. This will almost certainly result in broken business rules because no matter how well a system is adapted to its processes, the imagination of the business community is endless. They will often find ways to simplify their work, working around what seem to them to be difficult or illogical obstacles in IT systems.

As it is difficult to have a system that is foolproof and 100-percent correct, the process quality reviews must be conducted regularly. A repository for the SQL queries used for the directed business rule analyses should be created. These SQL queries also have to be versioned whenever there are changes to them. The result of the undirected analyses should be translated into SQL where, for example, found unknown but valid business rules will in the next analysis be part of the SQL- based directed business rule analyses.

The SQL queries should always be run in order to find data errors in known business rules, looking for anything not conforming to the defined business rules. If there are no results to the query, so much the better, as this means that no known business rules are broken.

As more analyses are conducted, the quality of the process under control will increase. This also means that the SQL repository will grow over time, taking into account more and more known business rules that need to be regularly verified. On the other hand, the workload for the automatic rule- detection software will decrease, as there will be fewer and fewer unknown business rules to find.

It is important to realize that business process quality control is tightly linked to regular data quality controls. If the data fields under analysis contain data that is erroneous, this is not necessarily taken into account by the rule detection software. For example, if there are enough existences of the birth date 01011900, this may be considered a normal value by the rule detection software, even though this date may be a default date when the real one is not known. Empty fields may cause even more problems when validating business rules as they may not provide any information when, in fact, they should. A business process quality control is only as good as the underlying data quality. Basic data quality is still the basis for everything that uses data, whether it is operational systems, BI applications or process control systems.

Once the basic process is in place for the process quality control, it can be further developed. SQL queries can be triggered automatically whenever some specific data deemed to be of greater importance is included in the rule-detection software analysis result. These queries could then create reports with statistics on when, where and how often this data occurs and in what context (business rules, possible errors, etc.). SQL queries can also be triggered to find and also possibly correct deviations reported by the rule-detection software. With some rule- detection software, it is also possible to automatically correct erroneous data in the business rules.

Improved Quality

Non- working processes in an organization risk hampering its development. The result may be loss of revenue and/or increased costs. The analyses described in this article will help improve the quality of the business processes. The results for each business process analysis can be presented in the process quality quadrant, easily understood by both IT and the business community. The quadrant will provide an immediate indication of how reliable the business process is by taking into account the quality of the business rules in the process.

A good control of what is occurring in the business will further develop the business activities and allow changes to be made more easily. The more known the business processes are, the fewer the unpleasant surprises there will be when adapting the IT systems and the business routines to new situations. It is critical to understand that improvement and maintenance of an implemented system is just as important as the original implementation itself. Otherwise, the system will become outdated, rendering it less useful. Also, any process analysis and its detailed business rules analyses are dependent on the underlying data quality. Good data quality will facilitate the business process quality analyses, and good processes will improve business.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access