Information-Management.com: This new survey on business modeling and mapping follows up an initial survey you conducted in 2009 on the same topic. Over the last three years, what has been the biggest change you’ve seen in adoption of these tools?
Mark McGregor: On one hand, we were seeing more and more people using specialist tools for the process modeling and mapping, or so we thought. When we started digging in, we realized more and more people aren’t using the modeling tools. They are using the mapping capabilities. There is some crossover, but to get the best value out of these tools, you need to be modeling with them, not just mapping. If you are spending a lot of money on a modeling tool and just doing mapping with it, then, surprise, surprise, you don’t find the value you were promised.
Is it something where there is a lack of knowledge with the users about these tools? Or are people just doing more quick-and-dirty work on the mapping side? Maybe a little bit of both?
Sure, there is some nuance to each use case. But a large proportion of the process mapping is occurring within operational excellence and that kind of work. Those are also the users who are making the least use of the modeling tools. The modeling tool vendors are very much focused on support for business analysts, but they’re still mainly working with an IT audience. I think there is a real mismatch between where the majority of work on process mapping is occurring, and the mainstream developing technology.
There is a negative connotation of mapping and especially modeling when it comes to ROI in the survey. Thirty-two percent of end users reported less-than-expected returns from modeling tools. In a separate question, enterprises that did find success from use were also those paid the most. With only so much control over what they get from vendors, what can enterprise IT do to tap into more direct results and, thus, support from business?
One thing the users need to do is ask themselves the question: Are you contributing to the waste that you’re trying to solve at your organization? In other words, if someone is already doing process analysis and these guys are coming in saying you have to look at it from their perspective, that’s just contributing to waste. Users need to work together in an enterprise. It’s not about following a religion of a particular process method. It’s about working end-to-end to take out waste.
The mapping people could work together and find out that someone has already done it. And if they don’t stop arguing about who wants what to run left-to-right and actually go back and talk to the workers about how they want to use it, this stuff isn’t going to be of any use at all. If you want to get business adoption, make sure what is being produced is being used, particularly in the mapping area. Maps are often used for analysis and then thrown away. Maybe that can be part of the end system. The modeling tools are more complex, take more time to use and are more expensive. But part of that complexity is that their design demands it be linked to the production process. It’s using the same resources. Unless you have all of those resources together and interconnected, then you can’t actually perform good business analysis or risk analysis or impacts of change. Simplistic maps are great for the early stages but they’re not providing the longevity. They need a more sophisticated approach.
And what’s the vendors’ role in this modeling conundrum?
It would be handy if some of the vendors recognized that people want to start simply and then grow from there. In many instances, there’s a bucket-load of tool implementation that takes up your first few months, when what you want to do is deliver your first project outcomes. It’s easier to get that groundwork done when other people understand the value. If you start by burning through $50,000 on consulting just to get all of the tools up and running, you’ll frighten the business side away. Here is a way to work together to understand modeling value. The vendors, over the years, have added more and more into the products to make them more architectural or applicable to other groups. But they’ve lost their way. If you had a product that users loved for doing one particular thing, and then you pile on all of these other functions, you lose your core audience. It’s fine to have those functions in the later stages, but keep it simple early on.