“Business process reengineering is the act of recreating a core business process with the goal of improving product output, quality, or reducing costs.”* Recently I’ve perused articles on business process reengineering and have been surprised to find that they share a lack of emphasis on data definition.
By establishing a shared business vocabulary, identifying and describing business-critical entities and events, and applying the defined entities and events in process and system design, BPR teams can ensure an efficient redesigned process that works smoothly from end to end.
In spite of data concerns making up two of the seven key BPR principles (“Merging data collection and processing units” and “Shared databases to interconnect dispersed departments”), articles on the topic tend to lump these concerns into general Information Technology topics, without acknowledging the need for business driven data definition and management. For example, this post stresses the need for “more sources of data and enhanced connectedness to information”. This one recounts a famous Ford BPR example where a new database was central to the solution. Many, like this one, cite “shared databases” as a core principle. However, none details the business leadership and participation necessary to define a common data foundation across a reengineered business process.
Imagine an insurance company seeking to speed up sales and claims processes, and generally improve customer service, through business process redesign. Perhaps the company’s history and growth by acquisition resulted in siloed sales, customer service, underwriting, and claims departments. These departments might feature various legacy systems that communicate over custom interfaces with a “great deal of third party data that is aggregated during the process relating to active claims, such as forms, letters, etc. which arrive in a variety of unstructured ways, from different sources, at different times, and at different offices.”
IT folks can stitch the polyglot systems together with point to point interfaces, an enterprise service bus, or a shared database, but regardless of technical architecture business leaders breathe life into the system by unifying definitions of key concepts and business rules.
For example, if a reengineered process encompasses sales and underwriting groups, the sales team might include in their definition of “customer” subscribers to a free email newsletter, while the underwriting team only includes policy holders as customers. The reengineering team must account for the interests of both teams in setting definitions and business rules that work across the breadth of the process, and defining how enterprise definitions should translate to integrated legacy systems. For example, the shared database might include structures for both subscribers and customers, and a database view integrating the two might serve the sales department.
Here’s how business leaders can enable unified data for business reengineering:
- Establish a shared business vocabulary
- Identify and describe business-critical entities and events
- Apply defined entities and events in process and system design
Establish a shared business vocabulary
It’s generally recognized that shared language across different departments increases their ability to work together. Business process reengineering by definition takes shared language one step further: teams can’t be expected to establish common definitions and business rules if they can’t understand each others’ jargon. Establishing “shared databases to interconnect dispersed departments” means that all interpret the data in those databases the same way.
Teams can borrow from steps Michael Rand recommends to get business reengineering teams speaking the same language:
- Generate lists of terms unique to each department
- Integrate the lists into a reengineering team vocabulary that resolves differences among the lists, whenever possible, adopting language commonly used in industry
- Throughout the reengineering effort, identify points of miscommunication and update the vocabulary as needed
Identify and describe business-critical entities and events
After agreeing on common terminology, the team can develop an understanding of the people, places, things, and events involved in the reengineered process, and how they relate to each other. The resulting high-level data model is a conceptual picture of the world in which the process operates, enabling the team to accurately define operations across the breadth of the organization, and enabling IT to build systems and databases that accurately serve those operations.
Hoberman et al, authors of the book linked above, recommend business teams work top down to describe business areas. Teams first focus on nouns defined in their integrated list of vocabulary terms. Some of those nouns denote business things and events — entities — like customer, policy, or accident. Some represent characteristics, or attributes, of those business entities, like address, value, or date.
By answering key questions about each business event and object, the team can set definitions and rules that apply across the entire business process. For example, it is possible to have a customer without knowing their address? What information is required in order to establish a policy for a customer? Which attributes of a customer are private and subject to higher security restrictions? Teams should resist the temptation to dig into too much detail at this point, but instead should focus on broad brush rules that apply across the entire process.
After understanding important things and events, the team considers relationships among them. If the consensus vocabulary includes verbs, that’s a good place to start. For example, an adjuster estimates the cost of an accident, or a customer applies for a policy.
The resulting work product is often a diagram like this one, but format doesn’t matter as long as the entities and relationships are accurately and clearly expressed. This book shows how a data model can be rendered into a set of business sentences!
In my experience, IT needn’t participate in high-level data model development. Some IT participants might open conversations about technical topics that hamper the effort by shortcutting business definition. Think of it like the difference between drawing a house plan rather than a blueprint. You wouldn’t start on a blueprint without an approved house plan, and many blueprint details are irrelevant to planning the layout of the house.
Apply defined entities and events in process and system design
With a common business vocabulary the team can design processes and systems that speak the same language end to end. And with a high level data model as a starting point, the team can ensure that different steps manage data consistently by making sure process and data designs are consistent with the high level data model.
For example, designers of a sales step can verify that their process collects sufficient data on customers to support subsequent order and fulfillment steps, and manages customers’ private data correctly. Designers of an underwriting step know that previous steps, having been designed consistently with the high level model, will have stored sufficient data describing the customer, property, and previous claims, etc.
Yes, as design progresses detailed process and data design drive changes to the high level view. However, early establishment of common terminology and insistence on consistency of details with the high level data model enable a unified process from end to end.
* Here. Their business process link.