Jim Sinur
This is always a Catch-22. Those getting started with BPM want to know about the pitfalls. Those who have made mistakes don’t necessarily want to air their dirty laundry. So how about this? Tell us about the worst practices a “friend in another company” has made. What did the “friend” do, what was the consequence? What happened to the BPM program? In hindsight, what would have been a better practice? How could you recognize this might be happening to you? Respond to this blog or feel free to contact me directly at elise.olding@gartner.com – just in case your “friend” might be sensitive about their context!
Category: BPM Business Process Improvement Tags: BPM, Business Process Improvement
1 response so far ↓
1 Brian Reale June 14, 2009 at 8:43 pm
Most BPM implementations tend to start with a solution implementation. In other words, a company is acquiring a BPM solution first to address a particular process problem and later to apply it to “other” processes in the company.
We see the same mistake time and time again when trying to implement this first “solution.” Many customers just want to dive in and start building their process. After all, BPM products (like ProcessMaker) are so easy that you can just start building with zero need for code. So, if it is that simple, then that means the customer should just be able to knock out his process and that’s it, right?
Wrong.
I speak and write the English language pretty well (I’m a native speaker
, but if I am about to write my graduate thesis, I don’t just start writing it. First I plan it. I write an outline. I draw up coherent notes. I organize the notes. I get feedback on the notes (very important step!). And THEN i start writing. As a student, I often remember getting lazy and wanting to skip this step. The end result was invariably the same – a thesis that just didn’t make that much sense, wandered, and could have been much better had I just taken the time in the planning phase.
After many years of doing ProcessMaker BPM implementations, we have fine tuned a methodology for successful implementations based first on creating a detailed SOW (Statement of Work). Small-to-Midsized companies often want to skip this step, claiming that they don’t have the budget. If they insist, then we tell them that we do not wish to be involved in the project consulting. They can still use ProcessMaker (it is free and open source after all), but we won’t involve our consulting team on the project.
It is as simple as that.
We’ve found that the old adage holds true – an ounce of planning is worth its weight in gold. Although the SOW may seem like an unneeded project cost, skipping it will always come back to bite you later …right in the wallet where it hurts the most.