Colloborative BPM - A new way for SOA, and Enterprise IT projects.

Last week I had the opportunity to look at the process flow diagram of one of our BPM projects. Looking at the exiting process flow it was no surprise to see a wall to wall snapshot of the long work flow diligently documented by our BPM team. We had the normal conversation of how complex our processes have become and how inefficient the existing operations are. One point that was brought up was how simple tasks have grown into complex entities due to N number of intermediate steps in them.

This made me think about the work flow presented to me. Basically I was wondering whether the complex setup I see before my eyes was developed by a dedicated team for solving a particular problem or grew by itself to solve a business requirement.

I took a piece of the work flow and started inquiring around the organization about why it is being done like that. Amazingly I had answers that were logical and reasonable that supported every twists and turns that made the flow complex. For me it looked like nothing was really amiss in the microscopic level, at the macroscopic scale I found the asynchronous nature of organizational tasks lead to all this complex work flow.

For example task A which when completed leads to task B after some time gets a new business requirement task A.1, since the implementor of task A.1 changed the original task A to be safe he added a check point C to Task A before it goes to task B.So a Simple task of going from A to B now has morphed into A to A.1 to C to B and this happens to a task cycle were there is no interplay with other enterprise components. If we take the enterprise effect into account the A.1 and C may effect processes X and Y and they may add new steps X.1 and Y.1 to solve the issues of A.1 and C

As the organization grows there are events that happen asynchronously all the time and we have a situation with an ugly looking BPM work flow chart and we have all the six sigma's and SOA architects attacking it to create simplicity and efficiency.

Now the question is after this iteration will we have a stable system that will be predictable and provide an efficient work flow for now and the future? The answer in the SOA/BPM space for that is governance. Tighter control, standardizations and process management when implemented and governed properly will provide that stability. However the after effect of tighter governance is decline of innovation, creativity and spontaneity. How does organizations will deal with this side effect of the BPM/SOA initiative. This becomes critical in a global marketplace were innovation is the competitive advantage for organizations.

Looking into my spyglass I see answer in the application of Chaos Theory in organizational development. The challenge of change management is pervasive in the BPM/SOA space for creating an agile organization receptive to change. Chaos management can provide organizations an environment that would thrive on change. Embracing chaos and constantly being on the edge is a nervous state for organizations but the payback is a creative, innovative and agile organization. So my recipe would be embrace chaos and use BPM/SOA to act as the moderator in controlling the chaos.Have loose governance, create a plan to do a BPM work flow analysis in iteration after the first run as often possible to find the instability and use SOA to manage.

Innovation with SOA and R&D, Business Perceptions and Engineering Challenges

There I was sitting in a meeting with business stake holders discussing on the next set of deliverables for a new product we have been developing for the past five months. This is a project I am involved with new business development in my company. To give a brief background, we are developing a retail reward system that is both hardware and software based. We have two dedicated teams, one for business and one for technology. The teams are small and focused on getting this done with the shortest possible time.

My this post is not on developing new product but about the relationship between the business teams and technical teams on driving the product development. As with any new product development we have fewer resources, more complex problems and tighter deadlines.

As with any new innovation project, the challenge I face everyday in the project is the uncertainty involved in solving complex engineering and technology issues. Historically in our company business for the most of the time has been dealing only with software projects, even those projects were most of the time limited to the scope of enhancing our existing applications or trans migrating our existing applications.

This product I am working on now is unique in the sense that it has hardware development and software development. As we are going through the development phases I see a expectations gap between the business and the engineering team. The complexity involved in the engineering solutions is seldom reflected in the perception of the business for a particular business requirement.

The core concern of the business is its ROI on the project and the delivery schedule. While the concerns are legitimate the problem is the expectations arising out of them are not rooted in reality. The biggest gap I see in this issue is the concept of risk management. While businesses are within their rights to demand the ROI which includes the business requirements and delivery time, as with any business investments they should also realize that they are taking up risk in their investment expecting a higher return.

When this uncertainty in engineering and technical challenges or in other words the risk in the project is brought up to the table in the form of prototype testing, tighter scoping of the business requirements, avoiding complexity by eliminating scope creep etc., business gets rattled.

