Posts Tagged ‘ERP Implementations’

Panorama Consulting does a nice job of summing up their view of the key questions companies should ask themselves before embarking on an ERP implementation.  We would concur with virtually all of them.  While a different ten could be just as valid, these are a good starting point for ensuring your implementation team has asked the right ‘big questions’ before the hard work begins.  We’ll reprise them here today from an original posting they did here, adding a few comments from our own experience as well.


  1. Do you have the right team? You want the A Team, freed up when necessary to put serious attention to the new plans.  Add to that your vendor team implementation lead consultant, and project managers from both teams.  They should be in on all key planning meetings.
  2. What will the project’s org chart look like? Project roles need to be clearly defined.  Include project management, the core team, functional and technical resources, and key managers who will be involved in the business process analysis.
  3. What will the total cost of ownership (TCO) of the project be? Remember that project estimates are just that – estimates.  Leave margin for error for things not considered, discussed or discovered initially.  Don’t forget hardware, lost productivity or hidden costs beyond your vendor’s purview.
  4. What is the business case (cost justification)? There is always a projected ROI (Return on Investment), or you wouldn’t be doing the project, right?  Beyond the immediate exigencies, be sure you’ve identified the long-term cost benefits – they are often huge, and easily can justify a project.  Establish benchmarks or metrics early on, while understanding that it may take longer to reach them than originally projected (it’s the nature of the beast).  Each company will have its own business case, but yours should be widely shared and understood.
  5. What is your overarching implementation plan? Be sure you’ve worked out things like data migrations (there may be more than one), conference room pilots, necessary modifications and a user training schedule with your vendor.
  6. How will you handle third-party or external program integration? ERP systems don’t typically handle every single aspect of your business – and even if they could, that doesn’t mean that their approach would be your best choice.  Third party applications enable users to choose among best-of-breed solutions to narrower project requirements like shipping modes, EDI, e-commerce and other needs.
  7. What organizational change management strategies and tactics will you deploy? Roles, processes and sometimes even people will change, post-implementation.  Make sure you’ve thought about that ahead of time, so a clear transition strategy can be embraced.
  8. What project governance and controls will you put in place? Poor project management can, as Panorama notes, run a project off the rails.  Be clear ahead of time about who makes what decisions, how they will be made, what controls you will have in place and what issues or decisions will need to be made by the project steering committee.
  9. What milestones will you use to evaluate progress? Take time to evaluate your project at regular intervals, and identify key project criteria that you will compare to with each one.  Don’t be afraid to pull the cord to temporarily stop a project when things go off-track mid-course.
  10. How will you define success? Or as we like to say: What does ‘done’ look like?  This might be the hardest one of all, since continuous improvement – and ERP is simply a tool for continuous improvement – is never ‘done.’  It might be as vague as being better off than before, or as concrete as adherence to a fixed ROI figure.  Each company is unique.  Just be certain in the early going to have some frank internal discussions about what the right success metrics will be for your unique project, and its corresponding investment.


Read Full Post »

For folks contemplating an upgrade to a new business management system – given that many have been on old, or even ancient systems, for a very long time now – one question to ask early on can have a big effect on how well the implementation proceeds.  In essence, it comes down to this: Where does your company stand on the standardization vs. flexibility spectrum?

We are reminded of this question by the folks at Panorama Consulting, and we would concur that it’s an important question to ask oneself.

Standardization certainly has its benefits.  If you have reasonably clear, easy to understand (and teach) repeatable processes, you have the makings of a successful ERP implementation.  Generally speaking, if you can provide the logic process and stick to it, your software can be made to conform to that logic over and over again. It gets even better if your processes happen mostly to coincide with how your software works out of the box, more or less.

Some businesses can conform to that prescription.  Burger chains come to mind, though of course they’re not what we usually think of when it comes to ERP.  But the idea that even your company, say a manufacturer or a distributor, can set out process flows that are consistent over time and customer, implies that standardization could serve you well, and ease the pains of ERP implementation.

The downside is this doesn’t leave you as open to changing trends, industry shifts, or simply producing custom products.  One’s not better than the other, they just reflect different business models.

As a result, we (like Panorama) find some companies end up being too standardized.  They end up missing out on opportunities when they are unable to customize or configure to specific client needs.  The software side of that problem is that it often requires customization or modifications to accommodate that kind of flexibility.

In between these two poles comes resistance to change on one hand, or an insistence on abiding by standard business processes to the exclusion of what’s truly good for the business (like customizing product or getting creative in delivery).

