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

 

Implementing ERP more effectively – Part 3

Part 3: Having the right approach and attitude to an ERP implementation

(cross-posted from SYSPRO Smarter ERP blog)

“Change is not made without inconvenience, even from worse to better.” Samuel Johnson

Do you know how complex Microsoft Word and Excel are?

Because Word and Excel look so easy, people under-estimate how complex other standard systems, like an ERP, can be. If business users knew how complex those two Microsoft applications really are, they would be more thoughtful and careful when embarking on a complex software project.

Read more...
The statistics on ERP project failures are staggering. However you measure it, the figures don’t look good when it comes to software project success. There is a blog dedicated just to software project failures and a recent Harvard Business Review article highlighted the unexpected risks of major IT projects. Ironically ERP project failures keep occurring despite research that started more than 10 years ago on the critical success factors of ERP implementations, and which has been repeated several times since then.

While an ERP implementation is an IT project, it is also much more. Its main drivers and objectives are business-related, and it has a major impact is on people, processes and culture. Some important non-technical aspects of ERP projects were recognized early on:

“…large, complex projects, involving large groups of people and other resources, working together under considerable time pressure and facing many unforeseen developments.”

The way, therefore, to ensure that an ERP project is successful is not just to focus on IT issues but to have the right approach and attitudes. (Having the right people in the right place during the implementation is the topic of another blog series). The following are critical attitudes and approaches for a successful ERP project:

  • Top management support
  • Clear goals and objectives
  • Management of expectations
  • Change management, communication and user education
  • Project/program management

Let’s look at each of these briefly.

Top management support

While top management initiate an ERP project, giving it their blessing to start, the tendency to delegate the project once it is underway should be challenged. Top management needs to remain not only accountable but also responsible for the project. The question of who in the executive team should be the ERP guardian is debated on numerous projects. One commentator has a strong argument that the CEO is the only proper person to be custodian of the ERP system.

Clear goals and objectives

Too many software projects use the metric of ‘on-time, on-budget’ to measure project success, but as a recent ERP project failure showed, if you only use those metrics other important objectives can get omitted, such as customer or user satisfaction. At the outset of the project, before software selection is done, success should be truly and clearly defined. How do we know the stakeholders will be happy? What specific measurable benefits should the system deliver? Put another way – what does DONE look like?

Management of expectations

One reason why a senior executive should be in charge of the project is so that it is ‘owned’ by the business, rather than by the implementation consultants who often develop the project plan. The project’s scope, planned deliverables and schedule have a significant influence on setting expectations.

Deciding on deliverables and schedules without sufficient executive and staff buy-in can produce an environment where legitimate concerns are ignored and distrust is created. When determining the scope, focus only on what is ‘in scope’ (which only implies what is excluded), but also make explicit what is ‘out of scope’ – this aims to avoid those difficult conversations of “but I thought XX was going to be included.”

Change management, communication and user education

There’s a saying in change management:

“Old organization + New technology = Expensive old organization”

An ERP project can succeed or fail through the commitment of the people who use it. Therefore it makes sense to communicate with employees – early, often and in-depth.
I mentioned in a previous blog that one of the aspects of managing an ERP project is how to handle business process changes. A Forrester Research comment on change management was:

Forrester Change Management
source: Forrester Research

“Any business process change is strongly related to personal change — that means your people — and this is often the component that gets shortchanged.”

The change management and training programs should commence in the early stages of the ERP project, not, as is often the case, near Go Live date.

When it comes to training, there are some basic mistakes to avoid.

  • Training should not be considered a secondary, optional aspect of the project
  • Users need to be educated (taught the inner workings and reasons) as well as trained (how to complete a task)
  • Training should be planned for the long term
  • A variety of training methods need to be employed

Project and program management

ERP projects can be complex and long; organizations therefore need to invest in a project management capability. This means they need to understand the principles of project management relating to software projects, and be prepared for the challenges of managing a project.

Projects costs money. Don’t spend the money? Then, as Dr. Phil says, “how’s that work’in for ya?”

Finally, since an ERP project has long-term consequences, businesses need to develop a program mentality when it comes to their ERP application. This is to ensure that the system receives ongoing attention, oversight and support throughout its life cycle.

(Follow Glen Alleman and Michael Krigsman for ideas, evidence and pointers on how projects should be managed.)

Implementing ERP more effectively – Part 2

Part 2: Changing the system as business realities change

