How to Build Better Applications with Business Process Management
When business users and the IT department work as a team to build the most valuable application possible, changes are expected and welcomed. With a partnership that is formed using this approach, the IT department is able to deliver value to the business immediately and constantly. Here, Knowledge Center Andrew Hull explains how a process-centric enterprise can use business process management to focus on processes that are strategically important to the company, putting solutions into the hands of the business side quickly and efficiently.
A recent research article revealed the greatest concerns for CEOs in 2009. The number one concern is layoffs and restructuring. Number two on the list is the need to "pare the corporate efforts down to those that are central to the company's short-term survival while not killing off its future." How well will your IT department fare when the time comes to make adjustments to the budget? The answer can be predicted depending on your response to the following questions:
1. Does your IT department deliver solutions that are critical to the strategic goals of the company?
2. How long does it take to deliver value to the business users? Can you react quickly enough to meet the tactical needs of the business?
For those of you that get a little nervous while answering either one of these questions, this article will introduce you to the delivery methodology utilized by Business Process Management (BPM), a technology that has been shown to reduce costs by 20 percent in the first year and is the number one priority for CEOs in 2009. BPM does this by focusing on processes that are strategically important to the company and putting solutions into the hands of the business side as quickly as possible.
The traditional approach
To kick off traditional IT projects, business analysts will take time from the business users to capture all the details needed to construct the final application. Then, after several months of interviews, the analysts toss a massive requirements document over the wall to the developers. The developers transcribe the requirements and begin building the application. The business is not brought back into the process until the application is close to the final release.
When the application is finally ready for release many months (or even years) later, the organization can only cross its fingers in the hope that the process that was described in the requirements document is still in practice today. At any point before or after the release has been delivered, the business users' change requests are usually met with frustration from IT because they are departures from the functionality that was agreed upon in the requirements document.