News & Views | ERP

News & Views is published monthly by 180 Systems. Our objective is to provide recent articles to our readers on business technology topics. In some cases, our blog contains a title with a hyperlink to a source article, a quote from the article and our comments. In other cases, we have provided a blog without a hyperlink for original content by 180 Systems. We encourage you to post your own comments. You can also access our blog by topic.

Statement of Work (SOW) Stoppers

Contract Negotiations, ERP, Software Selection

The SOW is a key document from your vendor that can make or break the implementation. The vendors will do their best to reduce their risk by limiting scope to a high level list, assuming that you will follow best practices, and making a lot of other assumptions about you doing work that you don’t know or understand the effort to complete. 

As the vendor risks go down, the customer risks go up.  We recommend the following:

  • Scope is tied to the requirements in the RFP which need to be specific
  • Best practices should only be applied to processes that are considered basic.  It should not be tied to ones that allow a company to differentiate themselves from the competition or address critical success factors (what an organization must do well in order to be successful strategically). You should limit the best practices to a few basic processes such as accounts receivable and accounts payable.
  • Ensure you understand what is involved in your roles and responsibilities. Many organizations don’t have the experience or qualifications to do some of the tasks that may be assigned to them without a lot of help from the vendors. An example of this is developing to-be business process documentation.  If you don’t have a resource on your team with the skill set to do this, you may be setting yourself up for a vendor change order.

A good way to limit scope for both the vendor and the customer is by arranging a “paid-for” business needs analysis (BNA) or discovery process prior to signing any long-term contracts. This should not delay the implementation process as it is work that would need to be done anyway. It should also not be a full-blown design phase by the vendors. It should be enough work for the vendors to define scope clearly and provide a fixed or not-to-exceed fee to do the implementation. It will also involve deciding what to do with all the requirements that are not met out-of-the-box by the vendors which include customization or custom reports, 3rd party modules, changing the process and workarounds.

The vendors would rather close the deal without doing the discovery if possible but we think this is short-sighted. In the end, the vendors don’t want unhappy customers and taking this extra step will help reduce the risks of unexpected and costly surprises during the implementation.

0 Comments

So the project has gone belly-up, what now?

ERP, Project Management

December 3, 2015 from LinkedIn – “…Most SMEs and many larger companies are not experienced in running projects. It is just not something they need to do on a regular basis and certainly not with this much at stake.  An investment in the services of a skilled internal Project Manager is rarely a waste of money. It will often cost you more to skimp in this area and then have to recover afterwards…”

180 View – The author, a business development manager for Pronto Software, makes a number of really good comments on why implementation projects fail and what to do about it. I have acted as an ERP expert witness and have seen just how bad things can get. It is far better to find a solution to the problems than to fight it out in court.

0 Comments

Demonstration Scripts

ERP, Project Management

A demonstration script is critical to the selection process but there are huge differences on how to do this. Rather than criticize the techniques we have read, I will share our methodology with you:

  1. Two demonstrations – You don’t want to go too deep on the first demonstration unless you are positive that the vendor will not waste your time (or their time)
  2. 1st demonstration – We base it on a small subset of the most important requirements in the RFP and limit the time to about 3 hours. We allocate a certain amount of time to each requirement and then total the amount of time for each section. We provide an agenda that includes the agenda time for each section as well as the scripted time and try to leave a buffer in certain sections.  There are usually 4 vendors invited for this demonstration.
  3. 2nd demonstration – We base it on the AS-IS business process and include sample documents. We ask the vendors to prepare a prototype of the suggested TO-BE business process and to include a certain number of the requirements from the RFP. We are evaluating vendors not just on the strengths of the system but also on their ability to improve business process. There are usually 2 vendors invited for this demonstration which often lasts for a day for each vendor.
  4. Access to clients – The vendors have access to our clients before each of the demonstrations. We want them to have every opportunity to do a great demonstration.
  5. Evaluations - Our clients are asked to note the major strengths, weaknesses and follow-up items by section as well as scoring each section. We do a detailed evaluation which includes notes on each requirement demonstrated as well as an assessment whether it is a strength or a weakness.

Our process is always evolving based on the feedback we get. Recent changes include:

  • Reducing the number of requirements
  • Using Survey Monkey for the evaluations done by our client
  • Adding more buffer time so vendors can make the presentation flow better and let them show off some of the features in the system that may not be included in the script but which they believe are very useful
0 Comments

Should you restrict ERP selection to just the major vendors?

ERP, Software Selection

We don’t think so. There are many excellent products built by small companies for specific industries that are worthy of consideration. But there are risks that the vendor will not be around for the long haul. There are a number of ways to evaluate long-term viability:

  • The system is built with old technology that is getting really difficult to support by the boomers ripe for retirement.
  • There is a lack of investment in the system. Ask to see the product roadmap and recent enhancements.
  • The company is not profitable. Private companies will be reluctant to release this but it can be obtained with an NDA late in the selection process. There can be extending circumstances such as the company now offers a subscription fee rather than up-front license fees.
  • There is a lack of good people available for implementation and support. Ask for resumes and meet members of the team.
  • Customers are not so happy with support. Ask for references that can be called or visited in person.
  • The owners are nearing retirement age. Ask them directly about their plans. Systems with a good client base and using recent technology will be purchased and will very likely be maintained and enhanced by the acquiring company who should know better than to alienate new customers. However if the technology is old or not built with industry-standard tools, then who can blame the new vendor from encouraging clients to convert to one of their other systems.

There are also advantages to being a bigger fish in a smaller pond.

0 Comments

