5 Keys For Maximizing Your ROI Through Optimal ERP Performance - A Software ERP Directive

Key No 1 - Charting the course of success for your technology investment

Is your current ERP system is lacking in functionality? Does it limit your ability to respond quickly to customers' requests? Where are you placed in comparison with your competitors, and does your existing system help you or hinder you in meeting industry best practice or benchmarks? Are you simply unhappy with your current supplier and their ability to respond to your requirements, let alone those of your customers?

Whatever the case, you are unlikely to stand alone in these areas - many companies have faced similar issues with their ERP systems, so no user is likely to be unique. There are common drivers you can consider in your deliberations over a replacement ERP system, and these include the measures you use to chart the success of your technology investment, the major issues you need to address and the consideration of how much pain you are willing to put up with to achieve your ultimate goal.

According to Aberdeen Group's 2007 ERP in Manufacturing Benchmark Report, 328 companies out of 1245 companies surveyed were planning to replace their current ERP systems at one or more locations within the next three years. In other words, at any one time, a quarter of companies are looking to replace their existing ERP systems.

In the past, enterprise resource planning has garnered a mixed reputation. While there are fundamental reasons and obvious benefits for going down the ERP path, many have feared - rightly or wrongly - that ERP entailed major organisational disruption if not re-engineering, at high cost and high risk.

Aberdeen Group reports ("When Replacing ERP - Size Matters", June 2007) the primary driver for large companies is consolidation and rationalisation strategies. An underlying issue, considering the proliferation of ERP and other enterprise applications, is the need for integration. For mid-sized and small companies, on the other hand, the concerns are more with gaining functionality and integration. These sized firms are also more heavily concerned with updating their outdated user interfaces, an important factor in raising employee productivity and efficiencies.

Other issues include requirements of expansion, pressure from trading partners, compliance with regulation and even disastrous events, but overall companies looking at ERP implementations are primarily seeking "low cost options that minimise risk".

Risk and cost in combination imply a concern for return on investment, but Aberdeen's surveys show that fewer than 25 per cent of respondents consistently estimate ROI to cost estimate ERP projects, and 20 per cent or less measure the actual post-implementation costs and gains to calculate ROI.

In contrast, "best in class companies are on average 88 per cent more likely to estimate ROI before initiating projects and are 130 per cent more likely to measure ROI after project completion. As a result, these best performing companies produce, on average, 93 per cent more improvement across a variety of metrics such as cost reductions, schedule performance, headcount reduction or redeployment and quality improvements."

The reality is that minimising risk with an ERP implementation is an achievable result and, by minimising risk, costs should also be kept under control. By following a formal process of charting the reasons for your implementation, assessing the various offerings from your current supplier and, importantly, from suppliers who might be new to you, and checking off against the various criteria for selection, an ERP implementation need not be a nightmare; in fact, it could prove to be the instigator of quantifiable benefits for all concerned.

Specific success markers

Getting down to brass tacks, there are a number of key aspects of an ERP system that need to be addressed, both prior to any decision to move to such a system and certainly as part of selection criteria. Near the top of the list is total cost of ownership, which incorporates:

• Software and implementation costs;
• Costs associated with any interfaces or system modifications;
• All costs associated with system communications;
• Costs associated with employing additional or specialised staff; and
• Annual costs for system upgrades and helpline support.

Other specific areas of consideration that will impact on the success or otherwise of your ERP program include:

• Functionality;
• Ease of use;
• Integration capabilities;
• Ease and speed of implementation;
• Ability to tailor functionality without programming; and
• Software licence price.

Added to this, or overarching these considerations, is return on investment. Whether and how quickly you achieve this is dependent on many factors, not least the rigour and realism applied to the assessment of current circumstances and the contribution made by the ERP system as outlined in initial business cases. An article as far back as the European Journal of Information Systems in 1996 reported on a survey of the 200 largest UK companies that found that 47 per cent openly admitted to overstating the benefits to get approval for IT investments.

But wishful thinking and creative accounting aside, these are all relevant considerations. (And in future articles, covering total cost of ownership, selection criteria, best and worst practices, and maximising ROI, we will look at them in more detail.) But it should be noted that the level and mix of these factors and how successfully they are achieved is specific to individual sets of circumstances, including size and type of organisation, intended purpose, individual business priorities and, of course, budget.

