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 are the costliest BPM mistakes?

Vote 0 Votes
From a discussion on the BPM Guru from LinkedIn (which requires you to join), what are the costliest BPM mistakes?

10 Replies

| Add a Reply
  • Scott is correct scope creep can be deadly.

    The costliest BPM mistake is anything that forces the organization to halt its business process optimization/BPM effort, re-evaluate, and begin again. Frankly, this is the most costly error for any enterprise initiative that involves organizational change coupled with technology components.

  • (1) Not tying BPM into other corporate initiatives (BPM in a vaccum) such as Services, EA, Continuous Improvement.
    (2) A lot of BPM projects are technology/product driven, and results in vendor driven architecture vs. a true representation of the process.
    (3) Poor metric and KPI definitions.

  • The single costliest mistake is thinking that there should be one process, when there really should be a variety. There is a built in assumption to most BPM projects to find the one best process. That one process has to work at the storefront in Beverly Hills, the suburban mall in south Chicago, and also the Heathrow duty free shop. Given different people, different contexts, and different customers there are scores of management books that will recommend tuning the business to the particular customer needs. A BPM project might waste a lot of time trying to gather from all the participants a single process, when all their experience tells them different things. Accommodating all the various legal requirements into a single process may cause bewildering complexity. I don't have any easy advice on how to avoid this situation, but one should carefully examine the assumption that one common process is needed for all, and consider what you might be giving up if you enforce a single consistent process.


    see:
    http://social-biz.org/2011/01/24/knowledge-worker-productivity-requires-autonomy/

    and:
    http://social-biz.org/2011/01/01/structure-is-in-the-eye-of-the-beholder/

  • So many ways to fail, so here are a few:

    1. Not getting started, or building the case to start
    2. Scope too big so results take too long and momentum fades
    3. Automation before mapping/discovery
    4. Letting IT turn it into their project. There is a hint in the name 'B' PM
    5. Lack of committed, not just supportive senior management. A pig is committed to a Full English Breakfast, a chicken is only supportive

  • Not considering up front to architect BPM …

    (This one mistake is enough because all the serious mistakes are made in the first day.)

    Thanks,
    AS

  • I agree with most that's been already said. However, there are three fundamental mistakes I would claim can be costliest -

    1. Treating a BPM project like a conventional IT project.
    2. Not appreciating the criticality Business-IT participation/collaboration
    3. Not acknowledging Change Management as an important enabler of success of BPM projects.

    It can be argued that these are true about non-BPM projects too. It is. Surely is.

    But with BPM the connotations are different. Less transactional, more strategic. Deeper. Wider.

    Think about it.

    • OK JV, I agree with your "three fundamental mistakes"; they are important to BPM efforts. I still think that non-BPM efforts can be considered just as strategic and transformational to the enterprise. Thus, non-BPM initiatives can be just as seriously impacted by these costly errors as can BPM efforts.

  • The costlies BPM mistake is ignoring BPM - anyone _here_ dare to argue? :)

  • user-pic

    IMHO the three costliest mistakes of BPM are just that - Business, Process, and Management.

    1. Business - or not getting the business to drive BPM. The process is owned by the business, is understood best by the business, and improving it would benefit the business the most - so it is obvious who should be "driving" this initiative. I have often seen IT "involving" business, but that is not quite the same as the business "driving" BPM.

    2. Process - or picking the wrong process as a start. What process you pick would vary with your situation, but typically pick something that is significant enough to catch the attention of the CEO, is able to meet the financial objectives set out by the CFO, and the timelines set by the CIO.

    3. Management - or change management to be more specific. BPM almost always involves changing the way people work. Understanding the softer aspects of BPM involves knowing what matters to the most to the people in the process, and being able to relate how they benefit from it. Higher productivity or efficiency can often mean that lesser people will be required to achieve the same business objectives - employees often feel threatened by this. Trying to manage change as an external consultant is futile - you must get the senior management to understand and embrace BPM; then get them to drive the change in their organizations.

Add a Reply

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT