Review of the Gartner ERP Magic Quadrant

magic-quadrantIt’s been six years since I posted my views on the Gartner ERP magic quadrant for Tier 2 vendors. It has been one of the most viewed posts on my blog, but I think it’s now time to have a relook at the ERP magic quadrant (MQ) and the ERP market as a whole. Continue reading

Advertisements

Why monolithic systems of record will disappear

cloud-computingI thought that having left the ERP industry I would not have any reason or inspiration to write about it, but I was wrong. My experiences since I started working in the cloud application market have led me to believe that the era of the monolithic systems of record, as typified by ERP, might be coming to an end. Continue reading

Should ERP vendors enter adjacencies?

strategyThere is a tendency these days to advise that people and companies ‘focus’, and not try to do too much. Should companies stay with one set of products, or broaden out into other related areas or ‘adjacencies’?

Recently an analyst I follow on Twitter commented that SAP has spend $50billion over the years to acquire innovative products the company could not build. I can’t remember whether it was Vinnie Mirchandani or Ray Wang, but there is a Wikipedia link that shows the SAP acquisition list. The money for those acquisitions came from the annual license fees that SAP customers pay, an issue that Vinnie has said before is a concern to customers, for example here.

SAP is not alone, Oracle has also spent billions on acquisitions over the last 10 years to broaden its footprint from a database and finance applications player, to one that has its own complete technology stack.

In an era when ‘focus’ is often evoked, the question is how do executives of a company identify opportunities and prioritise goals when they move from specialising in one area of technology to a huge range of technology products? An article in 2014 raised the issue of the dangers of adjacencies. When growth begins to decline, the reaction is for companies to enter other related areas of business, and this seems to have become almost an addiction. When it comes to SAP and Oracle, their acquisitions appear to be driven by a need to continue an aggressive growth strategy.

The basis of the article is that adjacency moves distract the company leaders from finding new ways to grow the business they are already in, and so the core business grows slower. This reduces the focus on the core area, what makes this area unique and valuable, and the business loses the advantages it used to have. Again, SAP’s core ERP area has not recorded strong growth in recent years.

Interestingly, the writer of the 2014 article published another one in 2015 that discussed how diversification into adjacencies could work. What needs to be done to succeed is to:

think about focus in terms of how much your businesses materially benefit from the distinctive capabilities that make your company better than any other at its way of creating value.

According to the new hypothesis, you don’t diversify just to enter more attractive growth markets, you do it for these two reasons.

To use your company’s way of creating value and its distinctive capabilities to generate new avenues for profitable growth.

To strengthen your company’s current business, by enhancing either its capabilities or its value proposition.

The adjacency strategy for a business therefore is not to diversify away from your base, but to diversify for your base.

Looking at SAP, Oracle, and also IBM, the question seems to be, what did they diversify for?

Twenty questions for CFOs embarking on an ERP project

cfo-questionsAs the CFO of an organization, your responsibility is to ensure efficient and effective financial operations and records, and influence overall strategy. An ERP is the foundation of the operations of a business. For a CFO, it enables you to track and report on all business transactions, analyse information, ensure governance and compliance, and increasingly do this via mobile devices. Therefore, you need to be very sure your ERP project will deliver what the business requires, and also what was promised.

Before going ahead with an ERP project, you should have addressed these questions.

Planning and selection

  1. What is the executive board’s experience with business software? Will there be sufficient executive involvement beforehand, and how will it be maintained during the project and afterwards?
  2. Are the business objectives clear, and is there detailed understanding of what you want to achieve? Do you just want a new system, or do you want to change the business – its processes, what roles people perform?
  3. How will you engage with vendors? Will you short-list with the use of an extensive RFP (Request for Proposal) sent to lots of vendors; use recommendations and peer contacts to identify a smaller number of vendors; do your own research on the Internet to identify possible vendors; employ the services of an external consultant?
  4. How will the chosen solution impact the way you do business – what aspects will it dictate to you, and what can you change to suit your needs?
  5. What benefits do you expect, and where will you look to find:
    1. Increased revenue
    2. Decreased costs
    3. Improved quality
    4. Better customer service
    5. Shortened manufacturing cycle time
    6. More accurate inventory information
    7. More streamlined processes
  6. Have you got details of all the costs involved?
    1. For the obvious items – software, infrastructure, services, training, support
    2. For less obvious ones – budget for data conversion/take on, third party software integration, change management, process modelling.
  7. How will you ensure that the consultants engaged for implementation can be treated as:
    1. trusted advisors
    2. knowledgeable and experienced in your industry issues
  8. What are the cost, time and effort implications of upgrading the ERP software?

 Implementation and training

  1. Is the project scope clearly defined? How will you handle the scope changes that so often happen during an ERP project?
  2.  Are the right internal people involved? What might their agendas be?
  3. How will training take place? If the staff needs proper training, how will it be scheduled to minimize the effect on their day-to-day work, bearing in mind they will also need the time and opportunities to practice and learn the new skills.
  4. How will the project impact both the intended users and the current IT team? How will they manage time on work vs. on the project?
  5. How will the ERP software work with other applications that the business relies on?
  6. How easy is it to access information via reports, or other sources?
  7. What procedures need to be implemented to safeguard governance, regulatory reporting and compliance?

Ongoing use, management and maintenance

  1. What ongoing training and education programs need to be instituted so that staff continue to use the system effectively?
  2.  What strategies are required so that the ERP system encourages the standardization and classification of information across the business
  3. How will you extend the ERP system from just a transactional system to one that assists with planning, analysis and insight?
  4. What people and policies will you put in place to maintain the Return on Investment of the ERP system?
  5. How often will you review the alignment of the ERP with the business?

This was originally published on the SYSPRO Smarter ERP blog

 

Four tips for starting an ERP project

Cross-posted from SYSPRO SmarterERP blog

There has been a post on the SYSPRO blog on how an ERP system can help a business, and also some suggestions on how to select an ERP solution. But if you have read some of the stories about ERP project problems you might wonder if it is worth the risk. The answer to this is twofold.

  1. The reports on ERP project failure mainly refer to large organizations implementing fairly large projects, and are not representative of projects undertaken by small- and mid-size businesses.
  2. It’s how you approach the implementation that is a significant determinant of success or failure.

So where and how do you start?

The lead up to an ERP project is a good time to consider Eli Goldratt’s Theory of Constraints Thinking Processes, which is a set of tools to help organizations identify what can be done to significantly improve any business system. By the time you start the project you should have dealt with the question “Why change?” Now you need to look at the other questions:

  • What to change?
  • What to change into?
  • How to cause the change?

A number of organizations might think that all they need to change is their business system, when in reality they will probably also change and streamline processes, and realign roles and responsibilities. Therefore I recommend the following steps.

1. Do a business process blueprint.

To answer those “what” questions you need to understand the processes that operate in the business. A process blueprint provides a graphical view of the way processes work, who is responsible for the processes, and the interaction between different roles.  It also helps by creating a view of the business that both IT and business can understand and discuss – a common, visually-based language. From the blueprint you can see more clearly what might need to change (e.g., in terms of streamlining processes), and with a decent blueprint tool you can try out different changes to see what might be most appropriate. The blueprint enables you to identify solution gaps and define integration points between IT solutions.

2. Check that the key project issues are covered

Evidence from many projects shows that there are four main factors that create project problems, and so mitigating them will improve the chances of project success.

Main causes of project problems How to mitigate them
Unclear objectives and poor focus Focus on strategy, involve stakeholders and define project teams responsibilities and accountability
Changes in project scope Ensure project team and all affected staff are aligned to work towards common project goals
Lack of appropriate skills Ensure appropriate skills are available
Unrealistic schedules and poor planning Have a good project manager

3. Plan the project in phases

The implementation project plan describes how the transition from current state to envisaged future state will occur – it addresses “how to cause the change?” Plan the project in phases and implement over time, for several reasons.

  • It’s easier to estimate and manage the budget for a smaller set of tasks than it would be for a ‘big bang’ type of approach
  • It restricts the impact of the change to a smaller number of people, which means disruptions to everyday work can be minimized
  • Showing rolled-out wins will keep people motivated

4. Make sure change management is included
Forrester-change management
The biggest cause of failure in IT projects is not software, it’s ‘wet-ware’ (people). Resistance to change can block even the most perfect plans, so building active consensus and buy-in is crucial. Forrester Research offers the following steps.

Lastly, although you may have undertaken a thorough business process analysis, and done the proper project planning, be prepared for unexpected complications that occur during roll-out. This is especially true for manufacturing businesses with complex processes, and where integration with other manufacturing applications is needed. If, however, you have done the upfront work, you will be in a position to handle these complexities without seriously impacting the project or the business.

What is your experience with starting an ERP project? Have you got any other tips to add?

SYSPRO’s cloud strategy and journey

This is an interview that Dennis Howlett of Diginomica did with me about SYSPRO‘s approach and implementation of a cloud solution for its ERP software.

The accompanying article can found here.

Selecting an ERP solution

This is a cross-post from the SYSPRO SmarterERP blog

Whether you call them RFIs, RFPs, RFQs* or some other acronym, and whether you are a vendor or a customer, those three letters conjure up the same impression in many minds – pages and pages of detailed questions about a software product’s functionality, which takes weeks to create, days to respond, and weeks again to review. Continue reading