The big picture

The overriding consideration that affects all organisations, large or small, regardless of industry sector or even of budget, is alignment with the business objectives of your organisation.

Jerry Luftman and Rajkumar Kempaiah of the Stevens Institute of Technology suggest ("An update on business-IT alignment", September 2007) that the issue of achieving IT-business alignment was first documented in the late 1970s and was in the top 10 IT management issues from 1980 through 1994, as reported by the Society for Information Management. Since 1994 it has consistently been issue #1 or #2.

Nonetheless, it has proved to be an elusive target. Luftman and Kempaiah suggest a number of reasons for this, including that, while IT might be aligned with the business, business is rarely aligned with IT. They also add that organisations have often looked for a 'silver bullet', whether technological solution or improved communications, as well as improved governance to identify and prioritise projects, resources and risks. Another reason they suggest for missing the alignment target has been the lack of an effective tool to gauge the maturity of IT-business alignment.

On this last point, they suggest a set of six components that indicate (if not mandate) alignment maturity: Communications - exchange of ideas, knowledge and information between IT and business; Value - balanced measurements to demonstrate the contributions of information technology and the IT organisation in terms that both business and IT understand;

• Governance - who has authority to make IT decisions and set IT priorities;
• Partnership - including IT's role in defining business strategies, the degree of trust and how each perceives the other's contribution;
• Scope and architecture - IT's provision of flexible infrastructure, evaluation of emerging technologies, driving business process change, and delivery of customised solutions internally and externally; and
• Skills - HR practices of hiring and retention, encouragement of innovation, developing individuals' skills, and the organisation's readiness for change, capability to learn and ability to leverage new ideas.

Interestingly, they say that "business executives score alignment maturity higher than IT executives". In other words, it is the IT side of the business that feels most that alignment is not being achieved. Whether your organisation complies with these suggestions - and it should be added that sometimes these factors can be seen as reflections of alignment maturity as opposed to stepping-stones for achieving that heightened state - any IT implementation, especially one as significant as ERP, should keep all of these factors top of mind.

Supply chain criteria

Many ERP systems are implemented as part of the supply chain process of an organisation. Here, again, the above success markers are relevant, but Tim Payne of Gartner ("Supply chain and IT strategies must align around five key themes", August 2007) suggests that "enterprises should focus on five technology areas - business process agility, data management, analytics and performance management, collaboration, and sensory networks - as the sources of technology-enabled supply chain innovation".

Payne says "focusing on these technology areas will give the IT organisation more credibility as an ongoing participant in the dialogue [with the supply chain organisation]". He goes on to recommend:

• Periodic demonstrations of new technology capabilities, coupled with the co-development of supply chain initiatives, as new capabilities arise in these areas;
• Developing a plan for incorporating new infrastructure components that are needed to support innovation areas; and
• Evaluating the supply chain IT strategies and SCM vendor-sourcing criteria with the supply chain organisation for conformance and alignment based on the five key themes and related discussions, adjusting IT and sourcing strategies to address perceived gaps.

All well and good. But, despite the best planning and setting of firm criteria, there is always the issue of compromise - that such an important and far-reaching a system as an ERP will not perfectly match your organisational set-up. The Aberdeen report suggests that "if your business processes were developed over time - in an unstructured way - the possibility exists that no ERP system will match exactly. Search out ERP solution providers with customers in your industry, evaluate the fit, and balance the need to adapt your business processes to conform with the software against aligning the software to your processes. While some customisation of software may be necessary, (only 11 per cent of respondents have zero customisation) it adds expense and effort to the initial implementation, and the complexity of future upgrades."

In other words, if you bend a little to accommodate the ERP, while still maintaining your markers of success, you will find that the ultimate payback is a system that works well with an organisation in sync with itself.

It is important overall, therefore, to look at all options, and that includes a range of suppliers, to assess the issues, drivers and pain points that you may have been facing in the past, and that you might be looking to deal with or, hopefully, avoid in the future to ensure the best fit for your organisation.

The next article in this series will look at "Managing the total cost of ownership - What you need to know".

References:

