The Gartner webinar that I dropped in on yesterday had some interesting points about modelling and methodologies that started me thinking.
First, on methodologies: it’s absolutely essential to have some best practices to lend structure to your BPM project. Don’t do this alone, get the help of someone like me (okay, it doesn’t have to be me) who has actually implemented BPM projects before. Whenever you change a business process, there’s a whole lot more than just technology going on, and you don’t want to get caught in the classic IT trap of believing that the business users will be just as excited about the new technology as you are (remember, they didn’t get to play with the Java code).
There were comments in yesterday’s webinar about how the soft benefits are becoming more significant, including internal factors such as real-time business agility and a process-focussed culture. However, you can’t expect your organization to change because of the introduction of BPM technology; instead, your organization needs to make cultural changes driven by business factors and enabled by the technology.
On modelling tools, I made the statement last month that most people are using Visio to model their business processes before they are implemented in a BPM system, which is true. However, just because it’s true doesn’t mean that it’s the best way to do this. If you use a standard modelling notation such as BPMN or UML activity diagrams, you’ll do fine up to a point with Visio, but somewhere along the way to your “to be” process, you’re going to need a more serious tool for process simulation and the like. If you check out the BPtrends report on modelling tools that I reviewed last week, you’ll see a lot more tools with a lot more power than Visio for your process modelling and analysis. You’re not going to put these on everyone’s desktop, but they are needed for a few analysts who will be doing the in-depth process design.