Resolved
4 votes

From Ian Gotts: Is it because there are not enough internal skills; project management, business analysis, change management? Is it because they don't do it often enough to build up the skills? Or is not seen as a priority?

Thursday, May 19 2016, 09:53 AM
Share this post:
Responses (12)
  • Accepted Answer

    Thursday, May 19 2016, 10:07 AM - #Permalink
    Resolved
    2 votes

    Probably because first IT is too busy and does not really believe ...and once it does get started it becomes another theoretical exercise with good intentions but no means to deliver without IT......?

    The reply is currently minimized Show
  • Accepted Answer

    Thursday, May 19 2016, 10:08 AM - #Permalink
    Resolved
    5 votes
    My guess is that most internal projects fail due to their infrequency... It takes time to build the skill set, and it takes exercise to maintain those skills. If you're only doing one BPM project every few years, you're unlikely to do it as well as those who do BPM for a living.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, May 19 2016, 10:18 AM - #Permalink
    Resolved
    5 votes

    It is easy to get lost in the process of process improvement.

    It can become an overwhelming task to plan and organize and implement especially when we take into consideration the necessary knowledge of tools, methodologies, languages, frameworks and other technologies. The exercise improves in ROI the more closely we can perceive it as a "story" about the way we work and an improvement of that narrative. Treating the business process management activity as a continuous improvement of the way we work can add clarity to the task and a shared understanding between stakeholders.

    I like the idea that companies are working to democratizie the act of BPM to get right to the reasons we do it -- to attain operational efficiency.

    • John Morris
      more than a month ago
      Good emphasis on the myriad skills (read "costs" too) required to do BPM. And then we realize that skills don't count for much if we aren't focusing on making work efficient -- likely perceived as story or narrative. One could say that story or narrative is or should be the first class citizen of our BPM kit. Most of the other things are secondary.
    • karl walter keirstead
      more than a month ago
      and, the other reason we do BPM is to attain operational effectiveness.
    • John Morris
      more than a month ago
      Perhaps this is splitting hairs, but consider that BPM-as-technology concerns just operational efficiency, doing more work with the same resources.

      Because operational effectiveness can be pursued by management regardless of the availability of BPM automation technology, as it was pursued for example using paper forms.

      Here's an analogy. I use a nail gun to drive more nails than I could with a hammer. But the nail gun doesn't help me decide where to drive the nails.

      I think it's helpful to tease apart the often inedible ball of spaghetti which is "BPM" . . . . BPM-as-software-infrastructure, BPM-as-executable-business-process-semantics, BPM-as-process-management-methodology, BPM-as-process-governance . . . . served as separate meals one might have a happier dining experience.
    • karl walter keirstead
      more than a month ago
      John, you are right...

      The way I see it, once an organization starts doing ACM/BPM within Case, the primary focus goes to operational effectiveness first, then efficiency.

      Clearly no point being effective, though, if you are not efficient so if BPM is second it's a very close second and not at all optional.

      Both are important - you can be highly efficient cranking out products no one wants.

      I guess Case folks should always explain they are practicing ACM/BPM, not BPM.

      Easier by far, of course, if the BPM folks could/would agree to transition to ACM/BPM.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, May 19 2016, 10:22 AM - #Permalink
    Resolved
    5 votes
    Internal BPM projects? When I read the article, I think the actual question is; why are BPM projects so hard without a little help from a BPM consultant?
     
    My intuitive response would be; because BPM is not a project. It is daily business.
     
    But ok, having said that I've seen many reasons why It's hard to implement "Managing by process":
     
    - The customer just wants to solve a problem and doesn't care about "managing by process"
    - The customer thinks that with some modelling you can improve processes ( the magical "Implementation" chapter in many process improvement books)
    - The customer has no clue what "managing by process" is about
    - The customer doesn't know it's own processes and their desired performance
     
    And I think all can be learned with a little coaching (and of course good old things like commitment, some helpful tools etc) I often use the metaphor of "BPM consultant/coach = general practitioner in healthcare"
     
    A general practitioner has a good understanding of what it takes to have an healthy body (performing processes).
     
    He can distinguish symptoms (in process language: too late, too expensive) from causes. These causes can be many because a body has many organs, bones, muscles, hormones, etc)
     
    Just like a process; to make a process perform it needs many aspects like a workflow, people, data, tools, a way of steering, steering information etc. All together they make the process perform.
     
    A general practitionar has this overview and can guide to the right diagnosis. Doesn't mean he can solve it all or know it all. Maybe that needs specialized surgeons. And I think in organizations most people operate like specialized surgeons. Very good in brain surgery (IT), heart surgery (Hrm), etc.
     
    But somehow it need all be brought in a context; a process context. Also to be sure you don't fix the wrong problems. And with a little guidance from the general practitioner, all the surgeons might get better in understanding each other, collaborating.
     
    But of course there is still a chance that a company says "I have a headache, give me that aspirine and get back to work"
     
    happy processing!
    • John Morris
      more than a month ago
      Bravo process "as daily business". Which as you point out then runs into a brick wall of, perhaps "not being very far along the process management maturity curve" would be a polite way of putting it. And then there's always the aspirin model too -- otherwise known as magical thinking.
    • Emiel Kelly
      more than a month ago
      Thanks John,

      Personally I am not a big fan on scoring organizations on "BPM maturity". Like it's a contest or something. "Oh our customers are exited; we are at level 3 of process maturity..."

      But it might help to get some ideas to break the next wall.
    • karl walter keirstead
      more than a month ago
      Hi, Emiel . . . Maturity levels seem to motivate some people - they visualize themselves at a level they are not at, and then, I suppose "pull themselves up by their bootstraps" to get there.

      Nothing wrong when you are at II from looking forward to III and IV if that seems to motivate.

      The winding road for BPM,in my view, is to go from

      BPM -> operational efficiency and effectiveness -> better business management -> preserving and increasing strategic competitive advantage.

      One of the "easy" ways to manage a business is to build up a "predictive analytics" infrastructure.

      See "What predictive analytics can do for you" at

      http://wp.me/pzzpB-L2
    • Emiel Kelly
      more than a month ago
      mmm.. I see I typed "Exited", while I meant "Excited" ...
    • John Morris
      more than a month ago
      Concerning "maturity levels" (like CMM etc.), one can be sceptical if they are arbitrary products of the imagination -- even if they help you break through the "wall" (Emiel) or enable you fix your "bootstraps" (Walter).

      A maturity level, coming as the idea does out of statistical quality control, could be applied "mechanistically" certainly. However, there is some research that a maturity level could in fact represent a real, coherent and emergent property of systems management.

      Think of a maturity level as a "management state". We usually do think of maturity as "linear", but it's quite possible that there may be more than one "path" (could I say "journey"?) from lower maturity states to higher maturity states.

      In summary, maturity states "exist". And if they exist they can be and should be managed, for gain. They are probably not just useful fictions.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, May 19 2016, 10:44 AM - #Permalink
    Resolved
    3 votes

    I would say they are generally thought of as discrete projects and the business is tasked with solving a specific issue/process. This leads to very short term process specific thinking with internal resources who may not have any context or expertise as others have mentioned. When the project is over, the resources are tasked with other projects or back to their main jobs. Because these projects tend to be far apart due to resource allocation, the resources may be relearning from the last project or brand new to BPM and starting from scratch.

    Most firms in my field do not have the insight or vision on how to manage their processes, they are only tasked with pain point projects. What makes it even harder for them to manage their business processes is the 'Workflow enabled' applications which allow pain points to be addressed by x number of systems. Pretty soon, they may be automated but with lots of different tools which means management of these processes is seriously difficult and especially not consistent.

    The reply is currently minimized Show
  • Accepted Answer

    Thursday, May 19 2016, 11:07 AM - #Permalink
    Resolved
    5 votes

    Off the top, here are six reasons why internal BPM efforts fail . . .

    Failure to pre-state objectives/expectations
    Lack of understanding of the BPM discipline
    Lack of expertise practicing the discipline
    Inadequate qualified human resource allocation to BPM
    Wrong software selection
    Bad choice of pilot project

    Notice that 'failure to sustain" does not appear in the list - Reason: if you implement a run-time UI where it is easier for workers to liaise with the software system than not to, most of the objections, foot-dragging etc goes away.

    • E Scott Menter
      more than a month ago
      +1 for all but in particular "bad choice of pilot project".

      "As a first project for our new, barely trained and totally inexperienced BPM team, we are going to fluoridate the Pacific. Once that is successful, we will move on to buying toothpaste at the CVS down the block."
    • Patrick Lujan
      more than a month ago
      +2, but I'd do the 'particular' moreso on "lack of expertise practicing the discipline."
    • karl walter keirstead
      more than a month ago
      Patrick... I suppose we need to be on guard for people ". . . .practicing the discipline when they don't know what it is"
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, May 19 2016, 11:35 AM - #Permalink
    Resolved
    4 votes

    Firstmost, IMO there are few genuine "pure" BPM efforts. At least, I have not seen many "BPM projects."

    On the other hand I have seen multiple "ERP implementation", "Lean", "Compliance" projects fail. The common denominator here is: "We need to understand our processes before (fill in any business initiative)." To make a long story short, and a lot has been said already above, but I happily repeat that: You need to get your BPM foundation in a healthy shape in order to make the mentioned initatives more succesful.

    So, basically we have a chicken - egg issue here: Is there any company that want's to spend money, just for the sake of retaining and manage BPM as a discipline. Not many I'd say. But here's the crazy thing: They're happy to spend thousands of $$$ for each business initative where BPM sort of is seen as a necessary side thing. Consultants are hired (again) to map processes, conduct analysis and capture requirements. Over and over and over again...

    And thus recalling Einstein's: "Insanity: doing the same thing over and over again and expecting different results."

    • karl walter keirstead
      more than a month ago
      Seems wasteful for consultants to spend much time on requirements - the usual customer expression of needs can be stated rather simply:

      "We want to be able to do the right things, the right way, using the right resources, at the right time and the right place.

      "We recognize there cannot be 10 best ways to do a particular set of tasks, hence the desire to evolve a set of context/situationally appropriate "best practices" and encourage staff to, within reason, follow the best practices.

      "We recognize that consistent use of best practices will, all other things being equal, lead to improved outcomes"

      --- how's that for borrowing your watch to tell you what time it is?
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, May 19 2016, 12:34 PM - #Permalink
    Resolved
    5 votes

    Most things fail.

    Take your pick: lack of imagination. Poor leadership. Muffed execution. Questionable teamwork. Lack of clarity of purpose.

    It's supposed to be hard.

     

    • karl walter keirstead
      more than a month ago
      It IS hard because most folks don't like to think. Some can't (having never done it).

      The message the consultant needs to get across is (from Senor Wences): "Difficult for you, easy for me", the implication being the expense will be worth it, with a greatly increased probability of success.

      The most important question a consultant can ask is "... and then, what do you do next"

      See "The facilitator is coming"

      http://wp.me/pzzpB-aG
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, May 19 2016, 02:04 PM - #Permalink
    Resolved
    5 votes

    Having worked as a consultant for 20 years, then re-entered the corporate environment as their BPM expert, the answer is easy. Staff DO NOT have the credibility consultants do and therefore no matter what you try it eventually, sometimes slowly, but eventually it fails. The reasons already given certainly contribute but at the root of it all is the fact that what an external consultant says and what a member of staff says do not carry the same level of influence.

    It's been a very enlightening experience for me and one that I'm glad that I've had.

    • Patrick Lujan
      more than a month ago
      Consultants usually get the same short shrift employees too. About the only time I hear the client listen is when the vendor says.
    • karl walter keirstead
      more than a month ago
      Influence is earned and this applies both to internal staff and to outside consultants.

      Remember Red Adair? - when he went on-site, everyone (exec, tech staff, contractors, government inspectors), literally stopped whatever it was they were doing and gave him full focus.

      A mining engineer colleague of mine, not quite as famous, would go on site, walk around in a seemingly random fashion until he had built up a sizeable group of followers, then, when he figured his 'show' was over, he would point to a location and say "dig here". Only a few of us knew that he spent days looking at the maps and memorizing the terrain.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, May 19 2016, 03:46 PM - #Permalink
    Resolved
    5 votes
    Yet another BPM law
     
    Successful BPM implementation is an enterprise-wide digital transformation.
     
    Corollary 1 It is mandatory to keep the big picture and implement it in several small projects.
     
    Corollary 2 All the enterprise-wide functions must be aligned to optimised the use of BPM.
     
    Corollary 3, ICT, as the most common enterprise-wide function, must have all its functionality “in tune” to optimise the delivery of process-centric solutions. Namely: Governance, Security, Software development practices, Operations, Monitoring, Support, Maintenance & Small enhancement, User Experience, Data Architecture, Use of the selected BPM-suite tool, Overall continual improvement.
     
    Corollary 4 An enterprise needs a small group of agreed minds to architect and guide others to execute this digital transformation.
     
    Ref 1 illustrates the corollary 1
     
    Thanks,
    AS
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, May 19 2016, 09:20 PM - #Permalink
    Resolved
    3 votes

    Hi all....

    I'd like to emphasize 3 points:

    1- In many organizations, the BPM has been treated as a project, instead to be treated as management discipline.

    2- There is no high level leadership that embraces the BPM and neither defend it as primordial to align strategies and operations.

    3- Culture: in general the people are satisfied where they are, what they do and how they do ... at same time, they don't know why they have to do this or that to support the strategy needs.

    For sure there are many other points to be considered....

    Rgds, M

    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Friday, May 20 2016, 08:24 AM - #Permalink
    Resolved
    3 votes

    "why do internal BPM efforts fail?"

    for all the reasons external BPM efforts fail, plus skills gap (as said above).

    • Dr Alexander Samarin
      more than a month ago
      People try to "handle" an iceberg from the visible part only which is the "low hanging fruit" syndrome.
    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
278 Replies
30/09/2016
David Chassels
271 Replies
30/09/2016
Emiel Kelly
223 Replies
30/09/2016
Bogdan Nafornita
210 Replies
30/09/2016
E Scott Menter
182 Replies
28/09/2016