The folks over at ebizQ have started up a discussion on Best Practices when getting started with BPM. A couple of good responses from other folks so far, each one reflecting a bit about that person's background or interpretation of "getting started" ! (Is getting started the point at which you decide BPM makes sense for your business? or the point at which you decide to evaluate BPM? Is it pre-vendor-selection or post-vendor-selection? ... etc. )
I wrote a quick response last night (taking advantage of the free wireless promotion on American Airlines - thanks gogoinflight! (Incidentally, as much as it might seem like work/internet is invading one of the last places where you might have some thoughts to yourself, it really does make the time go by faster on the plane when you are connected).
Following is my off-the-cuff response to the topic, also posted on ebizQ:
There are so many best practices to consider. But I think if you are truly "just starting" with BPM, it is important to coalesce a core, multi-disciplined team to spearhead your early efforts. It will be important to invest in this team your vision:
- for the business
- for the business process management that will support that business
- for the role of this new BPM team in enabling that vision....
And that investment needs formal and informal time, group time and individual one-on-one time. This is the time to practice some of that L thing - Leadership. Take your team to lunch. Get to know them, make sure that they share your values at least regarding this endeavor. Hold whiteboard sessions to explain your approach, rather than just emailing out powerpoints (yuck).
Now. Who should be on that team?
- Business SME (subject matter expert)
- BPMS expert (expert in the tool)
- (if #1 or #2 don't have it, get someone with some Process Improvement expertise)
- Integration expert
- Project manager
- Sponsor (um, likely that's you)
- Executive sponsor (someone who can go to bat for you, if you're not an executive)
- Add people to the team as it becomes clear what capabilities you'll need. Add carefully. The first few people you pick are crucial.
You can have more than 1 of these, and you might have one person who plays more than one role, but you really can't accept part-time contributions for the core team unless THIS is their first priority (outside of the exec sponsor). If they can drop everything else to help you, then you can accept their help. But if they have something else that is first priority, odds are that they will leave you hanging when you need them most. That doesn't work for BPM.
In particular, why our own integration expert? because integration teams are notoriously the long pole in the tent for most BPM projects (and often BPM projects are required to go through whatever the current integration orthodoxy is). BPM tools provide good integration tool sets, but the software they integrate with has to be prepared to hold up the other end of the bargain - and that's what takes so much time.? The integrations BPM projects require aren't hard, but the integration teams are likely working on the "5 year plan" and your BPM pilot project is definitely not on that plan.
If you have the right people, and direction, you're probably halfway there. Now get to work :)