How to Build Better Applications with Business Process Management (
Page 1 of 3 )
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.