(cross-posted from SYSPRO Smarter ERP blog

Hands up all those who have started implementing an ERP system and not had to deal with changes as the project progresses. No one? I am not surprised. Has anyone gone live with an ERP project and never had any changes afterwards? The reality of any ERP project is that scope changes occur during the project, and after going live it is guaranteed that there will be more requirement changes.

In my previous blog, I discussed how integrated BPM (business process management) and ERP could provide a visual representation for designing and building an ERP, referring to my personal experience of having built a house. The second part of the story is about changing the plans when new ideas or new realities come up.
 
With my house we had extensive discussions with the architect during the design phase and we were confident that everything had been covered. But when we spoke to the builder he made additional suggestions and noticed some things that had not been considered. Using the blueprint drawings, we could decide on the changes needed, assess the effects on the building and the costs, and then make alterations to the drawing that everyone agreed with. It was a clear and understandable approach to taking on new ideas and changing plans even after everything had been agreed.
 
The same process happens in ERP implementations. Organizations often spend a good deal of time working on the design of the ERP application using skilled (and expensive) consultants to help them. This they believe will ensure they have got it right before the implementation starts. However, no matter how good the team, the fact is that issues can be over-looked, or valid change requests suddenly appear which had not been considered earlier.
 
In the past this was a problem because the ERP planning process assumed stability, and ERP systems were geared towards controlling data and automating processes. Flexibility and handling change were not priorities. Of course the world has changed and we now expect our software to be adaptable. For enterprise software, with its high level of inter-connected functionality and degree of complexity, this has been a challenge … until the advent of integrated BPM and ERP. With this integrated process toolset, new ideas and issues can be raised after planning is finished, and re-planning, review, approval and documentation can be managed more easily and clearly.

Integrated BPM-ERP

Integrated BPM-ERP

This concept of a model-driven ERP system is now possible using SYSPRO Process Modeling (SPM). Model-driven architecture has been around for 10 years, and is recognized as the most effective way to manage and optimize business processes, especially in a volatile environment. SPM helps in process management from high-level ‘Core Processes’, to actual ‘End-to-end’ processes, right down to activities and screens. For each level, this is integrated with the organizational structure, technology, data, and SYSPRO’s supported business processes.

This allows the organization to see how everything is inter-connected, and also to see how changing one element impacts on other areas of the model.

Hopefully the days of referring to ERP software as ‘monolithic’ are coming to an end. Changes to an ERP system should be expected and planned for because there are many aspects that can change. If you have been through more than one ERP implementation, particularly from the user perspective, what was your experience of making changes to the system? What would have made it easier?
 
In the next part of this blog series: Having the right approach and attitude to an ERP implementation.

Implementing ERP more effectively

Part 2 of a series on enterprise information systems

Building a house on a solid foundation

This blog has been cross-posted on the SYSPRO corporate blog.

You can hardly miss it these days: questions about why Enterprise Resource Planning (ERP) projects hit problems, or worse fail, are appearing on many websites. I have seen many ERP implementations and thought I had some answers, but it was only after I had been involved in building a house that I could see the similarities between building projects and ERP implementations, and why we don’t see buildings collapsing in the same ways some ERP projects fail.

Eric Kimberling’s Panorama Group identified this similarity at the same time I was building the house. The critical requirement for construction is the blueprint; the drawings of what the house will look like, what its parts will be and how it will be constructed.

The problem with projects, especially complex ones (like a house or an ERP project), is how to communicate the varied components, interactions, hierarchies and responsibilities to all parties concerned. You need a representation that will capture all these elements in a way that is clear and easy to understand, even if you are not a professional in the field. This will ensure that the various parties involved can achieve alignment in terms of common understanding of business needs and technology capabilities.

You also need a way for the plans to develop as your ideas and perspectives evolve. When you start planning a house you don’t go straight into the details. You may have some thoughts (even a vision), but you need guidance from an architect on what is possible, feasible and within budget. So you start with drawings that help you decide on the appearance of the house, then move into the technical and architectural details, and finally the construction and engineering specifications.

Until recently there was no easy way for ‘ERP novices’ to see the business in terms of how it would look after an ERP implementation. But now, with the integration of business process modeling (BPM) and ERP, those visual representations (the drawings) can be done. For an ERP implementation, the functional requirements and business processes are like the rooms and materials of a house, and a business process model is the equivalent of an architect’s drawings. The Business Process Modeling tool can be used in the same way that you start a house with some initial sketches. It allows you to view the business from a high level to make sure executives agree with the ‘look’ before going into more detail.

This graphical way of representing an ERP project can replace the mountains of design documents that were the staple of past ERP projects. This pile of paper used to be the main documentation a business had to describe its strategy, plans and processes. The sad fact was that only a few people ever probably read them, and even fewer understood them.

It’s about time that “the big freakin’ requirements document must die”. What is needed is one tool which can capture scope at different levels in one place, which provides traceability between business requirements and IT capabilities, and which uses better means of communication to illustrate than the common legal-style text of many project documents.

If you are an ERP implementer, how did you experience communicating via traditional project management tools? If you’ve experienced an ERP project as a business user in the past, what did you think of the project documents that you had to use?

At SYSPRO, we now provide a tool that can replace the big project document, which is graphical and shows how integrated BPM and ERP functions: SYSPRO Process Modeling (SPM). Analyst Brian Sommer described the combination as “A Key Mid-Market Need”. With SPM we believe that our customers will get more value, and have a far lower risk of problems in their ERP implementation projects.

In the next part of this series: changing the system as business realities change.