Resolved
1 votes
Speaking with both customers and vendors at last week's BPM & Case Management Conference, an issue that kept coming up was legacy processes. So what is the best way to deal with legacy processes?
Thursday, June 26 2014, 09:50 AM
Share this post:
Responses (8)
  • Accepted Answer

    Thursday, June 26 2014, 10:32 AM - #Permalink
    Resolved
    1 votes
    I would assume most legacy processes have been created "inside out" and as such do a job but not the desired complete capability that closes the gap between people and the process system. So suggest think "outside in" as previously discussed in this forum. Start with step by step how to deliver the outcomes recognising “adaptive” needs. During that exercise there will be data or useful "sub processes" that can be used from the legacy process. For example no point re writing a "bank payment process" use it as required. Whatever important that you do not create another inflexible legacy process! Think “communicate” not “integrate” which is now possible with next generation “BPM” adaptive tools that can orchestrate internally and externally So 4 key capabilities should keep you on the new fast track to tackle legacy processes “Outside-in” “Adaptive” “Communicate” “Orchestrate"
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, June 26 2014, 11:16 AM - #Permalink
    Resolved
    1 votes
    Asynchronous message brokers.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, June 26 2014, 11:26 AM - #Permalink
    Resolved
    3 votes
    http://www.socialprocess.co.uk/images/Evolution-BPM.jpg Imagine Neanderthals running around prehistoric earth, being chased by dinosaurs? Did they think “how do we manage these legacy creatures? Or did they just kill as many of them as they could? Like pre-historic creatures, processes evolve over time. Customer needs change, sometimes simply because your process is out there so it becomes normal, expected, no longer best in class. You’ve educated them to expect more. That means any well designed process has evolution built in – an intelligence system to see where customers are moving on and leaving gaps for you or competitors to fill, a way for people working in the system to collaborate on making changes and a way to evaluate those changes and constantly re-iterate. Processes are always only one short step behind the customer needs and never need step-change. So, assuming you've designed the process well, the first question has to be “How did it get to be legacy”. Are you so arrogant that you forgot to implement systems to evolve it? Perhaps you were so gullible that you fell for one of those big, inflexible “Eternal Revenues for Providers” (ERP) scams – the ones where you can never even find out how many seats you own and where they sit, but the invoice turns up regular as clockwork? Perhaps your process is so unimportant that some departments are allowed to keep doing wrong all the stuff they’ve been mucking up for years. Or perhaps your company is so disjointed that they actually like customer journeys with gaps in them, dis-engaged employees and documents and intelligence disappearing down holes. If it is any of these, how can we trust you to manage anything? Perhaps it is your company who should be (and soon will be) extinct? Anyway the answer is simple. The best way to manage legacy processes is to move to a company that hasn’t got any. Where process works and creates competitive advantage. After all they’ll be taking over your lot pretty soon anyway. Oh – perhaps you wanted the second best way? Well that is to make such a compelling case that the company suddenly finds a few smackers down the back of the sofa to turf the legacy c**p out and move forward from the eighties. Perhaps you could design some new BPM stuff to help them make the right move. Oh you meant the third best way. Why didn’t you say so? BPM is pretty resilient. It takes any data source and hides it behind a pretty front end. So they can still use their horrid forms and the data goes into BPM to work in the bits of the process it is allowed to manage. Users can stay trapped on their burning platform until you get round to sorting it. But don’t expect them to be happy about it.
    Like
    2
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, June 26 2014, 11:27 AM - #Permalink
    Resolved
    2 votes
    I would think about the same as any kind of process: determine the value of spending time reimplementing/improving/porting the process, and if it makes sense, do it. If not, live with it until the pain is enough to drive change.
    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Ian Gotts
    Ian Gotts
    Offline
    Thursday, June 26 2014, 12:56 PM - #Permalink
    Resolved
    2 votes
    Legacy and Continuous Improvement are opposite ends of the spectrum. If you analyze and update / improve legacy processes, then they are no longer legacy. Simple really.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, June 26 2014, 02:26 PM - #Permalink
    Resolved
    2 votes
    Having legacy business processes means that your internal BPM environment is not agile thus your BPM practices are weak thus your BPM architecture may be just absent. Find your root cause. Thanks, AS
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, June 26 2014, 03:55 PM - #Permalink
    Resolved
    3 votes
    Figure out how to bring them up to date and stop getting in the habit of letting them become legacy :)
    Like
    1
    • George Chast
      more than a month ago
      Right.
      I am not sure what else a legacy process is other than the way we have been doing it.
      If it's the next big problem, fix it. If not, don't.
    The reply is currently minimized Show
  • Accepted Answer

    Amy Barth
    Amy Barth
    Offline
    Thursday, June 26 2014, 05:38 PM - #Permalink
    Resolved
    3 votes
    If an organization is still using an antiquated legacy process, there is a reason they are doing so. Usually because "it works" (at least "good enough") and change is risky or considered unnecessary. A new solution is brought in to update the legacy or fix a problem they can't solve. With a BPM approach to updating the legacy, and/or a BPM solution, you can bridge the gaps, wrap the system with something more user friendly, streamline the legacy process so it all runs more smoothly (and faster), and convince the organization to repeat the process when there is success. There has to be some buy-in to the BPM solution, however, or you'll just be spinning your wheels if the project team won't let you get any traction. The real question is how to deal with an organization that is afraid of change and really, really needs to scrap the old way just to join the 21st century. It might seem hopeless, but if you can deliver on your promises to improve what they have with BPM, you can open the door, bit by bit, making room for an iterative cycle of modernization. If you can't deliver on your promises, though...yeah, the legacy stays another day.
    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
01/10/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