Feeds:
Posts
Comments

Posts Tagged ‘business process reengineering’

bpr magnifying glassAccording to a 2014 Business Process Management Report produced by Panorama Consulting (available here)

“Organizations that effectively define and document business process improvements as part of their enterprise software initiatives are much more likely to complete their projects on-time and on-budget…. [and] are more likely to receive the business benefits that they expect from their ERP systems.”

Panorama lists three reasons why business process reengineering is sometimes overlooked (and then list 3 things you can do about it):

  1. Business process reengineering (or Business Process Analysis) appears to cost more time and money – at least on paper. After all, if we configure and implement ERP software without spending time to analyze (and change our processes), won’t the implementation go faster?
  2. Less experienced implementers defer to the ERP software to deliver business process improvements. This, Panorama points out, is like the “easy button.”  The software is so robust, surely it will fix all our problems, right?  In fact, the complexity can be overwhelming, and will cost you a lot more money if your processes aren’t well-defined before you design and build the phases of your implementation.
  3. Too many organizations think that they will simply start with a clean slate and throw out their old business processes. The truth is, you don’t want to throw the baby out with the bath water.  Sure, some of your old processes may be outdated or inefficient.  But don’t neglect those things that have made you successful.  Your people need to be trained in a way that connects your “future state” business processes to how things are being done currently.  Here, communication and training become key.

Panorama then provides 3 tips to help ensure that your team avoids these pitfalls:

  1. Don’t forget to address both your current and future business processes. Identify the gaps between current and future state and ensure employees understand what is changing, and how.
  2. Begin defining business process improvements prior to your ERP implementation. (At our firm, we always start here.  That Business Process Analysis is the critical first step – it builds the roadmap for the ERP implementation and all that follows.)
  3. Use your reengineered business processes as the foundation for your organizational change management and training strategy. Document and communicate to all persons what’s changed, how it’s changed, and how things work in the future.  It’s all about training and communication.  Whatever you do – don’t ignore these critical elements.

Just like Panorama, our long experience bears out their very good advice.  Take it to heart.

 

Read Full Post »

working on the bizI have long considered the CEO’s number one task to be that of working ON the business, rather than IN the business whenever possible.  It’s not always possible, but it’s possible more than most CEOs and small business owners think.  It’s a principle I’ve abided by for the nearly 28 years I’ve been at the helm of this software company, and many of my colleagues and fellow business owners know that about me.

In fact, I take a fair amount of good-natured ribbing over my ‘inferior technical skills.’  Truth be told, I was a highly-technical-PC- guy a good many years ago.  But I dropped the mantel of the wizard and the Cult of Personality shtick a long time ago in favor of trying to do one thing well… just manage the business.

In other words, work ON it, not IN it.  So a recent article espousing that very philosophy written by the folks at Panorama Consulting was music to my ears.  In it, we are reminded of a book you may have read quite a few years ago called The E-Myth Revisited, in which author Michael Gerber first articulated this challenge, now so familiar to so many CEOs and entrepreneurs.

Panorama provides a succinct summary: “To summarize the general dilemma: executives at organizations often get consumed with “doing” the work rather than “building” a business that enables the work to get done. ”

So, if a business has not structured the right business processes… if it hasn’t managed its workflow into repeatable patterns… it hasn’t defined roles and responsibilities… it’s more likely to suffer from the stresses that stem from a lack of clarity.

Especially as organizations grow, owners who have focused more of their time working on the business tend to suffer through fewer crises and can often minimize stress and confusion.  Businesses can run more smoothly and predictably when roles and responsibilities are well established.  Less time is spent putting out fires and a little more time might be expended on planning for the future.

So, what does all this have to do with ERP?  If you’re a “mature” business, with a focus on growth, probably a lot.  The ERP system is a foundation for being able to focus on the business, instead of working in it.  ERP creates consistency of process and procedure, augmented by the speed of computing, that enables profitability and scalability – key components to growth.

Of course, that only works if the managers of the business have used the process of implementing ERP to evaluate and reengineer the underlying workflows that the system is intended to manage.  The way you get to scale and growth is through repeatability.  Planned and executed properly (and only then) ERP fosters repeatability.

It all starts with analyzing processes.  That usually leads to business process reengineering.  Then, in order to actually succeed at this, the company must embrace organizational change management, establishing clearly defined roles and responsibilities, clear communications and expectations, and a few key performance measures.

Only then are companies in a position to actually implement the (ERP) system that will put them on the road to repeatability, scale and growth – and thereby free the owner to work even more on the business, than in the business.

Or maybe, on the golf game.

 

 

Read Full Post »

bprWhether you’re looking to improve your customer service, improve your top line or increase your bottom line, companies seeking improvement have plenty of reason to reengineer their processes.  Usually, all of the above.

So when a firm takes on the task of implementing an ERP system, business process reengineering is – or should be – the key motivation.  That’s often coupled with a desire for growth, or the ability to handle growth already upon them.

A recent 2014 ERP Process Improvement Report from Panorama Consulting showed that 100% of respondents had suffered some sort of “material operational disruption at the time of go live.”  Of these, 60% lasted at least a month.  Nearly two-thirds said they expected some difficulty in adjusting to operational change.  Interestingly, fewer than half “changed their business processes [in order] to leverage functionality of the new ERP system.”

We ask: Why do it, if not to review, analyze and ultimately change and improve your processes?

Well, as it turns, one key reason is budget and timeline overruns.  The challenges of the reengineering that motivated acquiring the new ERP system in the first place appear to cause companies to neglect the very reason they went there in the first place: process change and improvement.

