BPR Done Right

Four Roads to Effective Business Process Re-engineering

There have been many approaches to BPR over the years. Some have been successful; some not so successful. In the end, successful approaches have used one or more of the following four techniques:

  1. Process Decomposition (top-down process analysis). What are your generic processes? How are they allocated in the business architecture? What are the inputs, outputs, controls and mechanisms on each process? What needs to be fixed? Decompose and repeat until processes are understandable at a basic level. The IDEF0 standard applies here.
  2. Scenario-driven (bottom up process analysis). Subject Matter Experts in facilitated work session answer the questions step-by-step: What do you do? And then what do you do? And why do you do it? And how how can we do it better? Analysts then factor out redundancies and clarify identified improvements.
  3. Actor-based decomposition of roles and responsibilities. What roles are played in you organization? What do they do? Why do they do it? How can they do it better? Essentially this techniques is play on the CRC card approach to object-oriented requirements development.
  4. Product Decomposition. What Results do you create? Why do you create them? Do you really need them? Do you need to do them better? What intermediate results are needed to get to the final results?

Depending on your need and internal skill set, any and all of the four approaches can work. In the end, my approach is to to work with you to decide the best combination of the four approaches to use. The goal however will be a consistent result regardless of initial approach. We will develop a “requirements baseline” consisting of scripted scenarios and linked requirements written in consistent language that can be used to for business transformation. Those scenarios and requirements will also provide business level software requirements needed to govern any any software development and/or software acquisition needed to support that transformation.

For software we transition directly the Iconix Software Development Process. I have found it simply to be the best way to hang requirements onto software architecture in a way that results in working systems that that actually meet requirements. I have been in the business 30 years. There is simply no better way.

The business transformation opportunity from our BPR results will be even more exciting. The concept is fairly simple. We can help you match human, machine, and computing tasks and process steps onto a business structural architecture following steps that are analogous to the Iconix software process. The result will be transformation of business structure into a lean, well performing modular organization. Think of the concept as object-oriented organization development. Intrigued? Let me lay it out for you.

Comments are closed.