Small vs. Large: a different approach to your ERP system implementation project

Author Ugne Kontare

There is no doubt that there are differences in business processes and management between small and large companies. Small companies are usually multi-taskers, faster in reacting to change, flexible in their daily operations and low on bureaucracy. Meanwhile, large companies usually need more routines in order to manage their business efficiently; the areas of responsibility among departments are divided clearly, and it takes more time to pass information from one management level to another.

The size and maturity of a company bring differences when implementing an enterprise resource planning (ERP) software system. Let’s overview the main areas you should pay attention to during the implementation of your next ERP software system, as well as the differences between small versus large implementations that you should understand and use in your favor in order to have a successful project.

1. Experience

For smaller companies, it might be the first or second time they have implemented a business management system. Therefore, in order to have a successful project they either need to educate themselves really fast on what matters when implementing an ERP system, or hire a professional ERP supplier and trust their professionalism. In our experience, it does not matter how much information on ERP implementation you get, the result will still be different than you expect, unless you have clear goals as to what you want to achieve by implementing a new software system. Then bring them up clearly with your supplier and check whether they have been respected during the system go-live, and also several months after the system has been implemented (because then you will start getting the results you expect). This also applies to large companies.

Even if this is not the first time a large company has implemented an ERP system, experienced internal employees are needed; otherwise everybody needs to learn, just like in a small company. From that perspective, it is easier in larger companies when the processes are already set and implemented in the software system, and there is more confidence in what does not work and what adjustments are necessary.

2. Management and coordination

The good thing about implementation in smaller companies is that all decision-makers and influencers are in one place and in most cases highly interested in the success of the project; therefore it is easier to communicate and bring up various issues during implementation. On the other hand, in large companies the need for a new ERP system is often brought up by one particular department, e.g. accounting; managers from other departments and top management are not always fully involved in the implementation project. The assigned project manager – most often from C-level management – sometimes has no authority to lead other people in the company. In addition, the coordination of issues between various departments takes longer.

In the ideal scenario, either top management should assign the project manager with full power to make decisions and involve the people necessary for the project, or top management itself should be involved in project-management activities at least on a weekly basis.

What we like about large implementations is that there is at least one dedicated person, and sometimes an entire team, working full-time on the project, which means more time is spent on various issues and finding solutions faster. Meanwhile in smaller organizations the ERP implementation has to be managed along with other duties.

3. Implementation methodology

In large projects, the implementation always goes (or at least, should go) according to some proven methodology. Microsoft Dynamics partners have Sure Step, SAP has ASAP; I am sure that other software providers have their own methodology that still usually looks very similar: it starts with diagnostics/analysis, moves through software development to deployment and operation with supporting actions in each phase.

In small projects, some phases are the same, but just take less time, while some are merged – e.g. diagnostics and analysis of the business processes within a company might take up to a week and can be done remotely; they can be completed in the form of an interview, the customers not knowing that they are in the analysis phase. That is a very short time compared to months spent on analysis in large companies, where business processes are more complex and there are more functional user groups to be interviewed in order to see fits and gaps in the software system according to the company’s business processes.

Actually, now, in the era of cloud solutions, a new approach to software implementation has been born: companies take and use the standard software solution as it is. This is typical with start-up companies, as most of them do not have documented processes. Many operations are still being tested, and it would therefore be very difficult to try aligning the system according to processes that either does not exist or are changing frequently.

Still, it’s a tricky topic. From our experience, companies get their competitive advantage from their unique way of doing business. Can ERP systems therefore be standardized to the “one-fits-all” model that is the essence of cloud solutions? I am not sure. We will discuss this in our next blog.

4. Documentation

Documentation is an important part of each project. During large ERP projects, so much time is invested in creating and reviewing the Functional Requirements Document, Solution Blueprint and other documents. The requirements document should be expanded and used throughout the implementation process. The question remains – is its form effective, as in many cases during implementation some things change, some features appear to be not needed, and finally no one compares the real system to the documented one, or if they do, there are so many indeterminacies on how one or another system part should work… This can lead to never-ending discussions and development. But surely the main goal is to make it work? And the less experienced the project team is, the more deviations from the original document version we have in real life. This is true for both large and small companies. Of course, it would be nice if the requirements document were living, constantly changing, improved and updated responding to the existing situation, but from our experience there are not many cases where this is so.