In other words, it’s harder than they thought it would be.

Panorama suggests three things to keep in mind to ensure that you achieve the best business process reengineering results possible:

  1. Recognize that not all your business processes are created equal. The short version: Prioritize your process improvements, and then focus on the handful that brings the most bang for the buck.  Push the others to the back burner when necessary.
  2. Integrate your business process reengineering and organizational change management activities. Don’t treat these as two separate activities.  So for example, the people defining the new processes should also be the ones defining the impacts on departments and people.
  3. Ensure your project plan includes enough time and resources to properly account for business process reengineering. Most teams don’t ignore process work because they want to… they often simply don’t have enough time (or didn’t budget for enough) to address this on top of all the other important project activities.  Start with a realistic plan and budget that accounts for process evaluation and retooling, and you’ll be an order of magnitude ahead of most ERP implementations right off the bat.

There’s the gist of it, and we couldn’t agree more, based on our own observations of many years.  The rest of the article author’s thinking can be found here.

Read Full Post »

erp success picAs we move officially into the second half of this year (wow… how’d that happen?!), we return today to some timely comments about ERP…

Panorama Consulting Solutions in Denver, through their blog and articles, often convey opinions and survey results about Enterprise Resource Planning (ERP) software solutions.  As often as not, we find ourselves concurring with many of their conclusions – after all, we’re pretty much in the same business, and after over 25 years of doing this, we’ve seen many of the same types of successes and failures.

Recently, President Eric Kimberling parsed his thoughts about just what constitutes ERP success.

On the one hand, he noted, too often “success” mean that, well, basically, ‘we survived the project.’  Or, some executive considered their ERP project a success because no one lost their job – or at least he didn’t. Or maybe they didn’t screw up the company’s operations.  It may simply be a preservation tactic since, as Kimberling put it, “no one wants to admit to overseeing a failure.”

Admittedly, ERP implementations are fraught with complexity, and the bar may be set low to acknowledge these facts.  Kimberling cites the fact, apparently the result of his firm’s frequent surveys, that the average $100 million company recoups about $1 million in tangible business benefits per year from its implementation.  Unfortunately, that’s about $2 million less than they anticipated, or about $20 million over the useful life of their system.

How can a company avoid a similar fate?  According to Kimberling, it should…

“Start with  a measurable business case that is used to manage business benefits – not just thrown on the shelf after justifying the project. The business case should be very tangible, specific, realistic and actionable to ensure that various stakeholders in the organization can be held accountable for achieving those results.”

Their second key piece of advice…

“Engage in business process re-engineering, rather than the “paving the cowpaths” approach that most organizations take. This means ensuring that you have adequate time built into your project plan to identify and implement significant operational improvements.”

Here we could not agree more.  With our own clients and prospective clients, we also go to great lengths to emphasize the importance of an initial Business Process Analysis.  We use these to match a client’s processes and workflows to the software and technology solution being considered.  We believe it’s the only way to begin an ERP project – and the single most critical phase at the onset.

Finally, Kimberling counsels…

“Ensure that you have a solid organizational change management strategy in place… Without employee acceptance and adoption of new business processes and software, the new ERP system is exactly that: just an unused system.”

There are a lot of fruitful benefits to be harvested from a successful ERP implementation.  Make sure yours extend beyond only the low-hanging fruit.

Read Full Post »

[Due to the Thanksgiving holiday on Thursday, we’re publishing a day early today.  We return to our Tuesday/Thursday schedule next week.  Til then, may all your turkeys be tender, and of the edible variety…]

A recent article from ERPWire.com highlights what we already know to be the absolute most critical component to a successful ERP implementation.

They call it “BPR” or Business Process Reengineering, and refer to the work as a Business Process Reengineering analysis.  At our firm, we call it a “BPA” or Business Process Analysis, but semantics aside, the message is the same: It’s the fundamental step taken prior to any successful ERP implementation.  It’s the process by which a company looks at what structural changes need to be made in the way it does business – before fixing their processes and procedures in place with their ERP system.

The BPR (or BPA) analysis is critical to any significant business process change.  In other words, it’s not just a precursor to deploying ERP.  It’s really a feasibility study, in which management looks at those inevitable agents of change (or improvement) and determines whether, when and how to adopt and integrate that change into its processes and systems.

BPA identifies areas for possible change (oftentimes, “gaps” in the current system), that then can be used to break down the process and reengineer a smarter solution.  Once the solution to a problem is proposed, flow-charted, debated and proposed, then your team sets about the task of inserting the changed process back into your process flow.  This could be simply changing the sequence or type of work to be done, or automating a process to eliminate some redundancy, or replacing the manual with the electronic, and so on. 

It is, of course, all part of what should be the ethic of every company: continuous improvement.

Oftentimes, a BPR/ERP clash occurs, when the process is in conflict with ERP and the software.  The answers are basically to restructure the process itself, modify the software, or find an acceptable workaround that satisfies the change requirements.  The best time to do this, of course, is before (or between) ERP implementations.

In fact, upgrading or deploying or redeploying ERP is the critical time juncture when any firm should step back, review its processes, update or change where needed, and only then think in terms of applying ERP (a new system) to the change principles.

In the last analysis, there is the tradeoff: change the software, or shoehorn the change to the software.  There are costs, hard and soft, involved either way.  Managers of course are paid to determine the most cost-effective long-term solution to the clash.  Modifying software costs money.  Changing processes can cause confusion and stress.  But software that does not work the way the organization should is no bargain (or helpful tool) at all. 

When that happens, it’s time for a little reengineering.

Read Full Post »

« Newer Posts