• Jutras, C., and Barnett, R., "The total cost of ERP ownership in large companies", Aberdeen Group, July 2008
• Jutras, C., and Dalle Tezze, H., "When replacing ERP - size matters", Aberdeen Group, June 2007
• Jutras, C., Trost, J., and Dalle Tezze, H., "Taking the ERP plunge for the first time", July 2007
• IBS, "5 things you should know about total cost of ownership (TCO) for ERP systems", IBS Australia, March 2008
• IBS, "6 essential considerations when selecting an ERP system", IBS Australia, February 2008
• Luftman, J., and Kempaiah, R., "An update on business-IT alignment: 'A line' has been drawn", MIS Quarterly Executive, Vol 6 No 3, September 2007
• Payne, T., "Supply chain and IT strategies must align around five key themes", Gartner Research, August 2007
• Ward, J., Daniel, E., and Peppard, J., "Building better business cases for IT investments", MIS Quarterly Executive, Vol 7 No 1, March 2008
• Ward, J., Taylor, P., and Bond, P., "Evaluation and realization of IS/IT benefits: an empirical study of current practice", European Journal of Information Systems (4), 1996, pp 214-225 (as cited in Ward et al, 2008).

IBS Australia develops ERP solutions, ERP systems and business management supply chain software for inventory management systems, manufacturing ERP software, business intelligence systems and integration ERP software

Peter Clarke will present on ERP Systems at the Gartner 2008 ITxpo, 11-14 November to be held in Sydney, Australia

http://www.supplychainsecrets.com.au/gartner
http://www.ibs.net/au/solutions/erp-system.jsp

Article Source: http://EzineArticles.com/?expert=Peter_T_Clarke

By Peter T Clarke

Keys For Maximising Your ROI Through Optimal ERP Performance - Maximise Your Business Benefits & ROI

It goes without saying that, despite the best planning and implementation processes, the proof of an ERP project is in the business benefits and the return on investment achieved. A well-executed project is less than successful if there are no benefits or returns. This should be obvious to all, and this should be the primary focus of every project, in any field.

But judging by the number of 'failed' projects - whether this means never being completed or simply not living up to expectations - one would be forgiven for wondering if this overriding priority is forgotten in many cases. The attitude that "the operation was successful but the patient died" must be avoided at all costs, and it is an attitude that must be avoided throughout the project lifecycle.

Realising the benefits of your ERP implementation is determined by the actions taken in the initial planning stages of a project, as well as the result of how well the system is used once it is up and running. Poor planning can mean limited or even zero benefits or, at worst, a highly negative impact on the organisation. There are cases where organisations have suffered terminal effects of a poor implementation.

Companies focus on the process of selecting and installing ERP software systems but once the initial project is complete, it often happens that both the original team and the business focus move on, whether or not all the original goals have been achieved. The end result is something of an instant legacy system, with no budget or plan for further training or realisation of business objectives.

It cannot be emphasised enough that business benefits come after the project is complete. This is often a difficult issue to manage during the implementation phase, as those involved require faith in the project that the benefits will be achieved, but often see little evidence of this during the implementation itself.

A good example of this is in the consideration of modifications. It is often easier for project teams to request a modification to maintain the status quo and appease business users rather than try and introduce an improved process. For this reason any modification must be endorsed by the business leader most affected by the modification and reviewed by his peers.

Where possible the benefits should be built into operational plans budgets to ensure they are realised. This will encourage business managers not directly involved with the project to maintain an interest as they know they will be measured once it is in operation.

Joe Peppard et al referred to this in an article in MIS Quarterly Executive (called MIS1 from here on): "With the information technology investments, most organisations focus on implementing the technology rather than on realising the expected business benefits. Consequently, benefits are not forthcoming, despite a project's technical success."

They go on to say: "When considering return on investment calculations, organisations are so pre-occupied with manipulating the denominator - reducing spend - that they do not focus on the numerator - how IT can generate significant benefits. Equally worrying is the traditional investment appraisal process, which is often seen as a ritual that must be overcome before a project can begin. Many benefits are overstated to get the project through this process.

"No wonder few companies engage in post-implementation reviews. They already know that many of the benefits described in the business case are unlikely to be achieved."

