We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion
BPM
user-pic

What is the most important aspect of BPM that enterprises often overlook?

Vote 2 Votes
What is the most important aspect of BPM that enterprises often overlook?

14 Replies

| Add a Reply
  • One of the most overlooked issues is the demotivation of people arising from never-ending projects.
    People expect to see tangible results within reasonable timeframes.
    Agile approaches in project management and BPM software deployment are crucial. We have seen this extensively in our projects, where early prototypes and interactive discussions keep the project and the people lively and engaged.
    People don't care about models, procedures, or plans. Care about being considered.

  • I agree with Marco. And what I find as the primary cause of such BPM projects are process that are too big to be managed well or stabilized. By such processes, I mean those that cover multiple department, many layers of management, although they may target the single end objective, they have to fight many a non-functional battle in getting it right.

  • Agree with Marco, but what makes these projects (besides being endless), disappointing is lack of understanding what it really means to manage your organization by process.

    Many companies start Lean projects, BPMS implementations, Compliance things without basic understanding of MbP.

    Of course I don't forbid that, but it might end up with process improvements on the wrong level of process (to small) or indeed endless projects because of a wrong (to large) view of process. They must be aware that process is not a goal. it's a means.

    So diving in to deep, to fast, might seem like going fast (we created 20 'has been' process models in 1 week!) but in the end you might end up with a lot of wasted time and money.

    mmm....waste...what methodology tries to delete that...

  • user-pic

    Two things come to mind, first, strong executive sponsorship and engagement to ensure that the BPM project gets the attention it deserves and secondly, controlling the scope, too many time initial success leads to more piling on of areas of scope, which becomes more difficult to manage and deliver the expected results.

  • Forgetting that at the heart of any BPM initiaitve there are people and there are processes, not applications and executives. It's an ongoing misconception that executive buy-in is the most important factor when 9 times out of 10 BPM will fail in the real world because the other 99% of the enterprise were never brought on the journey.

    Educate and engage.

  • I think one of the most important things is understanding what your company culture is- are you traditional, involvement, process, cross functional or matrix? Once you know that you know what kinds of successes or challenges you can expect with business process improvement, and where you should start. My blog expands on this: http://bit.ly/LEs2IF

  • I have to agree with Theo on this one, one of the biggest mistakes I have seen is the project not involving those who will actually be using the process, those on the front line are not being brough int. To do this correctly you need them involved from the start and their buy in is just as important as executive buy in.

  • Two things:

    1. The role of BPM in the demise of packaged apps, as further discussed here.

    2. BPM's contribution to employee engagement, as suggested above by Marco and further discussed here.

    Each of these areas has the potential to impact—even revolutionize—the BPM-driven business; and yet, they are rarely on the enterprise radar.

  • Perhaps a different take on the question.

    Visibility.

    For many organisations, all knowledge work is tracked in spreadsheets and email so basically no one knows how much stuff needs done by who or when its due.

    Understanding this simple equation can be the difference between great execution and operational failure.

  • I agree with a few folks above, change management is the key to BPM success, not just executive's buy-in, but also the staff's engagement, the culture of improvement, sharing and how to amplify the small win into large scope. thanks.

  • Some key oversights in my opinion are:


    Process Actors: The relationship between process owner, process expert and process users is not really a working relationship. More than likely, the relationship is just a tick in the checklist. The relationship has to be embedded , energised and empowered in order to drive process performance and business value


    Process Alignment: In many circumstances, the so called business processes are largely based on systems steps. In order to release the full value of business processes, it has to be truly a business processes aligning business good practices, non system steps, behaviour requirements and process metrics/outcome


    Enterprise process: In more situation than one, business processes mainly stack up vertically rather than unfold horizontally. The landscape must be truly seamless and joined up between functions. Transparent environment is not created with managed accountability and clear touch points underpinned by metrics

  • Some great comments by knowledgeable practitioners and evangelists for business process management technology! Now I will add my take on Peter's question concerning "the most important aspect of BPM that enterprises often overlook". My point of view is informed by my role in selling middleware and BPM technology, so I have an interest in identifying the roadblocks to BPM technology adoption. We are likely all participating in this discussion because we hold high expectations for BPM technology, although those expectations are salted with a decade's experience that BPM adoption has been slower than anticipated. So, what "aspects of BPM" do enterprises overlook that perhaps retard the adoption of BPM technology?

    I suggest that there are three key aspects of BPM technology adoption that are overlooked by enterprises. And by "overlooked", I am suggesting that these three challenges have not been solved, and are overlooked in greater or lesser degree. These three challenges are:

    1. Governance: Several commentators here have identified the governance challenge, i.e. that a BPM project often or even usually crosses organizational boundaries, and that either by failing to acknowledge that reality or to allocate sufficient resources to address the inherent complexity of cross-boundary processes, standalone BPM projects are less successful than hoped. And the specific reasons may be both political (i.e. no senior executive sponsorship from all affected organizations) and/or technical. My own view on this is that significant progress in BPM adoption will have to come from top-level business leadership, the same leadership that in the 80's and 90's sponsored ERP adoption. BPM is so strategically central to any organization that only total organizational commitment will make widespread BPM adoption possible. (It's a discussion for another time on how top level executive commitment is even possible, given that BPM is not a "product" like ERP. It's a sort of "chicken or the egg" problem . . . ).

    2. Master Data Management: The MDM problem lurks behind any BPM project. (And interestingly enough, the problem is now likely even worse because of the loss of the "MDM" acronym to the "mobile data management" space!) The MDM problem, which I have characterized as the "chaotic sea of data", is both a problem of complexity and a problem of culture. Where complexity is concerned, it is much more difficult to build cross-functional business processes when there are multiple and slightly incompatible definitions of even fundamental things as "human being name". But beyond the technical question, it's not uncommon to find process-oriented champions to be less than enthusiastic or even knowledgeable about the importance of good data and good data modelling. Process and data go together; process technology, like "object technology" a decade ago, is not a substitute for good data.

    3. BPM Technological Maturity: Bruce Silver has highlighted the BPM validation issue. I will go further and state that BPM rhetoric around process modelling and business processes is wonderfully seductive, but the reality when business analysts and developers ramp up their first projects can be a surprise. The reality of BPM is that the use of BPM modelling and execution technology is not straightforward, except for the simplest of processes. The really exciting business processes which might be candidates for BPM technology are also likely to highlight today's technology limitations. To understand the BPM technological maturity issue, you can look under the hood of the BPM technology engine and find that tokens, task state and graph resolution are not yet fully productized, or you can talk with business analysts and developers who have to compensate with all sorts of "best practices", otherwise known as "workarounds". In either case we have a less-than-mature technology where the gap between hope and reality is wider than expected.

    As several writers on eBizQ have pointed out, especially in the context of the disaggregation of ERP and packaged applications, BPM is very likely to be a central business technology of the future. My own view is that "business is about work, and that BPM technology is the technology that directly addresses that work". Let's keep the focus and keep working on the challenges that when addressed will make adoption of BPM technology easier.

  • That little word at the very beginning - Business.

    So many companies (and software vendors) see BPM as an IT thing.

    But business people don't know how to describe what they are and could be doing in IT terms.

    So IT gets a bad brief.

    Then they run off with it, without continuing to involve Business.
    They go all the way to coach stage without having really worked out what the business is trying to do.

    So when it comes back it is not what business was expecting.

    No-one has buy-in so it is resisted tooth and nail (change resistors have had plenty of time to raise roadblocks).

    End result is a fight, rather than a collaborative improvement.

    It doesn't have to be that way.
    We run a lean iterative process. We have the first iteration in days then drive it with new iterations every other day. That keeps everyone working together on how to improve this iteration (not creating one of their own) and that generates buy-in for whatever they eventually agree.

    The end result is value within weeks, not years. And no fisticuffs either!

  • Interesting MDM is raised. Surely a BPM driven project must supply quality data as required. BPM is the focus on people and their process the MDM is about having some reliable way to collect the correct data “lurking” somewhere in legacy amongst many versions of the truth! In such projects at the enterprise level MDM becomes an absolute requirement. The two working together are constituents of any "Modernisation" initiative but should result in a good ROI leading to next generation systems - evolution not revolution?

Add a Reply

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT