The goal of using Lean processes in IT is to eliminate waste and focus on value-added features. Using them in conjunction with a business process management (BPM) methodology, therefore, allows companies to focus more on maximizing value and minimizing waste in BPM projects.
Leveraging Lean processes can help an organization keep its BPM initiative on track, according to Clay Richardson, a senior analyst at Forrester Research Inc. Here, Richardson outlines three shifts midmarket companies can make to begin using Lean BPM.
1. Allow flexible, not just standardized, processes.
The traditional BPM methodology has always been about standardizing processes and structuring the steps you take to modify or implement new processes. However, in today's business climate, CIOs need to be more flexible and allow for ad hoc and unstructured process workflow when using BPM, advised Richardson.
"It's all about allowing the people who deal with the processes day in and day out to have more control over what happens," said Richardson.
BPM tools that offer ad hoc workflow capabilities are key to taking BPM technology to the next level, he said. Vendors such as HandySoft Global Corp. now offer ad hoc features in their BPM tool offerings. Pricing for this type of tool ranges from $30,000 to $50,000 for 20 to 50 users. But for companies that can't stretch their budgets for an investment in formal BPM software, Microsoft SharePoint is a low-cost alternative for workflow and collaboration.
The key to being flexible with BPM is to allow each person in the process to add value while the process is being built. An ad hoc ...
To continue reading for free, register below or login
To read more you must become a member of SearchCIO-Midmarket.com
tool lets developers enable a less structured sequence of steps during the process development. For instance, using ad hoc tools allows the person building the process to track it, determine who to push the next step to and assign a time frame based on that person's workload and other factors. In traditional BPM, the schedule for each step is determined at the outset of the project.
2. Shift the BPM project focus from ROI to value.
"The issue people face when investing in BPM technology is that they have to have an ROI story," said Richardson. Moving forward into the new economy, IT organizations should focus on the value of BPM, not just the potential for ROI, he advised.
CIOs should focus more on identifying the key strategic objectives where they can automate or attach BPM technology to add value to the business. To do this, Richardson highly recommends cloud computing. "Moving into the cloud is essential for midmarket companies looking at BPM," said Richardson.
Cloud computing makes cost less of an issue. Therefore, CIOs can cost effectively implement BPM and prove its value. Then when they're looking for more money for other BPM projects, cost and ROI won't be as much of an issue -- because they've been able to prove its value through past implementations. Therefore, the value should outweigh the cost concerns.
The cloud is more cost effective for midmarket organizations with tighter budgets and resources. Instead of spending $200,000 to $300,000 on a robust BPM software implementation, a company can pay an average of $30 per person, per month to try BPM technology in the cloud.
Some CIOs, however, are concerned with moving to the cloud because of the sense of loss of control. But Richardson advises that the beauty of putting BPM technology in the cloud at first is that you can always bring it back in house.
3. Use agile instead of waterfall development processes for BPM.
For the midmarket CIO, the agile development methodology is more cost efficient and less risky to use for BPM than the waterfall method, according to Richardson. Agile matches up well with the BPM methodology because they both focus on continuous improvement.
"If you're using waterfall and at the end of the project realize that it's not what the business wanted, you've wasted money," said Richardson. Agile has checkpoints along the way and allows developers to make sure the business is getting what they want in each iteration of the project.
Another issue that midmarket organizations could face in using the waterfall development methodology vs. agile is resource availability. The assumption with waterfall is that the resources that you start the project with will be there for the life of the project. In today's economy, you don't always know how long you're going to have money and resources, cautioned Richardson.
For instance, assume you're using the waterfall method for a typical project that will take six to nine months. Halfway through development, your budget gets cut. This stalls and may stop the project completely. With agile, there are iterative releases every two to three weeks. Even if the budget gets cut during the project, you will still have rolled out usable features. "Agile forces the teams to build usable code that is not fully dependent on the next iteration," said Richardson.
Let us know what you think about the story; email Karen Guglielmo, Executive Editor, or follow her on Twitter @kgugl.