As cynical as this last judgement is, there is an element of truth in it. But it needn't be so. There are ways to ensure - or, at least, to maximise - the business benefits that your ERP implementation can achieve.

Peppard et al, in another article (MIS Quarterly Executive, March 2008 - called MIS2 from here on), say "There is an important difference between investment objectives and benefits. Objectives are overall goals or aims on the investment, which are agreed on by all relevant stakeholders. In contrast, benefits are advantages provided to specific groups or individuals as a result of meeting the overall objectives."

They suggest (in MIS1) that, underlying an ERP project proposal, there should be five principles adhered with in order to realise value through IT.

Principle #1 is that IT has no inherent value. "Just having technology does not confer any benefit or create value. The value of technology is not in its possession. In fact, IT spending only incurs costs. Benefits result from effective use of IT assets."

Principle #2 is that benefits arise when IT enables people to do things differently. "Benefits emerge only when individuals or groups within an organisation, or its customers or suppliers, perform their roles in more efficient or effective ways. Generally, these new ways of working require improving how information is used."

Principle #3 says that only business managers and users can release business benefits. "Benefits result from changes and innovations in ways of working, so only business managers, users, and possibly customers and suppliers, can make these changes. Therefore, IT and project staff cannot be held accountable for realising the business benefits of IT investments. Business staff must take on this responsibility. Getting business staff to acknowledge this principle is a key way to ensure that they become involved in so-called IT projects."

Principle #4 reminds us that all IT projects have outcomes, but not all outcomes are benefits. "Many IT projects produce negative outcomes, sometimes even affecting the very survival of the organisation. The challenges for management are to avoid such negative outcomes and to ensure that the positive outcomes deliver explicit business benefits.

Principle #5 says that benefits must be actively managed to be obtained. "Benefits are not outcomes that automatically occur. Furthermore, the accumulation of benefits lags implementation; there can be a time gap between initial investment and payoff. Therefore, managing for the benefits does not stop when the technical implementation is completed. Benefits management needs to continue until all the expected benefits have either been achieved, or it is clear they will not materialise."

To implement an ERP project based on their five principles, Peppard et al recommend that seven key questions should be asked, the answers to which "are used to develop both a robust business case for the investment and a viable change management plan to deliver the benefits".

These questions are:

• Why must we improve?
• What improvements are necessary or possible?
• What benefits will be realised by each stakeholder if the investment objectives are achieved?
• Who owns each benefit and will be accountable for its delivery?
• What changes are needed to achieve each benefit?
• Who will be responsible for ensuring that each change is successfully made?
• How and when can the identified changes be made?

They do warn (MIS2) that "Some benefits can only be measured by opinion or judgement. ... Quantifiable benefits are ones where an existing measure is in place or can be put in place relatively easily. Since quantifying benefits inevitably involves forecasting the future, the challenge is to find ways of doing this as accurately and robustly as possible."

But an ERP system does not stand alone, and realising benefits often relies on other, external inputs. ERP software systems are largely data dependent and data driven and the key to realising the full benefits is integration. If information is incomplete or inconsistent it becomes very difficult to integrate reliably and the results can lead to a loss of business confidence in the system and increased non-productive work load for support personnel.

Often day-to-day operation of systems falls to staff who weren't involved during the initial implementation and who have not received the same levels of training and handover as the original team. As a result effective system usage tends to deteriorate over time.

Your approach, then, to realising benefits of an ERP implementation (or any IT project, for that matter) relies on taking an holistic approach, which means not just all participants and stakeholders, but also all inputs. And this also means across the entire spread of a project - from the very first inkling of a suggestion or realisation of a need, to the end project and, importantly, beyond - to the ultimate users and how they will react to and live with the system that has, hopefully, been fully implemented. An implementation is not successful until anticipated benefits are achieved - largely after implementation - or a good reason established for why they won't be. Responsibility, therefore, for doing this rests with many players, at many stages.

Complex? Yes.

Difficult? Maybe.

Essential? Absolutely.

References

• Clarke, P., "How to maximise your investment in ERP technology", June 2008, IBS Australia
• Peppard, J., Ward, J., and Daniel, E., "Managing the realisation of business benefits from IT investments", March 2007, MIS Quarterly Executive
• Ward, J., Daniel, E., and Peppard, J., "Building better business cases for IT investments", March 2008, MIS Quarterly Executive

