Good article on SearchCIO.com last week. The first paragraph points out the challenges:? lack of internal resources, and internal politics.? The second paragraph brings up another: complexity.? Of course the article goes on to point out that the challenges are worth it, because the rewards are significant and measurable.
The points are a bit obvious:? BPM is "new" in IT circles, relative to other technologies in use.? It also is a bit "different" in that it isn't just a new programming language (in fact, it *isn't* a new programming language), but if done right, it requires a different way of doing things, in that some of the traditional boundaries between the business and the folks who write code for a living are broken down.? It also tends to require a little more agility from the integration specialists and database specialists than traditional application development efforts. The approach is closer to an Agile development approach than a traditional software development approach (although I'm not big on the particular religions of software development methodologies, Agile is at least a close proximity to the implementation style you want to adopt).
Finally, BPM isn't something the kids are learning in college.? Hiring someone fresh out of school (graduate or undergraduate) isn't how you jump-start your BPM expertise, as you might have previously jump-started your Java expertise or Ruby or Rails expertise.? With BPM, you might or might not use those technologies, but the skills and knowledge you need to have a handle on include:
- Process Mapping
- Staging / Incremental Improvement
- Technical prowess for web services, thin or thick user interfaces, Java API's, XML, Databases
The complexity of deploying BPM often comes from the cross-department, cross-functional nature of the projects.? The typical analogy is that the process is the elephant and each group within the process is like the blind man feeling their part of the elephant and trying to guess what the whole process looks like.? We have to get these constituents into the room and complete the picture.
The lack of internal staff with these skills or experiences is most likely because these kinds of cross-department and cross-function projects are rarely embarked on.? Most of the members of your IT and Business teams may not have worked on such a project (and their previous experience may have made them gun-shy).? That's the time to pull in some outside experience- and if you can get both generalized experience with BPM projects, and specific-vendor experience, from the same outside firm, then so much the better.? You'll be better served by firms that aren't interested in backing up the bus and unloading a whole bunch of consultants, if you're goal is to have a core competency in Business Process roll-outs, or BPM.? Instead, you'll want to find firms that will augment your team, will reduce your risk, and will be available for the long-term, on your terms, to assist your process efforts.? In our experience, most companies start with one project, and then expand to two or three parallel projects in the next iteration.? So, even as internal staff are getting ramped up, the need to leverage outside expertise across those projects (risk mitigation) actually increases at that point, even while the percentage of outside help relative to internal resources actually declines as the internal expertise builds up.
If your organization is one that outsources non-core competencies, and BPM is not a core competency, then you can also work with a firm who will staff up as you need more work done, and stand down as your work winds down.? At BP3 we're interested in business continuity contracts where we maintain a long-term relationship with our customers and help them through high- and low- tides both with initial development as well as ongoing maintenance and support.? Doubtless we're not the only ones interested in providing this kind of white-glove service.