As businesses continue to turn to BPM and SOA for increased efficiency and effectiveness of their business processes, many are still missing the mark. There are various approaches that can either make or break an engagement.
Many organizations often make common mistakes such as buying software first or trying to solve all of their problems with one product. At the same time, some organizations are getting it right the first time by starting with process discovery and taking a holistic approach to optimizing their business challenges.
Successful execution of any BPM project ultimately comes down to a number of factors and the market has matured to a point where we can learn from past mistakes and institute best practices. Let's explore some of the best and worst practices in BPM and SOA.
Worst practices
1. Buying software first
The worst mistake any organization can make is to start a BPM/SOA initiative by evaluating and purchasing software first. Avoid this at all costs, as very few organizations actually know what type of software they need and fewer still are able to properly implement the software they ultimately purchase.
In fact, most initiatives that start with a product purchase are owned by the IT group and result in bottom-up advocacy and implementation strategy. This causes a disconnect from the strategic goals of the business, because the tendency is to be more focused on the technology than the process or business need. Taking the software-focused approach could also lead to potential failure of the project and reduce the ROI benefits of the product.
IT groups at most organizations are necessarily technology centric. As such, their worldview is influenced by the lenses of the glasses they are currently wearing. The result is that IT will purchase what they consider to be the best software and then will shoe-horn the business processes into that technology.
Making processes match off-the-shelf software is tantamount to letting someone else run your business. The correct approach is to properly design and architect a BPM/SOA solution that matches your business and process needs. This cannot be done if you purchase software before completing a comprehensive analysis and discovery effort.
2. Discounting organizational change effort
Most people are change-averse. They don't like change and they avoid it at all costs, even in the face of easier and better solutions. This may not be rational, but it is a well-documented defense mechanism that all users come by naturally.
Do not discount this tendency and wait until late in the implementation of a BPM/SOA solution to deal with it, otherwise the project will most certainly face significant resistance from users. This is the old adage that if one fails to plan they should plan to fail.
Users must be approached about and coached through the change that comes with BPM/SOA systems from the beginning of the project. If users are properly engaged and provided the opportunity to review, comment upon, validate and help make decisions about the new processes and systems being put into place then they will internalize these changes and accept them.
Without this inclusive approach, users may have a tendency to revolt and potentially find ways to work around a perfectly good solution. Organizational change must be faced up front. All change is either evolutionary or revolutionary and good implementation teams start the evolutionary change process from day one of their projects.
3. Trying to "boil the ocean"
Do not try to implement a BPM/SOA solution for an entire business group or division as one massive upgrade or roll out. BPM and SOA efforts are both inherently evolutionary in that they are best implemented in small, constrained, and frequent capability releases that grow upon each other. Capabilities should be rolled out iteratively in a controlled manner. Processes and services should be independently managed and implemented such that they provide immediate value to their user communities.
Trying to over-engineer and micromanage the development of all processes within a single implementation effort is futile, as requirements will change and both the development team and user community will become frustrated and disenfranchised. The best advice is to do the hard things first and implement functionality in the smallest increments as possible, one process or service at a time. This is often hard to do, but successful implementation teams find ways to come as close as possible.
Best practices
1. It all begins at discovery
The number one failure of most BPM/SOA initiatives is to start throwing a technology solution together before there is a clear understanding of the problem. Implementation teams with battle scars will be quick to tell you that Analysis & Discovery are at least 40 percent of the project effort, and if this does not appear to be the case, then you need to go back and start over. Accurately defining the processes being managed and documenting the service contracts (WSDL files and data schemas) should be the first and most significant aspect of any implementation initiative.
Once an accurate and clearly documented Process Specification (i.e. business requirements) has been validated, signed and approved by your client or partner organization, then and only then should a team begin development and prototyping. This practice also has the added advantage in that it facilitates the generation of an inventory of both business services (provided to customers) and IT services (provided to business) that can then be managed according to a governance structure appropriate for the organization.
2. Approach BPM and SOA together as a composite solution
BPM and SOA are not things that can be purchased and implemented. They are strategies and techniques that are utilized to solve some fairly common and ubiquitous problems within business. They also happen to be well supported by technology platforms.
But, woe to the wayward fool who mistakes the technology for the solution. They are most powerful and effective when considered as a composite solution to a complex problem.
BPM suites are very effective integration tools, especially if there is a need to integrate both humans and computer systems into a consolidated solution. However, they are not effective as the core logic processors. They should be treated as glorified Turk machines that automate known scenarios and facilitate the handling of exception cases by allowing people to make informed decisions.
Web services and SOA technologies are great mechanisms to provide code reuse and interoperability between both computer systems/platforms and organizations. However, developing web services simply for the sake of having an SOA is completely unnecessary and ultimately will result in frail and brittle systems. Utilized and implemented together, BPM and SOA enable an implementation team to realize a Process Centric approach, which actually facilitates real organizational goals and solves real business problems.
3. Start with a mission-critical process
Start with a single mission-critical business process that will recognize identifiable and quantifiable value. Ideally, an organization should select a process that is directly customer focused and does not have an obvious solution. Experience shows that this is the most effective way to acquire upfront buy-in and responsibility from an executive sponsor and a business champion with process ownership. This will result in the implementation being owned by the business group(s) within the organization and not become the responsibility of the Information Technology team.
All business processes must have an owner/steward that is part of the business group responsible for the process. IT cannot own business processes and should not own the implementation thereof. Also, working with a complex, mission-critical process will force all participants to appreciate that there will be exception scenarios, which must be dispositioned by a real person. This approach will alleviate the tendency to over-engineer the process.
There is no such thing as a perfect process. Do not over-engineer solutions to handle every permutation -- this is what people are really good at and is what customers expect.
The bottom line is that there is no silver bullet when it comes to BPM and SOA. Implementing these best practices and avoiding the worst ones still does not guarantee success as each situation is unique and must be looked at objectively.
By developing the right process first, the organization will be able to identify technologies that specifically suit the needs of the process and align them with the business goals for optimal results. The key to improving operational and enterprise performance is having a strong, repeatable process in place that achieves the desired gains. Only when organizations recognize that changing business processes takes time and invest the effort in getting it right the first time, will they truly gain competitive advantage and be positioned for success.
|