IBS Australia develops ERP solutions, ERP Systems and business management supply chain software for inventory management systems, manufacturing ERP software, business intelligence systems and integration ERP software.

http://www.ibs.net/au/solutions/manufacturing-software/

http://www.supplychainsecrets.com.au/gartner

Article Source: http://EzineArticles.com/?expert=Peter_T_Clarke

By Peter T Clarke

Keys For Maximising Your ROI Through Optimal ERP Performance - Critical Factors & Classic Mistakes

By Peter T Clarke

The complexity and wide encompassing nature of ERP means that there are inherent challenges in any ERP implementation. The issue is to ensure that these challenges enhance the project and final outcome rather than become problems or disasters that undermine the project's viability.

According to Carol Ptak, failure is "an implementation that does not achieve a sufficient return on investment identified in the project approval phase. Using this definition, it has been found that failure rates are in the range of 60-90 per cent."

This is a fairly uncompromising definition of failure. The industry and the media are rife with stories of more dramatic IT project failures, and sometimes even disasters, and these are occasionally even backed up with reliable information and data. The Standish Group's oft-quoted and on-going CHAOS study suggests that two out of every three IT projects fail - ie succumb to total failure and cancellation, or suffer cost overruns, time overruns, or a rollout with fewer features or functions than promised. Sometimes these failures have disastrous consequences beyond time and budget, and can seriously impact on the continued existence of the organisation itself.

But every IT implementation need not end in disaster. In fact, by studying the nature of past failures and finding common elements, mistakes and problems can be avoided.

R. Ryan Nelson (MIS Quarterly Executive, June 2007) investigated a number of 'infamous' IT project failures that in some instances involved sums in the billions of dollars. A post-mortem of these projects revealed that "While some of the projects experienced contractor failure, others cite poor requirements determination, ineffective stakeholder management, [over-extended] research-oriented development, poor estimation, insufficient risk management and a host of other issues."

And what is our reaction when something does go wrong? Nelson says that "We tend to make some mistakes more often than others. In some cases, these mistakes have a seductive appeal. Faced with a project that is behind schedule? Add more people! Want to speed up development? Cut testing! A new version of the operating system becomes available during the project? Time for an upgrade! Is one of your key contributors aggravating the rest of the team? Wait until the end of the project to fire him!"

Nelson cites an on-going study at the University of Virginia into the reasons for project failure. During 2006, the students in the Master of Science degree in the Management of IT program studied 99 projects to elicit any common lessons, regardless of whether or not the project was ultimately considered a success.

"The first major finding," he reports, "was that the vast majority of the classic mistakes were categorised as either process mistakes (45 per cent) or people mistakes (43 per cent). The remaining 12 per cent were categorised as either product mistakes (8 per cent) or technology mistakes (4 per cent). None of the top 10 mistakes was a technology mistake, which confirms that technology is seldom the chief cause of project failure. Therefore, technical expertise will rarely be enough to bring a project in on-schedule, while meeting requirements. Instead, the finding suggests that project managers should be, first and foremost, experts in managing processes and people."

He goes on to add that, while scope creep did not make the top 10 mistakes, "the fact that roughly one out of four projects experienced scope creep suggests that project managers should pay attention to it, along with its closely connected problems of requirements and developer 'gold plating'".

"Two other surprising findings were contractor failure, which was lower than expected at #13 but has been climbing in frequency in recent years., and adding people to a late project, which was #22, also lower than expected.

"The third interesting finding is that the top three mistakes occurred in approximately one-half of the projects examined. This finding clearly shows that if the project managers in the studied projects had focused their attention on better estimation and scheduling, stakeholder management and risk management, they could have significantly improved the success of the majority of the projects studied."

Recognising problems and potential problems is one thing; doing something about them, preferably before they occur or incur great harm, is another.

Below is a summary of "six fatal mistakes" in ERP implementations, along with methods that can be employed to avoid or, at worst, rectify them.

The failures and methods to avoid them are:

Ineffective project leadership.