There is no one-size-fits-all answer to the problem, any more than there is a “perfect” software solution.  Certain software products tend to be less customizable and more rigid, but may allow you sufficient room to embrace your own standard processes and keep everything simple.  Other solutions tend to be more complex, with the associated higher level of flexibility and customization, but with the attendant implementation cost and complexity.

Like we said, there’s no right answer.  But the question itself is one every company should wrestle with and discuss, both internally and externally, before making any final ERP decisions.

Read Full Post »

time_riskIn a recent post from Panorama Consulting, CEO Eric Kimberling – using the article title “Five Reasons Executives Say “No” to ERP Implementations (and How to Overcome the Resistance)” – points out some of the common pitfalls of ERP implementations.  Today we’ll blend his comments with ours, based on three decades’ of implementations on our part, and about half that much from Mr. Kimberling’s firm as well.  Together, we’ve seen a few things…

  1. They are worried that the project will take too long and cost too much. And he’s right.  Most projects, as notated in both annual surveys and real-world experience of implementers such as them and us, run long and go over budget.  There are several reasons for this, most all having to do with the fact that the projects involve humans.  Strong project controls and limits can help.  But in the end, no one can predict all the nuances and twists and turns and unexpected glitches and changes of heart and new things learned… that all occur along the way.  The key to managing this lies deeply in the partnership, agreement and underlying trust and confidence between the client team and the implementation team.  Communication is key.
  2. They are afraid of the project disrupting their daily operations. Statistics confirm this happens in about half of all projects.  We’ve experienced it ourselves in at least some parts of implementations.  We find that a thorough “quote-to-cash” testing scenario prior to going live – while usually easier said than done – can mitigate most of this risk.  It takes time, effort and investment, but it is possible to predict and correct most potential errors, albeit not all of them.  We recently did an implementation that by all measures was really successful – except, there were too many snafus in shipping, where more testing should have been done, earlier.  Live and learn.  Won’t happen again.
  3. Their own people are the real sources of resistance. This varies by company.  We always remind clients that while their employees are busy up to the ears in the final pre-go-live stages of implementation, they still have a regular job!  Be careful what you ask of your team.  Invest in thorough training of the users.  Have a realistic timetable (noting that projects nearly always take longer than predicted).  Be ready to hire temps to handle parts of their ‘regular jobs’ when needed.  Conduct frequent, regular, well-announced project meetings.  Involve all your stakeholders.  Communicate freely and openly about project goals and tasks.  Make your users central to your process analysis and organizational change management.  And listen to them.
  4. They don’t have the budget to pay for the initiative. Within some limits, the more detailed the pre-project spec, the more accurate the budget.  But, there are  You need a working relationship with a provider who can give you their best good-faith estimate as to cost and time.  Some items can be quoted accurately and/or on a fixed price basis, but many (i.e., exact amount of training required, change orders, sudden exposure of previously unknown processes or issues) cannot.  Here we like Panorama’s advice: “Define a realistic business case that captures not only the project costs, but also the potential benefits that your company is currently missing out on.”
  5. They are concerned that the new ERP system will not improve their business. No one’s interested in an investment with no return.  ROI matters most to execs.  To ensure your goals are met, begin  A process analysis can usually uncover numerous areas of redundancy, inefficiencies, recommended process changes, technology touch-points and advantages… the list goes on and on.  Quantify, and then monetize these.  Whether you use time studies or back of the napkin calculations, you can pretty quickly – if you’re honest and complete in your analysis – come to a fair calculation of all the cost savings inherent in an IT project, especially ERP.  Take the time to do the calculations.  Then recognize (and keep reminding yourself) that once you’re up and running, those cost-savings will repeat themselves year after year after year…

Read Full Post »

ocmBuried in a recent report on Organizational Change Management (OCM) from Denver based Panorama Consulting are five points that those of us who implement these systems would like to see every potential client embrace.

All too often we see ERP implementations viewed by their buyers as “a computer project” or a technology project – and that’s just so wrong.  It’s a BUSINESS project, and needs to be viewed at all times as the strategic business investment that ERP truly is.  Panorama’s report drives home five key reasons which we’d like to reprise for our readers today (with a healthy dose of our own commentary based on 30 years’ experience mixed in).

  1. Executive support needs to be focused on getting the job done right – not just “getting it up and running as quickly as possible.” Firms focused on getting it right understand the need for a balance between short-term implementation costs and long-term benefits.
  2. Business processes need to be well-defined up front. Given the amazing array of capabilities in today’s modern ERP systems, it is tempting to look solely to “how the software does things out of the box” to define your future stage.  That’s usually wrong too.  Successful businesses define how they want their processes to look first – because that is after all one of the keys to their competitive advantage — and then adapt the software to those processes, and not the other way around.
  3. Organizational change management is about more than just “training.” OCM is a structured approach to moving the business forward from its current state to a future state by taking stock of current processes and how they can be improved to deliver better future results.  Each stakeholder in an ERP project has a role in the process.   Stakeholders need to be empowered to embrace the change processes, contribute to them, and execute the changes.  An ERP implementation is the perfect time for all the above.  There is a lot of multi-directional communication required to make this happen successfully.
  4. Just getting the “tech part” of an ERP implementation alone is a daunting task. But much more is required.  Panorama says this one perfectly in our opinion, so we’ll quote them here: “Organizations need to focus on user acceptance testing, conference room pilots and other forms of testing the software against desired business processes and requirements.”  It’s not enough to make sure the software steps work or the modification doesn’t blow up – the business use must be vetted, validated and tested.  Otherwise, what’s the purpose of change?
  5. Benefits realization is focused on real business results. Tech-focused projects tend to set the bar relatively low: does it work as well as the old system?  Is it technically sound?  A business-focused project is more concerned with the higher vision of ensuring that the company is achieving tangible, measure improvement.  They set baselines for KPIs, and then use their implementation process – and many months thereafter – to tweak goals and performance.  What you don’t measure, you don’t improve – that’s the business-focused way of looking at ERP.

We wish every prospective customer would approach the purchase of their new or upgraded system with these considerations in mind – they’d be a lot happier, and more successful, in the end.

Read Full Post »

surestepToday we’ll briefly consider a question we get asked all the time: How long should our ERP project take?  Our comments are a mix of our own experience and input with those of other consulting, research and implementation firms (like one of our favorites, Panorama Consulting).

According to annual Panorama surveys, the “typical” (if there is such a thing) implementation for a software initiative is about 21 months, a pretty good average over the past several years – though they do see it trending up.  In our own experience 18 months to 24 months is a fair median.  Hopefully, those numbers help in terms of a starting benchmark when comparing to other organizations.

Of course, many software vendors will tell you that they can have you “up and running in a few months.”  Be wary.  We have found their assumptions to be unrealistic, as their “perfect world implementation scenario” may not apply to your company, and it’s highly likely they will make a lot of overly standardized setup assumptions that may not be appropriate for your company.  And if you’re in a complex environment, like say manufacturing or distribution… be even more wary.

As Panorama says: “Don’t believe the hype.”  Sales hype can easily lead to happy ears and unrealistic expectations.  It happens all the time.  Promises of rapid implementations due to trendy clichés like utilizing the cloud, or pre-configured best practices, sound enticing.  Just remember to take these for what they are: sales messages.  That’s not inherently bad, but we’ve found such statements are usually the very definition of ‘your mileage may vary.’  And it usually does.

Remember as well, your project team needs to invest time in changing processes for the better… in educating and training staff (not just in software, but in better practices)… and in addressing the change management complexities of figuring out who will do what, and how, in your new scenario.  These elements typically take the most time of all – and they simply cannot be rushed.

Adopting the right project management controls is a challenge that needs to be addressed clearly.  Implementations take longer than expected because controls aren’t in place, or aren’t being managed or followed.  Make sure you have a clearly defined set of project tasks and agreed upon solutions to workflow issues, roundly communicated to all.  Appoint a project administrator who acts as the control point for all major project decisions – especially those that could cause a change in scope, like customizations, process changes or project extensions that creep in and which, while perfectly valid, still need to be quoted and managed appropriately.

Finally, make sure that your project plan is complete and comprehensive.  That’s more or less implied by everything stated above, but not to be overlooked.  If you are missing key activities, or hope that skipping some elements will reduce the project timeline or cost, you’re setting yourself up with unrealistic expectations and a larger project than you expected – but should have known better.  There are few shortcuts in ERP, but countless stories of implementation time and cost overruns, too often caused by an unrealistic project plan in the first place.  If you only want to do it once, work closely with a trusted adviser to ensure that you are doing it right.  It all starts with a realistic, comprehensive, mutually agreeable and well-structured project plan with appropriate timelines, benchmarks and personnel assignments.



Read Full Post »

solutionWhen we first started doing ERP implementations back in the 80s (and we didn’t even call them “ERP implementations” back then…), the industry’s focus was mostly on technology, not business.  We have always been suspect of that approach, and sure enough, post year 2000, these implementations became very much about business.  I recall how in the run-up to Y2K, the focus was, largely, on making sure you were “Windows-compliant” and Year 2000 ready.

Today it may be a different story, but it your ERP implementation sure had better be all about the business focus.  Because that’s where the ROI lies.  That’s where process reform lies.  And that’s where you will find the roots of your business success in the next ten years.

Recently a post by Eric Kimberling wisely pointed out key differences between a tech-focused implementation and a business-focused one.  We’ll highlight his observations here, by noting 5 key differentiators:

  1. Executive support focuses on getting the job done right. Most successful business-focused implementations focus on getting the job done right the first time, and thus wisely consider the long-term business implications.   You only want to do this once (or every so many years) – so you’d best do it right and be sure to “find the right balance between short-term implementation costs and longer-term costs and benefits.”
  2. Business processes are well-defined up front. Don’t just throw caution to the wind and assume the new ERP system will automatically provide you with the path to better business processes.  The business-focused implementation requires a clear vision on management’s part about what you want your processes to look like, and they focus all the time necessary on business process analysis and reengineering.
  3. Organizational change management entails much more than basic end-user training. Training is just one component of having your employees adapt new software and deliver measurable results to the business.  Assessments pertaining to organizational readiness… impact… and a healthy discussion about changes… all should be a part of the mix.
  4. Testing focuses on business usage instead of technical stability. Getting the technical aspects of modifications and implementation tasks is hard enough.  But it’s not enough.  It’s critically important (and really should go without saying) that testing must be used to validate that the necessary business requirements will be met.  No one knows your business like you do, so companies must take a major role in ensuring that testing focuses on their business use.
  5. Benefits realization is focused on real business results. A technically sound implementation is not necessarily a successful one from a business standpoint.  Business-focused implementations, besides striving to be ‘on-time, on-budget’ focus on tangible measurable results.  They set baselines and targets and identify the key performance indicators that yield the most meaningful benchmarks in their business.  They then make sure to measure those results.

Remember that in the end, the purpose of your ERP implementation is to improve business results and streamline operations, not to impress the world with your technology chops.

Read Full Post »

ready_fire_aimPanorama Consulting is a Colorado based consulting firm that helps large companies with ERP selection and implementation.  But their advice often applies equally well to the small to midsize companies that comprise the lion’s share of modern ERP implementations.  In a recent article, the folks at Panorama ask which of the following 3 questions apply to your ERP project.  Notwithstanding the excitement that often surrounds the launch of such a project, they remind us of the importance of the old adage (which I borrowed long ago from Robert Duvall in the movie The Great Santini): Prior Planning Prevents Piss Poor Performance.

Key questions:

  1. Do you have a clear ERP blueprint? Developing a business blueprint (what our firm calls a Business Process Analysis) is a key first step to an ERP implementation.  Just as you wouldn’t build a house without a blueprint, so too you cannot safely wade into an ERP implementation without a roadmap providing a clear sense of how your business processes will, or should, look.  This is not about the technical or transactional aspects of an implementation – it’s about the business underpinnings that are driving the need for, and the future of, your new and improved business infrastructure. 
  1. Do you have a complete ERP implementation plan in place? To quote Panorama’s article directly (since they say it well)…A comprehensive implementation plan should certainly incorporate a vendor or VAR’s technical activities, but it also needs to include internal and non-technical activities, such as business blueprint, business process testing, organizational change management, infrastructure upgrades, data migration, and other critical activities” not always included in a standard (technical) vendor’s plan.  In other words: Think business


  1. Does the plan include organizational change management? Panorama offers six key organizational change management “work streams” (which they use to sell their services) but the larger point is simply this: Without organizational and process flow change – and their corresponding management – an ERP system is probably incomplete at best, and a fool’s errand at worst.  Be sure that your implementation addresses changes in workflows and reporting… that it includes ample staff training (in both the software and in some of the key principles of ERP, MRP and process change)… and that you’re benchmarking a few Key Performance Indicators against your firm’s most important financial success criteria.

We recommend clients give these questions fair consideration before putting money down on a system for which they have not adequately planned the business case.

Otherwise, you run the risk of Ready, Fire, Aim!

Read Full Post »

Older Posts »