We see in many blogs in EAI space the importance of ROI, especially in the BPM and SOA space we see arguments forcefully made to sell the SOA project to the business with relevant ROI. Many SOA proponents advocate that the SOA practitioner do that job of selling the project to Business with ROI. Doing this I see an agency conflict.Since it is in the benefit of the SOA practitioner to sell his goods he is going to underplay the risk involved in the project, which many times translates to direct costs in the form of change management, process correction and the need for outside resources in the form of outsourcing.

So how do we attack this gap in the Business perception of engineering challenges and bring to the table the Real Risk in ROI presented for the project. Looking through my spyglass I see some answers in financial management theory. In the CAPM model the expected rate of return for any investment takes into account the risk free return, the risk premium for the investment and the market sensitivity factor.

In our case applying the CAPM model to SOA or R&D projects we should factor in the historic success rate of IT projects in the enterprise, the risk premium associated with attempting new technology and the industry success rate for projects of similar nature (if available) for the ROI calculation . When a dialog on ROI is based on this framework, the risk factor is automatically included in the dialog and should address the gap in engineering challenges and business perceptions about it. I would welcome feedback on any other the ways to bring to the table the risk factor.

In conclusion it is not about IT department showcasing ROI of SOA, IT or R&D projects that leads to business alignment, rather it is about what kind of ROI we present and what type of dialog it initiates in the business about the project. A ROI rooted in the reality of what is the risk associated with the project and what is the expected rate of return for the business it provides will decide the true business alignment.

SOA, BPM, Six Sigma and IT Projects...what is the scope here?

The past three weeks I had a hectic training schedule. First I was in a SOA Architecture Boot camp, week later I was in a course ware on Lean Management from MIT looking at ways to accelerate process efficiency. The thing that struck me in both the courses were the involvement of Six Sigma Black belts in show casing process improvement methodologies. I had the opportunity to look at real life case studies and ask questions about them. In an economy looking at recession, it was no wonder to see all this BPM initiatives in companies looking at ways to "Cut Costs".

As expected BPM was the entry point for IT projects where some of them ended up as SOA initiatives and black belts were the enablers for those BPM projects. Looking through my spyglass (plugin for my blog) I find many Q's popping out in the landscape. There was a general distrust of the six sigma methodologies and its efficiency among the participants.

One of the points that was raised in the seminar was, the black belts definitely bring in the horsepower to do the DMA part of the DMAIC six sigma process, however when it comes to the Improve and Control piece of the process they seem to falter. They face obstacles and road blocks all the way after the DMA cycle to implement their recommendations. When I asked the black belts about the buy in from IT groups on their recommendations, all of them unanimously mentioned IT as their biggest bottle neck. For that matter one Master Black Belt told me that in his organization some of the IT managers have expressly prohibited his team members attending the BPM meetings without his permission.

One other participant put forth an interesting observation, he said "American companies in the 90's have invested a lot on the BPM initiatives and while they have gained a lot of incremental improvements only some of them has got the biggest bang for the buck and it is so late now for them to change course on this.

So after this three weeks of SOA, BP, Six Sigma and Lean... I come out with more questions than answers. Common sense tells us there is no one size fits all, at the same time companies are implementing solutions based on these tool sets which they feel will solve all of their problems. The challenge ahead is how to improve efficiency of the existing processes and at the same time create an environment that fosters innovation (this is another whole topic for a later blog). Looking through my spyglass I found one place where there was something interesting. U.S Army has embarked upon a ambitious plan to transform its business process and they have taken best of two disciplines Lean Management and Six Sigma and have attempted to chart a new course. Check it out at http://www.army.mil/ArmyBTKC/focus/cpi/tools3.htm.

Looks like Lean can partner at where six sigma falters and make it a success. The process map and variance analysis that was rigorously done by the six sigma black belts can now be made to real processes that will bring the change by using Lean Management principles. I feel IT can be a great partner in doing this phase of the BPM initiative. By involving IT in a lean initiative we can create an environment in BPM Projects where, IT groups feels that they are an important enabler of the initiative rather than just a trench warriors executing everybody's wishes. The Improve and Control part of the DMAIC can now be done through a partnership with Business, IT and the Black Belts using Lean as the tool.