There are many different aspects to this and they are by no means all controlled by the Project Sponsor and the Project Manager. Leaders in all areas affected by the project need to have a clear understanding and commitment to the reasons for the project and its end goals. Without their support, the project team will often be side tracked on insignificant issues by end users with their own personal agenda. Commitment starts with the Project Charter which should clearly articulate key aspects of the project. Project Charter approval should not be taken lightly in an effort to achieve an early milestone. Many Project Managers have been frustrated by people who have signed off a Project Charter without fully understanding what they have committed to. This always manifests itself during the tough times when it is least helpful.

Leadership also embraces the management of risks both from a project perspective and the management of the on-going business during the implementation. The company cannot afford for either to fail, yet it is often key resources who are forced to make priority decisions instead of the company leaders who should understand the overall picture.

Modifications to the standard system are at the forefront of potential mistakes. The leadership has an important role to play. Any modification that is proposed should be endorsed by the business leader most affected by the modification. This endorsement should incorporate clear reasons why the standard solution cannot be used and what benefits will be achieved. Where possible the benefits should be built into operational budgets to ensure they are realised.

Lack of frequent and realistic milestones throughout the implementation project.

In developing your project plan, you should always have the ability, at any time, to answer three critical questions - where are we? are we there yet? and how do we confidently know we are there? By setting frequent milestones at key points along the project timeframe, you will be able to quickly measure your progress and more importantly celebrate achievements with the team. Of course, this is also the time to make adjustments if, for whatever reason, the project is not going to plan. The important thing is to ensure that any milestones set are simple and realistic.

Having no dedicated, high quality people in your implementation team and no compensation scheme in place for them.

The reality is that the people you really need in your implementation team are undoubtedly your best people, and it is almost guaranteed that they are also the busiest and least able to find additional time for the project in hand.The best thing you can do is to offload some of their daily workload onto junior staff. And by giving junior staff the chance to prove themselves at a higher level, you also gain a wider spread of skills in the business and identify potential promotions at the same time.

The many different ways of rewarding project staff for their achievements range from revised job descriptions and salary scale to higher duty payments. The most effective, is a double bonus scheme, made up of a financial bonus against achieving major milestones and a public recognition or even celebration at each relevant stage. An extended leave at the end of the project may also be effective.

In the overall scope and cost of your project, the additional bonus and public recognition will pay dividends well past the life of the project. Bonuses should be significant enough so that recipients feel proud and respected rather than cheated.

Lack of adequate budget for training users on the new system.

Almost every organisation approaching systems implementation fails to budget sufficient dollars and time for training and the end result is that uptake on new systems, processes, policies is slow and the immediate effect is longer time to benefit. It is normally true, he adds, that whatever figure you have budgeted for training, you should double.

Making modifications to the standard system without carefully weighing benefits against risks.

There is a tendency in many organisations to quickly modify the system in areas where it does not match present business processes. The end result of this is a system where future upgrades become extremely difficult to apply and any help desk support is always compromised because of the need to know the modifications as well as the standard system before any help can be offered. The approach is to apply three "whys":

• Why are we considering this request for a modification and what is the proven measurable benefit?
• Why haven't we looked at all the alternatives and their risk/benefit first before choosing to modify?
• Why don't we see what other companies have done in this area? Unless we are the first, there must be lessons out there that we can learn from.

Failing to protect and insure the most critical parts of your business.

One example is of a managing director of a large pharmaceutical firm who wanted three guarantees before signing a contract for a new system:

• That his system would never, never put him in a position where he couldn't take orders from customers,
• That his new system would never, never prevent him from dispatching customer orders from his warehouse, and
• That his new system would never, never put him in a position where he couldn't accept his customers' payments and put their money in his bank account.

The lesson of this is to take a hard look at your business and identify the critical areas that you need to have available 24/7 and then talk to your hardware and software vendors to make sure they can provide adequate backup/recovery options to keep you operational when the unexpected happens.

Even with so many catastrophic examples of companies going bankrupt due to failed software implementations, many companies still don't pay enough attention to the risks involved. Adequate planning and preparation is essential to help you identify and manage potential risks. Previewing is just as important than reviewing, certainly when it comes to avoiding potential disasters. By previewing your current business practices, goals, risks and articulating a solid implementation plan, you can go some way (at least) to making the life of your ERP project that much less risky.

References:

• Nelson, R. Ryan, "IT project management: Infamous failures, classic mistakes, and best practices", MIS Quarterly Executive, June 2007
• Ptak, C., "ERP: Tools, techniques and applications for integrating the supply chain", 2000, St Lucie Press (as cited in Wong et al)
• Wong, A., Scarbrough, H., Chau, P.Y.K., and Davidson, R., "Critical failure factors in ERP implementation".

IBS Australia develops ERP solutions, ERP Systems and business management supply chain software for inventory management systems, manufacturing ERP software, business intelligence systems and integration ERP software.

http://www.supplychainsecrets.com.au/gartner

http://www.ibs.net/au/solutions/erp-system.jsp

Article Source: http://EzineArticles.com/?expert=Peter_T_Clarke

Maximizing Your ROI Through Optimal ERP Performance - Key 3 - Selecting Your ERP Solution

By Peter T Clarke

Once you've made your decision as to why you are considering an ERP implementation (covered in article #1 in this series) and investigated the total cost of ownership (article #2), there are several aspects you should consider in detail when selecting a specific system for your situation.

The seven most important of these are Functional compatibility with current and future business requirements

• Total cost of ownership
• Operational Metrics
• Flexibility
• Time and ease of implementation
• Vendor support and relationships
• Industry expertise and customer references

A survey by the Aberdeen Group (June 2007) found when it asked respondents what criteria were most important in selecting an ERP vendor, "remarkably little variation was visible across company size ... functionality is the clear top priority for all companies, followed by total cost of ownership".

1. Functional compatibility The first question you need to ask is: what applications can accommodate your business needs? As Christina Soh and Siew Kien Sia point out (MIS Quarterly, 2005), vendors create enterprise systems based around a number of common structures - "ES packages are not custom-built for each implementing organisation". "Vendors must make many assumptions about organisational requirements in such areas as organisational policies, structures, standard operating procedures, user knowledge, and interfaces. These assumptions manifest themselves in the processes and features in the ES package", which the authors refer to as 'package-embedded structures'. "ES vendors claim that their package-embedded structures reflect best practice, However, many customers have found that these configuration options do not meet all their specific needs, and many question whether the 'best practices' truly do apply to all organisations. "Developers' context - that is, their reference organisations - may differ from potential implementers' contexts, particularly those located in different countries or industries. Even within the same country and industry, contextual differences can exist".

The system should be able to provide functionality for all of your current and future business processes. To ascertain that this is the case, you first need to define and prioritise your company's processes, identifying the core business functions and developing a comprehensive requirements list based on input from all stakeholders. This means that, as Soh et al recommend, "implementing organisations identify, as early as possible, misfits between the package and their organisation. They should create a basis for ascertaining when to align through organisational adaptation and when to align through package customisation". 'Misfits', missing critical features or unsupported business processes, could be the elements that transform an otherwise great fit into a complete mismatch. Very often, these only surface upon implementation. Buyers should be very wary of future promises from software vendors. If the system does not have the necessary functionality right now in the current release, then you should discount any claims of functionality being available in the future. The Aberdeen survey warns that, while functionality may be the top selection criterion, "ERP is often considered a commodity today. Don't assume the functionality you need is available. Take a 'show me' attitude in demonstration." One who has documented this 'road test' guide to assess the suitability of a specific solution is Esref Akpinar (2005), who describes a software selection process for a liner shipping company using fuzzy logic decision making. This entailed five scripted scenarios to understand how software packages would handle specific key operational situations. A demonstration evaluation document was prepared, with every question in the document given a weighting according to their importance. An evaluation table was prepared of the results of the demonstrations which clearly indicated which product best fitted the company's operations and requirements.

2. Total cost of ownership Prospective buyers should ensure they fully understand the true cost of ownership beyond the initial software licence fees and hardware cost. These may include costs such as those for integration, interfaces, systems communications , extra staff required, upgrades and helpline support. This topic is so important that it has been covered in great detail by the second article in this series, "Managing The Total Cost Of Ownership - What You Need To Know".