How to measure whether an ERP implementation is successful

ERP, Project Management

It’s not time to celebrate when the system goes live. Nor is it time to celebrate even if it’s on time or on budget. It’s only time to celebrate if the benefits in the business case have been realized. Ideally the benefits are in the form of a measurable metric or a Key Performance Indicator (KPI) such as the time it takes to process an order. However many organizations don’t identify these measures of success and even if they do, they promptly forget about them as soon as the implementation starts as they have enough on their plates to consume each day and then some.

So what do you do to keep the KPIs relevant? We recommend that the goal KPIs be embedded in the project from the start so that everyone is aware of them. Subject matter experts involved in designing and testing should be questioned whether the goal metrics are attainable at various times throughout the implementation. Steering committee meetings should include updates of whether the goal metrics are at risk of being attained. Sometimes attaining the goal KPIs puts the budget and schedule at risk. When this happens, you need to get the steering committee to consider budget and schedule variances.

 

0 Comments

How to get an accurate estimate of ERP implementations costs

ERP, Software Selection

We ask the finalists in our software selection projects for a detailed breakdown of implementation costs by module (g/l, a/r, a/p, purchasing…) and by task (customization, integration, conversion, project management, design…). We provide them with a lot of information to make the estimate possible:

  • detailed requirements
  • business process review which includes process, problems, type of problem, and impact of problem
  • high level process maps
  • access to our client to get the tour and ask whatever questions are needed

The finalists are asked to demonstrate a prototype of the to-be business process allowing them to validate assumptions. But sometimes, even with all this information, the vendors still can’t nail down the costs because of the unknowns. We then ask the vendors to conduct a paid-for consulting assignment to do some of the work they would have done in the design phase to arrive at more accurate numbers prior to signing a long-term contract.

1 Comment

ERP Cost Estimates

Business Case, Contract Negotiations, ERP, Software Selection

Buyer beware when estimating the costs of an ERP implementation. There are so many unknowns that make it really tough to avoid unpleasant surprises. The vendors are very reluctant to fix price anything when it comes to the services required because of the many unknowns – scope of work, who does what, capabilities and available time of buyer resources…. It’s especially difficult for the vendors in the early stages of the selection process. At the same time, the buyers want to have a decent ball park of costs before pursuing a potential solution.

But there are guidelines that will help. When it comes to license or annual fees, it’s fairly easy to come up with a number as it’s based on number of users and high level scope. You should be using a rule of thumb for the implementation services which can be estimated as a ratio of implementation to license fees as follows:

  • 1:1 for a straight forward implementation with relatively simple requirements
  • 1:5:1 for an implementation with some complexity of requirements and little or no customization
  • 2:1 for an implementation with a lot of complex requirements and some customization
  • 3:1 for an implementation with a lot of complex requirements as well as a lot of customization

Other costs to consider:

  • Maintenance – the vendors will provide a % but make sure that it includes adequate levels of support. The vendors have been pushing their maintenance %’s ever higher despite the competition. Assume at least 20%.
  • Travel – it can be as high as 15% of implementation fees
  • Upgrade fees – many systems that are installed on premise or on private clouds will have upgrade costs every few years which should be a small % of the implementation fees.
  • Internal costs – you need to know who will be involved and the extent of their time as well as their approximate cost to the company
  • Legal fees
  • Infrastructure changes – you need to get an idea of the recommended infrastructure for the new system and what it will cost to acquire and install it.
  • Consultant fees – you may want some coaching services from a company like 180 Systems.
4 Comments

ERP software survey 2015

ERP

September 1, 2015 from CPA Magazine and written by Michael Burns – “Welcome to our annual vendor survey on enterprise resource planning (ERP) software…” This year’s article is mostly about elusive ROI and what to look for when it comes to technology. The survey includes almost 100 ERP systems with key information for the following categories:

  • Company Profile/Target Market
  • Geography
  • Language
  • Industry
  • Technology
  • Applications
  • Generic Features
  • Business Intelligence
  • Financial
  • Budgeting and Forecasting
  • Fixed Assets
  • Distribution
  • Manufacturing
  • Professional Services
  • Construction
  • Service Management
  • Human Resources
  • Document Management
  • CRM
  • eCommerce

 

1 Comment

Technology investment survey (ERP, CRM and BI)

Business Case, ERP

June 1, 2015 from CPA Magazine and written by Michael Burns – “Making a business case for technology investments is challenging – and potentially career limiting. Anything you can learn from our peers’ experience in making these investments can be helpful in crafting a case. That is why we decided to run our own IT satisfaction survey in CPA Magazine. It ran from January to April 2015, and is available by clicking here.

0 Comments

Beyond ERP and new technology, new options

ERP

2014 from PwC – “…The brave new world of business application software is rapidly transforming how corporate IT departments source and implement all kinds of critical systems. Perhaps nowhere is this truer than in the realm of ERP systems, the software that runs virtually every large company in the world. CIOs are rethinking their approach to ERP, thanks to modular, cloud-based business applications that offer viable alternatives to the unwieldy, inflexible, and expensive systems that have long dominated the sector…”

180 View – The idea is that you can stitch together best of breed cloud-based/Software as a Service (SaaS) applications with a core ERP system and create what they call “hybrid ERP”. PwC cautions that the “the hype surrounding these new technologies is sky-high.” We believe that technology for integrating different applications has been around for years and has been called different things including web services and service-oriented architecture (SOA). Web services and SOA technologies were hyped as a panacea to integration between applications but gradually the hype subsided and reality set in. Hopefully one day the reality will match the hype.

0 Comments