Resolved
0 votes
Mike Kavis raised the point about agile in this article. But what about BPM, and what's the best way to minimize these differences?
Tuesday, February 11 2014, 09:55 AM
Share this post:
Responses (13)
  • Accepted Answer

    Tuesday, February 11 2014, 10:12 AM - #Permalink
    Resolved
    1 votes
    "IT is from Mars, Business is from Venus." 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.
    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Eli Stutz
    Eli Stutz
    Offline
    Tuesday, February 11 2014, 10:19 AM - #Permalink
    Resolved
    0 votes
    Here's what I think: http://www.pnmsoft.com/wp-content/uploads/2012/09/Funny-Business-Biz-and-IT-Tug-o-War-C.jpg 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.
    • Patrick Lujan
      more than a month ago
      #entarch and others have been telling us for well over a decade that IT should align WITH and SUPPORT the business. This is an old saw and I can't believe this perspective is still being offered up. Every org I've been at since the turn of the century upholds and pursues the view of supporting the business. It is our raison d'etre.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, February 11 2014, 10:30 AM - #Permalink
    Resolved
    1 votes
    Leaving aside the specific question about agile for the moment, it's interesting to think about different perspectives on BPM in IT and the business. Historically, process improvement paradigms—TQM, BPRE,Six Sigma,OpEx—have acted as euphemisms for "staff reduction". BPM is, inter alia,a process improvement strategy, and it does bring with it the promise of greater efficiencies. 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 enhance employee engagement 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.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, February 11 2014, 10:37 AM - #Permalink
    Resolved
    1 votes
    I think the difference is, IT usually thinks about BPM(S) as: "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.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, February 11 2014, 10:39 AM - #Permalink
    Resolved
    1 votes
    I think the business doesn't think about a definition for BPM at all, which absolutely doesn't mean they don't care about their processes. 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.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, February 11 2014, 11:14 AM - #Permalink
    Resolved
    1 votes
    I think Keith is about to chime in with a link to the BPM definition :)
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, February 11 2014, 11:37 AM - #Permalink
    Resolved
    4 votes
    Yes, business and IT often have completely different understanding and expectations about BPM. I love Theo's Mars/Venus analogy, as well as Eli's tug of war artwork. It doesn't stop there; I have cataloged dozens of different interpretations of BPM. That is why we spent so much time last month isolating the one common definition for 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.
    Like
    2
    • Scott Francis
      more than a month ago
      i feel vindicated in my prediction :)
    • E Scott Menter
      more than a month ago
      This last point is exactly right. Customers can be surprisingly naive about the trade-offs required in order to rationalize a business process. (I say "rationalize" rather than "automate" because the statement is true even if BPM or other technology isn't involved).

      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.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, February 11 2014, 12:03 PM - #Permalink
    Resolved
    2 votes
    I have found that "business" generally thinks about solving a problem (better visibility, greater efficiency, ensured compliance) while "IT" generally thinks about finding a tool with specific features and functionality. 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.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, February 11 2014, 02:04 PM - #Permalink
    Resolved
    1 votes
    BPM was an "IT" tag that acknowledged the relevance of the "discipline" of thinking people and process. It was of course over hyped in the early days so business really saw it sitting in the "IT" domain and probably still does? BUT once business realise that it is now possible to quickly deliver digitally what they require and understand how it works then they and users really do "get it" BUT do they see it as "BPM"? Not really they shrug their shoulders if that TLA means something to IT fine BUT let's just do it! 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.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, February 11 2014, 02:38 PM - #Permalink
    Resolved
    3 votes
    I am glad that we, finally, noticed that architecture is the key. People do not expect that a builder will make (automagically) their dream house – people know that they need an architect. The same in any creative work – first ask the architect then hire the builder. The same with BPM – the business and IT will continue to have their different understandings of BPM – it is for the architect to provide a "bridge". (An architect is a person who translates a customer’s requirements into a viable plan and guides others in its execution.) Maybe we should consider third (forgotten) BPM? - http://improving-bpm-systems.blogspot.fr/2009/04/should-we-consider-third-forgotten-bpm.html Thanks, AS
    Like
    1
    • Michal Rykiert
      more than a month ago
      I love the term "automagically"!
    • David Chassels
      more than a month ago
      You are helping to place the role of the architect. Historically the "enterprise architect" has really been the cause of so many failures in big projects as they focused too much on systems and not on users and outcomes. I agree that someone needs to advise as you described. This requires knowledge of the possible (just like a building architect) and as you say to plan the BPM Solutions interfacing with “IT” and orchestrate existing systems as required. However the actual build using BPM Platforms should be driven by business analysts skill sets that focus on users and their needs to achieve the required outcomes in their language.
    The reply is currently minimized Show
  • Accepted Answer

    Ian Gotts
    Ian Gotts
    Offline
    Wednesday, February 12 2014, 06:23 PM - #Permalink
    Resolved
    -1 votes
    Sadly it is not just IT and Business, but also BPM vendors and compliance. These 4 groups all say BPM and think they know what they mean, but their perspective is different from everyone else's. 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
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, February 13 2014, 01:48 AM - #Permalink
    Resolved
    1 votes
    In the near future the IT contribution to BPM will be: securing a reliable internet connection. I am looking forward to that.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, February 19 2014, 12:55 PM - #Permalink
    Resolved
    0 votes
    The answer to this question is embedded in the very fact that we still talk about "the business" and "information technology" as though they are two separate entities. That's your answer right there. Of course they have different views of what BPM is. Despite how long people have been preaching the need to "unite the tribes" and get away from this business/IT dichotomy, we still aren't there. 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.
    The reply is currently minimized Show
Your Reply

Join the Discussion

Want to join the discussion?

Login, or create an account to participate in the forum.

Top Participants

Dr Alexander Samarin
276 Replies
25/09/2016
David Chassels
269 Replies
23/09/2016
Emiel Kelly
220 Replies
23/09/2016
Bogdan Nafornita
209 Replies
25/09/2016
E Scott Menter
182 Replies
23/09/2016