3. Operational Metrics It is imperative to ensure that not only the costs, but also the benefits of an ERP system are controlled and measured during the implementation project. The benefits generally come in the form of cost savings and operational improvements (e.g. lead time reduction). Cost savings should be built into budgets and operation measures progressively tracked.Legacy systems often do not support the operational metrics and these have to be assessed manually. A key selection criterion for the new system is thus also the ability to support these operational metrics.

4. Flexibility Can the application be modified and scaled according to the changing needs of a dynamic and growing business?Look for an ERP solution that will accommodate new operating protocols, future business growth, market expansion and any other initiatives that might arise.Things to consider when evaluating flexibility:

• System parameters and default settings;
• Customer screen and menu options;
• Tools for modifying standard forms;
• Data access options and custom reporting; and modular format.

5. Time and ease of implementation

Key questions you should ask regarding the implementation process itself include:

• How long will it take to implement the ERP system?
• Will it cause any major disruptions to your normal business operations?
• Is there an implementation control process (ICP) in place to manage this?
• What sort of business process re-engineering will be required in order to implement the system?
• How long will it take to train staff to use the system?

6. Vendor support and relationships Your software vendor decision is one that, hopefully, continues well beyond the normal, five-year decision cycle. To that end, three questions are important:

• Does the vendor have a sustainable presence backed up by experience in your industry and a proven track record on installations to similar sized organisations as your own?
• Will you and your management team have a comfortable working relationship that extends to their knowing you and your business intimately? Do they show a sense of responsibility and accountability for making your system choice a success?
• Do you have 'one throat to choke'? In the event that issues need to be resolved, do you have a direct executive contact who is accountable for making sure your customer service experience is consistently at the highest level?
• How many total vendors will you deal with on your ERP package? Sustaining multiple vendors is cumbersome.

7. Industry expertise and customer references Key questions that will determine the reliability of the vendor include:

• Does the vendor have a proven track record in your specific industry?
• Can the vendor point to a number of companies in your industry who are already using the software and who will confirm that they made a sound decision.

One issue that cuts across many of these selection criteria is the issue of customisation of the software, so it is worth briefly flagging the topic in this context. As Aberdeen Group points out (July 2007), only 11 per cent of respondents to one of its surveys got away with zero customisation. According to Soh et al, the simplest form of implementation - so-called 'vanilla' implementation - requires the organisation to bend to accommodate the software package. "Vanilla promotes organisational adaptation, either by conscious redesign and substantial change management, or by piecemeal, evolutionary workarounds, such as individuals and groups adapting. Their adapted practices lead to new organisational structures. Package software modification can range from customising the package code to interfacing with custom-developed modules or modules from other vendors." "Users tend to push for package modification to minimise the amount of change they will have to make. Consultants and project managers tend to advocate organisational adaptation, to simplify package implementation and avoid the tangible costs (time, resources and risks) of package modification." The playoff between these two apparently conflicting viewpoints can be a key ingredient to the success of the ERP project, particularly the total cost of ownership, and should therefore be a prime consideration among your selection criteria.

References:

• Akpinar, E., "Software selection for a liner shipping company using fuzzy logic decision making", paper submitted to the Institute for Graduate Studies in Science & Engineering, Systems and Control Engineering, Bogazici University, 2005
• IBS, "6 Essential considerations when selecting an ERP system", IBS Australia, February 2008
• Jutras, C., and Dalle Tezze, H., "When relacing ERP - Size matters", Aberdeen Group, June 2007
• Jutras, C., Trost, J., and Dalle Tezze, H., "Taking the ERP plunge for the first time", July 2007
• Soh, C., and Siew Kien Sia, "The challenges of implementing 'vanilla' versions of enterprise software", MIS Quarterly Executive, September 2005

Peter Clarke is the Chief Technology Officer, IBS Asia-Pacific. IBS develops ERP solutions and business management supply chain software for inventory management systems, manufacturing ERP software, business intelligence systems and integration ERP software. The IBS ERP system is fully integrated and includes collaborative sales, procurement, customer service, order management, demand-driven manufacturing, inventory management, business performance measurement and financial control.

http://supplychainsecrets.com.au/gartner
http://www.ibs.net/au/solutions/erp-software.jsp

Article Source: http://EzineArticles.com/?expert=Peter_T_Clarke