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.

Frankly, no one likes these documents, but businesses evaluating ERP software keep producing them, and vendors keep responding. Isn’t there a better, more efficient, ‘leaner’ way? According to one view:

Regardless of how many consultants a client uses to select software, many would have been far better selecting out of a hat.

The people who see value in ERP selection documents are the consultants whose job it is to create those documents. I know of cases where the client didn’t really understand the reason and the purpose of several questions. I have also been on a project where literally hundreds of selection questions were used, but once the implementation started those questions – and the answers – were effectively forgotten.

The now undeniable truth is that the selection of software plays little part in the final success or failure of an ERP project. What makes the difference during selection is addressing the real questions.

• Has the organization identified the major business challenges that they want the ERP system to address, as well as the key business drivers the ERP system must support?
• Are the business processes which operate in the business clearly understood and defined, and how should the ERP software assist or improve those processes?
• Have executives clearly communicated the reason for, and objectives of, the ERP project to the rest of the enterprise, and more importantly, have they taken the time to get buy-in from the staff?

If those questions can be answered, here is an alternative process for selecting an ERP system:

1. Check with other organizations, or industry groups, what ERP software deployment they know of, and their experiences around it.
2. Do some of your own research. These days a bit of time using a search engine, and looking for some relevant blogs can give you a reasonable idea of issues in the ERP world.
3. How do the vendors you have now identified articulate the direction and focus of future functionality in their product roadmaps, and is that consistent with your organization’s goals and plans?
4. How are the vendors represented in your area? Do they have a local presence for training and support? What is the quality and quantity of skilled resources the vendor or reseller have available in your area?
5. From the list you have now created, invite the vendors or their resellers to present to you. Provide them with some key requirements you need in an ERP and ask them to do a live demonstration or proof of concept using their software. Do they show an understanding of your business and its key issues? Can they show proven functionality in areas that concern you specifically? Lastly, what will it all cost?

The result of this process will be a few vendors with proven understanding and experience, who can then be engaged in more detailed negotiations. You might also ask these vendors to summarize in writing how their proposals address your key requirements. The vendors who understand the business issues should not only do a good summary but may also give you additional ideas you hadn’t thought of.

The key point is – don’t sweat the small stuff; avoid getting into too much detail on small issues of functionality. Focus on the important issues of the business and how the ERP software will allow you to improve them. No ERP system will address every single requirement perfectly, so make sure the ‘must have’ requirements are met.

Let me know if you have other ideas for selecting an ERP solution.

* RF = Request For. I = Information. P = Proposal. Q = Quote

My previous blog archived here

I started blogging on a South Africa site in 2005, but moved here to WordPress after about a year. That South African site is going to be terminated soon so I decided to copy over a number of my blogs to a page on this blog – see the Archive page.

It was interesting for me to see some of the observations I made back then – some of them were quite presceient, others actually came true or show things haven’t changed at all.

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.

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:

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

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.

Where is Dynamics in Microsoft?

It has been some years since Microsoft changed its financial reporting structure so that their ERP and CRM business, Microsoft Dynamics, was included in a larger division rather than reporting separately. Dynamics is now part of the Business Division, which also includes the ‘mega-earner’ Office applications.

How Dynamics contributes to the overall Microsoft business came to mind this week when I read a report by Mary-Jo Foley on the SharePoint product. In 2009, SharePoint earned Microsoft over $1.3 billion, and according to Foley usage of the software is growing at a phenomenal rate. Another source noted that, for the same year, Dynamics revenue was $1.25 billion. However the earnings for the Dynamics business in the latest annual report (2010) were reported as being flat. Bear in mind that Microsoft total revenue for 2010 was $62 billion – so Dynamics is less than 3 percent of the business. Perhaps some good news is that in the first quarter of 2011, the Dynamics business grew 4 percent.

Back when I sold Dynamics software, I reported on a talk by a senior Dynamics executive about what it was like running the then ‘Microsoft Business Solutions’ (MBS).

It was interesting to hear how difficult and long he found it turning MBS into a division that could work properly. He also gave some insights into how Microsoft builds its business – aims for platforms rather than products…

If the strategy for building platforms still holds true, then SharePoint is succeeding. It is becoming a de facto standard in many businesses for content and document management, and collaboration. The part of Dynamics that is doing well is CRM, however the ERP part has not established itself as a platform in the same way.

With other products doing so well – “Kinect sensors selling at a rate of about 130,000 units a day, selling 657,534 Windows 7 copies per day … a copy of Office 2010 sold every second” according to Foley – and a strong focus on the new Windows Phone 7 mobile operating system, how important will the Dynamics business continue to be for Microsoft?

