IT think process automation, process mining, workflow.
Business think workflow, process mapping, an unnecessary evil with no ROI.
Note, more often than not there's a commonality that both still view BPM as 'workflow', not in the advanced terms we use today. Lots of education to still be done, and perhaps that's where we should start from, a common point of reference rather than try to waste time educating with two different stories.
However there's a killer point in the article that can be translated for BPM.
Agility should be measured in the eyes of the customer.
So too then must BPM. And the customer is that common reference point for both IT and Business.
But seriously, Business and IT may have a different view, but they need to learn to cooperate in order to make things work. Actually their views can complement one another. Business can bring the "bottom line" view, a more goal oriented approach, and IT can bring in the "lets get real" factor, define what's actually attainable technology-wise, and help both sides get there.
Head of Knowledge and Collaboration, PNMsoft
- Patrick Lujan
- 3 years ago
However, BPM is a lot more than just a cost savings measure. BPM offers greater insight into your whole business, paving the way for new ideas and even new products. It enables you to overcome those famous institutional silos, while at the same time offering new ways to reach and retain your customers. BPM can even <a href="http://www.ebizq.net/blogs/bpm_view/2011/11/bpm-and-employee-engagement.php">enhance employee engagement</a> within your organization.
Sometimes it's IT that recognizes these special qualities of BPM, and sometimes it's the business itself. It's a matter of thinking about BPM as an enabling technology and not just something that helps avoid paper or email. Fortunately, good ideas can come from any part of the organization, and overall the industry is getting better at helping non-technical business customers recognize and understand BPM's special place in the enterprise software ecosystem.
"How big pain in the butt will it be to handle?" and "Will it deliver something at least remotely close outcomes to what business requested?"
And business usually thinks:
"How much will it cost us?" and "What will we get in return?"
Of course it's a generalization and it depends wheter IT or business see a need to implement BPMS, but this is how I see it.
IT has probably a systems view on BPM, but do you think they care about a definition?
I think the need for definitions comes from types like analysts and process consultants.
They are the furthest away from the real processes. So what's the deal?
BPM is daily business for companies. They execute their processes in their context and apply stuff that others might refer to as BPM.
But hopefully they spend most of their time on making those processes do what they promise (and I hope we could indeed coach and educate them in that) and let us here, at the forum, spend time on discussing the definition of BPM.
Business Process Management (BPM) is a discipline involving any combination of modeling, automation, execution, control, measurement and optimization of business activity flows, in support of enterprise goals, spanning systems, employees, customers and partners within and beyond the enterprise boundaries.
In my experience the business side is more aligned in general with this, and the IT side tends to have the widest divergence from this. I have attended SOA oriented conferences where a sequence of speakers consistently insisted that BPM was a programming language/method. Please visit the definition page because each word has multiple meanings, and it is possible to read this definition with the wrong word meanings and get the wrong idea.
Lets assume though that in a good organization, the IT and business sides both agree on the above definition. The referenced article still has some sage advice for us. Any time you are building a large, complex product, whether it is agile software development, or a BPM project, there are design choices made along the way that will be heart wrenching. Often this is a choice between giving the customer what they ask for, and giving them something that will be easier to maintain in the future. You might choose to offer a very intuitive way to manipulate some control by leveraging a cool browser-specific function, but then you get locked into an incredible amount of extra work getting the same thing to work across all browsers. In the end, this one feature displaces many other features because it distorted the architecture of the system.
I see the same thing in organizations all the time: you sit around a table talking about the process, and someone says: "when the X is below the value of Y, I want person 1, 2, and 3 involved, except in on the occasion of Z." This happens to be the case they handled that morning, and "availability bias" makes one over-estimate the likelihood and importance. Many times, to retain a viable project, someone needs to say "NO" to these requests -- even though they come from the customer.
How can this be? The customer asks for something, but to better satisfy the customer you have to refuse to do something? The best answer is that you do it for "architecture". In order to handle future advanced, the system has to have a logical consistency. The designer of a system must assure that consistency. The customer is not the expert in how to build the system. The architect must be responsible for that, and refuse things that would make the architecture unwieldy. The surprising conclusion: you can not simply let the customer prioritize the work tasks. Architecture is a strategic effort that will, in the long term satisfy more customer requirements, even if it means foregoing specific requests today. That is why I call it heart-wrenching.
About a year ago, I practically begged one particular customer to reconsider the approach they were taking to collect approvals at a certain stage of their process. The issue had nothing to do with the technology. But they stuck to their guns and I agreed to implement it as they'd requested. A few weeks ago, the customer returned and asked us to change the design to be exactly what I'd recommended in the first place. Why? Because at some point their compliance team got involved and immediately spotted the same issue I had (when you spend a career in financial services, compliance becomes sort of second nature).
So, back to the textbook-length discussion we were having on the previous post: that alone is a great reason why you don't want users defining for themselves how processes work, "just by doing it that way". They will "do it" the way that is most convenient or familiar to them, and not the way it necessarily needs to be done.
- E Scott Menter
- 3 years ago
Whichever the case, it is helpful to understand the business challenge that is leading to an IT solution. Explaining tools and methodology needs context to be effective.
Our experience is that "IT" remains the barrier but in fairness they are so busy keeping the lights their reaction is instinctively to resist. BUT that may be changing as the now BPM Platforms can close the interpretation gap closes between the Business and IT. This places onus on business to articulate clearly their needs direct into the build environment with business analyst skills managing the project and so the term BPM may begin a new journey in the business world? IT therefore can rely on the BPM Platforms to produce the required application BUT will provide support e.g. linking to legacy creating complex algorithms etc if required. IT’s primary job is get the communication infrastructure and security ready for deployment.
Maybe we should consider third (forgotten) BPM? - http://improving-bpm-systems.blogspot.fr/2009/04/should-we-consider-third-forgotten-bpm.html
- David Chassels
- 3 years ago
We found it REALLY useful to call these differences out and highlight them by referring to each a different group by giving them a coloured hat; Business=Green, IT=White, Vendors=Blue, Compliance=Red.
This is explored more in my blog,.. http://wp.me/pLuvX-Qi and in detail in this White Paper http://iangotts.files.wordpress.com/2010/12/nimbus-paper-bpm_hat.pdf
I am looking forward to that.
Before we can even think about having a shared understanding of what BPM is, and how it can benefit an organization, we have to change our mental models and language to reflect that Information Technology IS "the business" and "the business" IS Information Technology. IT represents the spine and the nervous system of an organization... it would be silly to act as if it is this completely detached, independent entity.
So, how to fix this? I have some thoughts on this, many of which I've written up before. I'll include a couple of links, but the quick and dirty version is this:
1. "Business" leaders need to learn more about technology
2. "Technology" leaders need to learn more about business.
To address point (2) there, I wrote up two "recommended readings" lists for IT executives a while back. I think getting our CIOs, CTOs, IT Managers and all other IT personnel to think in "business terms" is a crucial part of achieving better alignment and clarity.
3. "Capability Cases" are a great bridge between the "business world" and the "IT world". We encourage all organizations to learn this methodology and apply it to new strategic IT initiatives.
- Page :
However, you are not allowed to reply to this post.
Join the Discussion
Webinar:Your Digital Disruption Survival Plan
Thursday, July 13th @ 1:00pm Pacific/4:00pm Eastern
In this fast-paced and informative roundtable discussion, three leading experts on business process management will explore the right methods and capabilities that make difference between success and failure with enterprise process management initiatives