Resolved
1 votes

As BPM has a long and varied history, what would you say are the key differences between today's BPM and process improvement projects of the past?

Thursday, February 19 2015, 09:45 AM
Share this post:
Responses (10)
  • Accepted Answer

    Ian Gotts
    Ian Gotts
    Offline
    Thursday, February 19 2015, 10:02 AM - #Permalink
    Resolved
    1 votes
    Clearly the BPM technology has moved on. Cloud, social and mobile mean that business uses can get projects going more quickly, more cheaply and can therefore deliver a greater ROI. But to deliver wide scale change requires an integration into the increasingly complex IT infrastructure of companies and that is an inhibitor.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, February 19 2015, 10:27 AM - #Permalink
    Resolved
    2 votes

    SMAC. We're going back and forth, across the DMZ much more than in the past. Nobody's still really doing analytics well, they're few and far between, but some folks are blowing a ton of money in the attempt. A large, multi-year effort on the west coast right now that goes beyond fugazzi immediately comes to mind. It was supposed to save money and streamline things but is achieving the opposite effect in a grand fashion.

    The practice itself hasn't changed much either. Either they do or don't get it, usually the latter regardless of how much effort is expended to enlighten. More often than not there's a specific need, specific project and when it's done the lens doesn't pan out any wider than that.

    A successful implementation remains the goal.

    • Emiel Kelly
      more than a month ago
      Voting on your own post... You should become a Russian president ;-)
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, February 19 2015, 10:56 AM - #Permalink
    Resolved
    1 votes

    I don't think it has anything to do with past or current days.

    Process Improvement is mostly attacked as a project, while BPM is daily business.

    @BPM mentor, come in ;-)

    • Patrick Lujan
      more than a month ago
      And here's the part where I'd revert to Ian's statement earlier this week about people wanting outcomes. ;)
    • BPM Mentor
      more than a month ago
      You don't know when to give up, isn't it? I thought we shacked our hands, you keep your perspective, I keep mine :-)
    • Emiel Kelly
      more than a month ago
      ;-)
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, February 19 2015, 11:04 AM - #Permalink
    Resolved
    2 votes

    No longer is process automation a choice. The ROI calculaition is not between doing nothing and doing something, it is between improving one thing or more than one thing through automation. The emphasis has shifted from "if" and "why" to "when" and "how".

    Today's consumers of process automation are in the enviable position of being able to optimize their own implementations and customize their experience. Reporting and dashboards flow seamlessly from systems offering an unlimited way of visualizing the data. Orchestration of third party techgnologies in the workflow, directly from within the BPMS, eliminates tedious system switching and manual lookups leading to increasing process velocity and accuracy

    Like
    1
    • BPM Mentor
      more than a month ago
      I couldn't have said it any better ! Spot on !
    • Emiel Kelly
      more than a month ago
      Sounds like BPM (you know, what happens every day in companies)
    • BPM Mentor
      more than a month ago
      To be a top-notch player in the BPM world you need to have a sound knowledge AND a good amount of EQ. It looks to me you need to practice more Emiel.
    • Emiel Kelly
      more than a month ago
      @BPM mentor, Practice what?
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, February 19 2015, 01:27 PM - #Permalink
    Resolved
    1 votes

    So I see several things, some of which I am affirming from others.

    1. Greater automation and technology- are now always part of processes. And now technology is even helping and empoweting at the individual perfomer level.

    2. BPM going wider, more cross funtional, and now much more global.

    3. Combination of lean six sigma, BPM, Case management methodologies - doing these frameworks together or what is needed for the organization. No need to have one evangelical method!

    4. Improving the work is the work and so building that principle into daily work and processes and doing it daily/regularly. I am only beginning to see that happen in a few companies.

    The reply is currently minimized Show
  • Accepted Answer

    Thursday, February 19 2015, 04:28 PM - #Permalink
    Resolved
    2 votes

    In the past, a BPI project could have an illustrative process (drawn on a wall) and its implicit implementation via coding. Today, we try to work with explicit and directly executable processes.

    See as well the table at http://improving-bpm-systems.blogspot.ch/2014/03/bpm-related-tlas-comparison.html

    Thanks,
    AS

    • Gary Samuelson
      more than a month ago
      re: "Today, we try to work with explicit and directly executable processes"

      I'm focusing on the "we try"... (this idea begs for additional details: compare/contrast, pros/cons... of directly building an executable process).

      Two perspectives (pressing the topic towards details on methodology):

      (1) "directly executable" -> Are you saying that BPM projects should be owned and operated as IT projects?

      - or -

      (2) "executable process" as in a new formal development methodology -> BPM is now a formal methodology and should take its rightful place alongside object-oriented and domain-driven analysis models.

      I bring this up because, with the onset of increasing technical support for process-management, there's a gap in general necessary organizational change. It's like putting a new driver behind the wheel of a specialized automobile without reviewing reasons, goals, and training per vehicle's value-add attributes (i.e. why go faster?).
    • Dr Alexander Samarin
      more than a month ago
      Neither. Because the full use of BPM potentials, primarily, “working with explicit and directly executable processes” requires a transformation of existing SDLC and IT departments (including strategy, its execution, governance, management, operations and evolution).

      Business process and some other process-related artefacts will be managed by the business super-users. All artefacts will be enriched by SMEs (e.g. forms, reports, patterns, etc.). This will allow to capture the business knowledge and prevent its “dilution” in code. Ideally, all processes of the whole enterprise will be implemented by a common business execution platform.

      So, “executable processes” is more than a “formal development methodology”.

      Thanks,
      AS
    The reply is currently minimized Show
  • Accepted Answer

    gB
    gB
    Offline
    Thursday, February 19 2015, 06:20 PM - #Permalink
    Resolved
    1 votes
    Process improvement is and will always be, the final goal. the thing is HOW to do it. several years ago we focused mainly on improving the drawing as Alexander says. Now it is just a part of the improvement To be done. Nowadays we also take care of the integration with other systems, the usability to maximize user efficiency, accesibility to enable more people to use the system, data analysis to measure in past executions as well as real time, etc. Yesterday we saw the process diagram; today we see its full picture.
    • Emiel Kelly
      more than a month ago
      I don't hope that process improvement will be the final goal. I hope executing processes well will be the final goal.

      'I don't want to improve, I want to do things well'
    • Emiel Kelly
      more than a month ago
      Maybe a little too short. I agree improvement is needed often to keep up. But I've seen so many organizations starting up big improvement projects which got so easily disconnected from the daily execution and management of processes that it causes an anti-improvement culture.

      I think that when improvement is not tightly connected with execution, but is seen as a 'process improvement team hobby' it's not really effective.

      I've always been at the lowest block of an organization chart, so I believe improvement should come from the work floor. But I'm also aware that you can't teach a drowning man how to swim, so some guidance is needed.

      That's why I think organizations don't need Process improvement projects, but (let's call them) process improvement coaches, who guide the people on the work floor to focus on the right things. Help them to set up the stuff to make them aware of the performance of the processes, to coach them what makes up a performing process, etc.
    • Dr Alexander Samarin
      more than a month ago
      RE " organizations don't need Process improvement projects," - disagree because they (as a set of changes) should be a lightweight agile mini-projects (in some places are called BAU).
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, February 19 2015, 06:36 PM - #Permalink
    Resolved
    1 votes

    Historically, process improvement has largely been a garbage-in, garbage-out endeavor. People estimate numbers, they estimate times, they estimate error frequency... and based on those WAGs we generated reams of paper explaining how we are going to improve a process by 22.325%, hilariously over-precise and potentially well within the margin of error for the numbers we used in the first place.

    BPM provides hard evidence. Real timings, real dollar figures, real exception rates. Measuring improvement issimplya matter of comparing pre- and post-change performace using those numbers. No guesswork, no self-serving approximations provided by the individuals whose jobs you were not-so-secretly trying to eliminate through your Operational Excellence initiative.

    And besides—you secretly got most of the improvement when you first automated your process. Everything else is just gravy.

    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Sunday, February 22 2015, 01:57 PM - #Permalink
    Resolved
    1 votes

    There are 4 core differences between Today's BPM and Process Improvement projects of the past.

    1. BPM is no longer Cutting Edge

    In the eighties and nineties Six Sigma was the high profile way to improve your company. People like Jack Welch were global superstars and a process improvement operation was something the whole board focused on as their competitive advantage.

    Last century was the mass production age with hundreds of thousands of people employed for their manual labour, doing repetitive low-skill tasks. And hundreds of thousands of clerks, doing equally repetitive, low-skill tasks - just in offices, not on factory floors. The manual jobs went first as we moved beond the limitation of human muscle. Now the clerical jobs have gone too except in backward companies.

    BPM missed the boat. Like making a better buggywhip just when someone had invented the car. It is restricted to backward companies who still have the sort of labour-intensive processes, or to companies where showing governance for their outdated clerical processes is vital. And it is rarely the key task which makes those companies the darling of the stock market. Process Improvement isn't sexy anymore.

    2. All Processes are now Computerised Processes

    Process Improvement in the past could only set guidelines. Processes were manual and it created the manual. But people then read the manual their own way, subverting many of the process improvements or twisting them to their own ends. So the process at the end of an improvement project was as good as it got - it would be subverted over time.

    Manual processes were hard to obtain information from in any quantifiable and verifiable form. So they tended to be subjectively analysed and stood or fell on the reputation of the person involved. This led to HIPPO (highest paid person's opinion) rulings, "not invented here" syndrome and "someone else's problem" effects.

    Computerised processes have real-time data on everything they do. You can see process time, percentage of exceptions, latency and waiting times and even percentage utilisations. You can show these in visual management graphs, AB test and see immediately the effect of any "improvements". Thus the process should be continually improving as people work to reduce the biggest problems first, try out new methods and optimise utiisations. No arguments either - the data drives decision making.

    But it hasn't happened like that. Seeing the true efficiency and effectiveness of a process has proved an uncomfortable truth for most managers. So they have stuck with the "project and out of there" approach of traditional process managment. A major opportunity has been missed.

    3. Process is Everywhere Now

    Process thinking used to be restricted to a few special people with silly names like Black Belts or Kaizen Kraftsmen (seriously - I saw it on a job description). Amazon changed all that. UX came along and with it customer journeys. Suddenly process was being done by web designers, marketers and customer service people, not just self-styled Process Gurus. So the process is no longer set in the IT department, nor as part of a manufacturing or ERP process, but dictated by the customer (anyone know what those are?). Today's BPM is just one of many approaches.

    4. BigIT is no longer the way to do things

    When IT was hard, business people had to put up with the way they did things. If they wanted to change a web page they had to put in an order in triplicate and wait three months. If they wanted to have a CRM it was a multi-million dollar, three year project. Business Intelligence was even worse, with massive data warehouses and fixed links to each datasource - change one and you broke the lot. Last but not least was Process - deciding their requirements two years before the project went live and waiting patiently while it went through a long Waterfall process was the only way companies knew to do things.

    Now interns can set up landing pages on the fly. Salesforce pulled the rug from under IT departments everywhere with SaaS. Data intelligence is now a point and click exercise, with APIs connected instantly and data just falling out fo the system at will - or even connected to a round-trip machine learning process.

    BPM is still BigIT. Slow, management intensive and inflexible. Depressing really.

     

    Let's not weep for Today's BPM. Let's look towards tomorrow's Process Improvement. Where demand intelligently drives production and delivery so the right goods are in the right place at the right time. Where markets are tracked automatically and changes built into the process systems which follow them. Where the income flow follows the demand, uninfluenced by sales cycles, promotional imperatives and other distortions. And where a million niche products can be created, tracked and delivered as easily as one monolithic brand leader.

    The reply is currently minimized Show
  • Accepted Answer

    Sunday, February 22 2015, 03:55 PM - #Permalink
    Resolved
    1 votes

    A little concerned that we're assuming "better" is "easier".

    I need to point out that, although technology is making it easier, "easy" isn't a function for "improved" output. There's no correlation.

    Example A: A developer may attain "certification" in one-of-many BPM development platforms. Certification-in-hand, they're now off and running in (sometimes) major BPM projects. Without seasoned oversight the results are staggeringly cost-heavy failures and a general tarnish upon our process-management methodology.

    Here we see a BPM suite leading towards a harmful simplification of the efforts behind organizational change (process improvement). BPM isn't a "training" requirement or certificate. And, though I honestly enjoy using the new(er) BPM technical suites, tools nor their certified training build the house.

    Example B: BPM tools allow for "executable models" - this feature provides a direct path between process model (BPMN) to deployed application (IT-asset). This capability tends to shortcut analysis and marginalize business knowhow. Evidence here is easy to point out on most projects by simply asking for (and not finding) the values/KPIs behind general process and composite activities. Where's the fit, or tactical representation, within overall strategy?

    Here we see BPM morphing into a functionally oriented point-solution (i.e. just-another-application). BPM suites make this easy... Just hand-over the tools to your IT department and let them have-at-it. There's no process-management outside of name-sake on the development suite.

    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