Iterative Business Process Decomposition (IBPD)™ ²

Iterative Business Process Decomposition (IBPD)™ ² 2017-05-24T14:45:14+00:00

WTG’s alternative to the traditional Business Impact Analysis (BIA) does everything a BIA does—but it does it faster, less expensively, more accurately and with less impact on your staff. More importantly, our IBPD identifies mission critical processes, upstream and downstream dependencies, recovery requisites, Inherent Criticalities™, Resultant Criticalities™, Need/Need+/Need- solutions, Riser Warnings™, Break Points™, Acceptable Risk Points™ and other key NextGen Level 2 data that traditional BIAs don’t even acknowledge exist. Without this data, it is impossible to design the most proportionate and operationally-effective recovery solutions.

The IBPD focuses on business process analysis and borrows techniques from process modeling disciplines to quickly create an accurate view of your critical applications and business process flows. It then becomes a relatively simple effort to map the critical processes to applications and, ultimately, to infrastructure hardware and other recovery requisites. The advantage of the IBPD over a traditional BIA is that we arrive at the RTO and RPO by understanding workflow interactions, as opposed to forcing relatively abstract estimates of loss.


Learn More About WTG’s Executive IBPD

More and more companies inherently acknowledge the need for disaster recovery and business continuity planning. As such, they often forego the details of the Business Impact Analysis (BIA). Others refresh their BIA information every two or three years. In either case, the time and cost of a full-blown needs/impact analysis is often not necessary.


Learn More About WTG’s IBPD (BIA) / Needs Analysis Refresh

The rate of change in business today is staggering. In fact, most organizations change so rapidly that the old model of refreshing your BIA every two or three years can leave you at risk. In fact, it’s even worse than that. You can be at risk and paying too much at the same time. New processes must be incorporated into your program when they become important to the organization, not when the next BIA happens to get scheduled. And conversely, old needs get eliminated and/or new, more cost-effective solutions become available.

Our IBPD tool simplifies the process dramatically while concurrently improving accuracy because it “calculates” many of the answers automatically. The entire process usually takes less than 10 minutes per business process even though much more granular information is revealed compared to a traditional approach. It’s the best of both worlds…the accuracy and effectiveness of individual interviews with the speed and simplicity of an automated tool.

While the coarse estimates arrived at with a BIA are usually sufficient for typical planning efforts, a much more accurate view is required to define the absolute smallest recovery footprint and to achieve the correspondingly smallest expense outlay. The IBPD is the ideal foundation for all continuity planning efforts and defines the capability required in terms business decision-makers can understand. It also serves as a permanent benchmark for future application development, system integration, training and business process improvement initiatives and becomes a functioning part of your recovery plan at time of disaster.


WTG Overview

We created the first formal recovery planning methodology, which is still the basis for most methodologies in the industry today and the basis of most practitioner certifications. We built and managed one of the world’s largest recovery facilities and developed the infrastructures and operating procedures used in the current generation of commercial hot sites.

Read More




WTG has developed a best practice approach that defines mission-critical applications, second and third level interactions, upstream and downstream dependencies, recovery requisites, data integrity requirements, recovery sequences and solution architectures better than any form of traditional Business Impact Analysis (BIA).

Read More

White Paper

The BIA’s Fatal Flaws

The goal of a traditional BIA is sound in theory—to identify and prioritize the business’ critical processes relative to the losses that would result from their interruption. However, in practice, this process repeatedly fails to produce the desired results and in virtually every instance we have seen, delays and complicates the recovery planning process.

Read More

Schedule A Free Demo Today


The William Travis Group, Inc.
1827 Walden Square, Suite 220
Schaumburg, Illinois 60173-4294
P: 847.303.0055 | F: 847.303.0378

NextGen 360° ABC Breakthroughs

We believe that it is time for a change!

The William Travis Group, Inc.

Dump Your BIA!

It’s time for a faster, more accurate, less expensive approach that actually reduces your DR/BC costs.

The goal of a traditional BIA is sound in theory—to identify and prioritize the business’ critical processes relative to the losses that would result from their interruption, and then, to convince management to fund the most cost- and operationally-effective architecture to recover those processes in the aftermath of a disaster.

However, in practice, the BIA process repeatedly fails to produce the desired results and in virtually every instance we have seen, it delays and complicates the recovery planning process.

Read More…

Request a Quote


What is a Business Process?

A Business Process is a single, complete, logical business function that a department performs.

● For example, if the department was called Accounting, then the business processes might be: accounts payable, accounts receivable, general ledger, tax prep, financial reporting (even though each of these processes have many individual components) If the department was called Accounts Payable, then the processes might be smaller and called vendor maintenance, invoice reconciliation, invoice approval, payment processing.

● The fundamental difference for our purposes is the overall size of the department in terms of number of staff. If there were 200 – 300 people in the department, then we would tend to break it into sub-departments called Accounts Payable, Accounts Receivable, Tax Reporting, Financial Reporting, etc., each with their own processes as described above. The reason is that the large number of people will have a great impact on the amount of recovery requisites needed (workstations, applications, connectivity, etc.), and as such, the more granular analysis will enable more granular solution planning. Conversely, if there were only 5 – 10 people addressing the entire function, we would tend to label it as Accounting and name the business processes Accounts Payable, Accounts Receivable, Tax Reporting, Financial Reporting since 5 – 10 people will not have a great impact on recovery requisites regardless of how they are allocate.

The general rule we use this to decide where to draw the line is that a “Department” should have no more than 10 business processes and typically no more than 100 people per process. If it does, then it should probably be broken down into sub-departments each with their own smaller processes. However, this is a rule of thumb at best. In the end, two things are important:

● Regardless of how departments and processes are defined, it should “feel right” to the business proponents and mirror the actual operation of their unit.

● Regardless of how the departments and process are estimated in advance, the actual interview process will validate the decision and adjust it on the fly if and when needed.

Featured Posts