The latest practice is to avoid complicated documentation in smaller projects, but I believe this could also be applied well in large projects: instead of creating a hundred-page implementation guide, create a 15-page Project Charter document instead, setting out the listed standard functionality, scope of development (well, the system can be developed infinitely – is that really needed? But for future record, gaps should be identified and documented, as well as the ways to solve them), and the timelines and budget for the project. Once everything is within scope, the main target is to launch the software system so your (customer’s) team could work with it and start getting benefits – after all, that’s what you were looking for overall when you started the project, wasn’t it?

Another topic is user guides or manuals. They are necessary, no argument about that, but instead of having a standard manual, you as a customer could adjust it to your own processes during the training period.  The document will then be more useful for you and your new employees, as it will provide guidelines on how to manage your business with the software, instead of providing some standard way the software works. This is especially true with complex systems such as Soft4Leasing – the full manual could consist of 500 pages or more, as we could describe not only the financial products leasing companies work with, but also financial programs for each of them, thus including hundreds of scenarios in the manual – this being just a small part of the system.

Therefore it is much more effective when a company takes a standard process in the system and configures it according to their own needs.

Another documentation method some of our customers use is to create a 1-2 page functional description for each role in the company that works with the software. This approach makes employees fast and comfortable in finding information they need for their daily work, instead of having to search through hundreds of pages.

5. Time

Time has always been important, but it’s even more so now that the pace of life has accelerated. And not only because of the pace itself, but also because companies started evaluating the impact on their business when they did not have the right software in place: unearned income, unserved markets and so on.

Implementation time often depends on more than the size of the company – in many cases we saw delays even in smaller projects when the project was led by an inexperienced or incompetent team. Sometimes it takes as long to implement the system in 2-user companies as in 20-user companies because of their business complexity. Even so, a period of 12 or 18 months for large implementations still looks quite normal in the ERP world. The time required also depends on the software system; whether it’s a front-office system like CRM or document management, or back-office, like ERP, Supply Chain Management or other similar software.

Typically, the length of the implementation is directly related to project costs, therefore  suppliers nowadays aim to shorten the implementation period by as much as possible, standardizing implementation procedures and documentation. For this reason, such complex software systems as Soft4Leasing can now be implemented in less than 3 months in smaller leasing companies. And cloud solutions, such as Soft4RealEstate, can be set-up in just 8 hours! 5 years ago that would have been hard to believe!

6. Budget

Money money money… Always as important as it was in the ABBA song. The budgets for ERP implementations have been shrinking for several years (depending on the region, e.g. in developing African countries the budgets are now at the same level as they used to be in Europe ten or fifteen years ago). With cloud solutions, the price level gives way to volume – more implementations at a lower price level are better valued by investors, therefore by software companies as well.

It is very useful if the software you choose can be sold “in pieces” – in modules, per user, per lease unit you manage, per number of contracts you have, etc. In this way, you as a customer can control your budgets in unexpected business situations – cloud pricing gives extremely high flexibility, as you can add and remove numbers of users (in the case of Microsoft Dynamics NAV) or change pricing level at any time.

The implementation budget can be clearly defined and thus controlled as well. From our experience, it is worthwhile going with the software if the standard functionality meets about 70 – 80% of your company’s needs. Then, after launching the standard system, the development scope should be defined, having in mind the budget you want to spend and the functionality/adjustments you really need for your business at the time. Things that are just ‘nice to have’ might have to wait – in most cases 6 months later you won’t even remember you needed them … Congratulations on saving part of your budget and investing it in what really creates value for your business!

This is especially important for large implementations that tend to slip into never-ending development tasks, which is why their system go-live is always delayed. One should always consider whether it is worth going with 80% of ready functionality immediately, or delay starting to get benefits and wait several months to complete the system 100%.

7. Pains and gains

We have a joke that the biggest enemy in the ERP world is not “not selling”; it is a decision “to do nothing”. When the business pain is not severe enough, or companies do not see clear benefits coming out of the implementation, they tend to procrastinate (especially when changing the back-office, ERP system). Still, it is hard for large companies to keep procrastinating once they can no longer develop business due to outdated or non-functional software systems, while still incurring on-going costs.

Smaller companies can survive longer using Excel spreadsheets or several software pieces until they come to the decision that some more complex software system is needed. Of course, there are always some bright minds in the SMB sector as well who see the real value of using modern technologies, but they usually have some previous experience with software implementation and clear targets as to what they want to achieve when spending their money.

Summarizing, both small and large implementations can be successful. Large ones need more discipline and coordination, while for smaller companies success might be achieved by being flexible and improvising in some stages. We think that trusting your software provider, who has completed hundreds of implementations, could be another key to success. Just as every surgeon is interested in successful surgery, each software supplier should be interested in the success of your business and project. At least the SOFT4 team is, because the best marketing tool in our industry is still word-of-mouth.