Some time ago, I wrote that Microsoft is becoming like the old IBM:

IBM was good in some areas and terrible in others, but still continued in the terrible areas, so too is Microsoft.

I am aware that the performance, growth and market share of the Dynamics ERP products vary geographically, but one does have to ask what role Microsoft’s executives see for Dynamics. If they want to spend a lot of resources to grow in the consumer and mobile sectors, how much will they have left over for Dynamics? Their competitors in the ERP space – SAP, Oracle, Epicor, Infor, and yes, SYSPRO – are able to focus all their efforts and talents on enterprise software issues.

I wonder, is Microsoft just too proud to admit they made a mistake and that ERP software is not really their field of expertise? Could the analysis be true that:

Microsoft will continue to increase its CRM software revenues by increasing its share in the ever increasing CRM market. We also expect it to more than offset any revenue loss experienced from ERP software sales.

Microsoft wins on the swings as well as the roundabouts

The saying “swings and roundabouts” is a British one that describes a situation where you can win and lose. I am using it here to point out that Microsoft’s combination of business divisions may be giving it advantages on both the traditional (Windows, server) as well as the Dynamics (ERP) sides.

What kicked off this train of thought was an article by Josh Greenbaum: The Realignment of the Enterprise Software Market: Oracle vs. Everyone, Microsoft in Ascendance, and Watch out for Infor. The article notes that Microsoft’s Dynamics division

… the former bastard stepchild of the Microsoft portfolio, is now becoming the poster child of innovation in Redmond. And Redmond is taking notice big time[.]

Dynamics is one of the smallest divisions in Microsoft, and I have discussed its problems in the past here, here and here, but the company now seems to have discovered a major advantage.

Dynamics is a great driver of product pull-through. Today, every dollar of Dynamics generates from $3 to $9 in additional software sales for Microsoft.

Note: the article mentions other points but my focus is the first one.

I know from a Microsoft partner perspective that product pull-through is one of those phrases that brings a sparkle to the eyes of Microsoft’s partner managers.

Does this mean that Microsoft is discovering the value of a wide eco-system? Greenbaum makes an interesting comment about Microsoft, in comparison to Oracle:

This places Microsoft front and center in a battlefield where it is deploying 21st century technology against an Oracle that fighting the battle as though this were still the 20th century.

Microsoft’s strategy seems to provide a whole range of “interchangeable, plug and play” components. In my opinion this is far better than the Oracle strategy which wants to control the full stack – from hardware, to database, application, and middleware.

I have thought for some time that the Oracle strategy of vertical integration is an anachronism since so many other industries have abandoned the practice. In effect, it is a throwback to a bygone era when IBM ruled the computer world in the 1970s.

I also wonder how customers would feel about putting all their computer ‘eggs’ in the Oracle ‘basket’? There is an advantage to having a single, strategic supplier, and a single ‘throat-to-choke’, but a small customer has very little bargaining power with such a large supplier.

new Gartner mid-market ERP magic quadrant

At the end of December 2010, Gartner published the updated version of the “Magic Quadrant for ERP for Product-Centric Midmarket Companies“, aka the mid-market ERP vendors.

Interesting for me is how Gartner has positioned the ERP mega-vendors – SAP, Oracle, Microsoft – compared to the other vendors.

2010 ERP predictions reviewed

Following from my previous post of Panorama’s 2011 ERP predictions, I was pointed to their 2010 predictions, which were:

1. Diligent focus on ERP software benefits realization and ROI.
2. SMBs to get back into the ERP software market.
3. Increased adoption of Software as a Service (SaaS) at SMBs.
4. Lots of ERP SaaS talk, but not as much action at large organizations.
5. Increasing focus on organizational change management and ERP benefits realization.
6. With ERP software, it’s still a buyers’ market.
7. Enterprise software risk management.
8. ERP software vendor consolidation.
9. Focus on integration rather than major ERP package enhancements.
10. Niches, low-hanging fruit, and business value.

Which one’s would you vote as being the most accurate?

Your 2011 ERP predictions

Eric Kimberling of Panorama published their top 10 ERP predictions for 2011.

1. Risk management and mitigation.
2. Increasing focus on organizational change management.
3. Increasing need for ERP business cases, ROI analysis, and benefits realization. 
4. ERP lawsuits and canceled ERP projects.
5. ERP vendors will get their “mojo” back. 
6. ERP vendor consolidation.
7. Heavy adoption of Software as a Service (SaaS) models at small and mid-size businesses (SMBs).
8. Continued buzz around cloud computing. 
9. A good year for CRM software.
10. More focus on diagnostics, analytics, and business intelligence.

But predictions can be subjective, so I would be interested to know how you would rank them.