A question that asks for the wrong answer, and an Answer that doesn't address the right Question.
- A Question:? "Is this project a good fit for BPM?"
- An Answer:? "This isn't a good fit for BPM."
First, let's talk about the question, and let's think about it in terms of process rather than project.? BPM is good for processes.? Not just some processes, but processes generally.? The real question that should be answered is "What is the process?" Define the process in terms of what it does for the business.? Don't define the process in terms of what it does with an incoming system event, or in terms of what a single user community does with some data.? Define the process in terms of how you:
- service your customers
- fulfill your demand
- respond to exceptions or challenges
- meet service level agreements
- create delighted customers and renewable business
- recognize revenue
(These are just a few ideas... )
If you can re-orient your thinking from the "project" or the "application" to really thinking about the process, you won't question whether it is a good fit for BPM, that will be obvious.? BPM is a good fit for processes, and if you want to manage your processes, you need some BPM!
The answer/statement: "This isn't a good fit for BPM."? When I hear someone say that, the following ideas run through my head:
- They haven't found the process that their project is intended to serve, or
- The BPMS they have doesn't lend itself to a clean representation and implementation of their process, or
- They just shined the light on their process and discovered all the ugly parts that were hidden in the boiler room.? Now they are feeling like it is barely a process at all, just a jumbled pile of exceptions connected by spaghetti.
To the first point:? Find your process.?? Broaden your scope if you must, to consider what happens before your "project" starts (almost every project has inputs - follow the inputs - where do they come from? how did they get created?? who / what is responsible for that?? how do they impact my project/process?), and consider what happens after (who receives my outputs, where do they go and what impacts do my outputs have on their project/process/applications/users).
To the second point:? Just because your BPMS doesn't represent the problem well doesn't make it not a process, or not a good fit for BPM.? Let's distinguish between a software package's shortcomings and a shortcoming of the concepts embodied by BPM.? The software part is still evolving and improving.? In the meantime, there are going to be gaps.? These can be resolved or patched without abandoning the benefits of BPM.
To the third point:? If you haven't been managing your projects and applications as key processes that support your business, of course there is a scary boiler room down there in the basement.? Take the time to extract process out of that mess, or else find a way to leverage the boiler room as a black box, with a nice tidy interface (think, electrical wall sockets) that let's you design higher level process around this one area.? Come back and clean up the boiler room when you can show that by having a better result out of that black box will yield benefits (after all, with BPM, you'll be able to measure the inputs and measurable outputs and timing and count data... and infer what could be improved without even knowing the inner workings)...
So, when I hear these things, I know we have a chance to help our customers realize an opportunity to look at their problem or project differently and yield the benefits of a BPM approach.? We've seen lots of data entry applications that lose sight of the fact that they are interacting with and altering the state of a real process with customer value.? Its really gratifying to see the value we can extract out of this change in perspective, and our CEO, Lance Gibbs, is one of the best in the business at this kind of out-of-the-box thinking (I've had the good fortune to be in the room with him on several occasions when such eureka moments have happened).? If you're using BPM and you think you've got a bum deal on your process, take a step back and see if you can't find the process there, the real process, which your project is meant to service...