Custom versus Boxed Enterprise Resource Planning (ERP)
ERP system is probably the most massive piece of software a company can implement. It is a hub that ties all the other administrative applications together and allows different departments to quickly and reliably exchange information. So it is no wonder that finding the right one and successfully implementing it is a complex issue. We attempt to make it easier for you with this article.
What are the principal differences between a boxed and a custom solution, how are they implemented, and when should you go for either — read on to find out. Let’s begin with the definitions, so we are on the same page.
What Is ERP
ERP system is defined as software that is used to collect, store, manage, and interpret data from many business activities. Its goals are to automate and speed up business processes, digitize documents, improve the exchange of information between departments, and increase overall productivity.
An ERP is usually a set of modules that handle specific functions.
Modules
Here are some typical modules that an ERP can include:
- Finance & Accounting. A module that calculates revenue, net income, expenses, payroll, etc.
- Customer Relations Management. Following a contact’s journey from a prospect to a partner.
- Inventory/Supply Chain Management. Tracking stock at the warehouses, procurement, shipment, etc.
- HR Management. Monitoring workload, turnover, performance, and other aspects.
- Manufacturing. Planning production, raw material expenditure, forecasting and comparison with the actual results, and more.
- Business Intelligence. Automatically analyzing raw data (production volume, revenue, sales volume, employee turnover, etc.) and turning it into valuable business insights.
There could be many more, specific to each industry. E.g. Oil & Gas ERP could include pipeline management, a chemical lab for monitoring the composition of the oil, and other relevant modules.
Types of ERPs
We can broadly separate the ERPs into two categories: off-the-shelf and custom.
The first type includes systems that are packaged as a product and sold to many different companies. Popular examples of these are SAP, Oracle, and Axapta. They are typically distributed on a subscription basis — customers regularly pay licensing fees for them. Boxed ERPs include presetsfor specific industries (Retail, Oil & Gas, Logistics, etc.) to cover the most widespread business processes in these domains. They still need to be customized during the implementation because no two businesses work the same way.
The second type covers the ERPs that are built to the specifications of the customer that ordered them. This software is owned by the customer and thus require no licensing payments. Such ERPs can be changed and modified whenever the customer wants — this is the whole point.
Side-by-Side Comparison
To fully understand the benefits and drawbacks of each kind, let’s go through each step in the creation and/or implementation of them.
Step 1. Business analysis/Preparation
Off-the-shelf
With a boxed system, the work starts with gathering information on how your company operates. It is necessary to put together the set of modules that would be needed for the most efficiency. After all, if a company doesn’t manufacture anything, having a production management module would be wasteful.
This information is compiled into documents that would serve as a roadmap for the implementation.
This is also the stage to bring all the stakeholders on board and ensure their opinion is heard. Otherwise, you risk missing important points and hampering your optimization efforts. The typical group of people responsible for ERP adoption consists of a C-level executive and a representative from each department of the company who would provide an end-user viewpoint and later serve as a super-user.
On the vendor’s side, the team would consist of an account manager, project manager (or several, depending on the scope), a business analyst, one tech lead per each module, a deployment manager, and a group of teachers that will provide knowledge transfer to the employees.
The risks at this stage are the following:
- Lack of stakeholder support. If the key people resist the ERP it could cause the failure of the project.
- Lack of a realistic objective. How can you judge whether the implementation was a success if you don’t know what success is? The same goes for an unrealistic objective, it would only lead to disappointment and waste of resources.
- Lack of planning. Having milestones and intermediate objectives help to locate bottlenecks before they lead to going over the allocated time and budget.
Custom
With a turnkey system, the information gathering process is similar. The goal is to analyze the customer’s business processes, locate areas of improvement, conduct competitor analysis, and suggest the appropriate solutions. The gathered information would then be turned into a set of requirements documents — guidelines for the development process. This document would also allow you to shop for alternatives — you can have other companies estimate the work if the current one wouldn’t be a fit for you.
This is also the stage to agree on the cooperation model: fixed price, time & material, or dedicated team.
The customer’s team, in this case, will include several line managers and a C-suite executive (in the beginning, to sign-off on the project, and possibly later if the issue can’t be solved by the lower ranks).
The vendor’s team will be comprised of a project manager (or several), a business analyst, an account manager, and a technical lead, not to mention the developers working on the system.
The leading risk here is skipping the needs of certain stakeholders, which will result in a system that lacks the necessary functionality. However, it is relatively simple to address down the line, especially under a time&material model.
Step 2. Estimation, Roadmap
In both cases, this stage largely depends on the quantity and quality of the information that was provided in the first step.
Off-the-shelf
The process descriptions and the requirements for the implementation are finalized. Which means the vendor can give a more-or-less reliable quote on the price and timeline. If the first step was thorough enough, the information would be sufficient for a down-to-earth estimate. However, there is always a possibility of something unexpected happening.
This step results in creating a quote, a roadmap (with all the stages, including training), and other relevant documentation, like a communication plan.
The main risk here is underestimating the task and going over the budget later.
The second risk is overpaying. There are cases where a company had to get a license for an entire extra module even though they just needed a single report from it.
Custom
With turnkey software, this stage begins with prioritizing features for the Minimum Viable Product (MVP). This approach is popular among startups and is useful for custom software development as well.
As the name suggests, MVP is a version of the software that has the most important features — without them, it wouldn’t be useful. This is why you should go for it too:
- Risk mitigation. There is always a chance that the software won’t work for you. It is better to find out while you’ve only invested money in the few critical features rather than the entire application with all the bells and whistles.
- Earlier payoff. Launching a custom ERP with the most important functions would allow you to start reaping its benefits earlier. You can always add more later.
- Quick feedback. Even with the most thorough testing, you won’t know whether an application would solve your problems until you start actually using it. Implementing an MVP version would allow you to get actual feedback faster.
Once the features are prioritized and the crucial ones are selected, the vendor forecasts how much time and money it would take to develop them. Note that the quote would partially depend on the cooperation model. Fixed Price contracts typically have 15% or more extra time and money included as a precaution in case the work takes more than expected. Time&Material, on the other hand, doesn’t, as such work is billed based on the actual time worked.
The risk here is once again underestimating the tasks. It can be mitigated by using an Agile development methodology — working in 2-3 week cycles and flexibly managing the team’s workload.
Step 3. Design and Development
This stage takes the most time in custom systems. But it is also present in boxed ones.
Off-the-shelf
One of the benefits of the boxed systems is that most features are already in place. As we’ve mentioned earlier, there are even premade settings for specific domains. Still, no two companies have the exact same business processes. This is why the customers have two options: change the processes to fit the ERP or have the vendor customize the system for them. This work can include something as simple as company branding, or as complex as wholly new modules.
The system is also tested to ensure it is configured correctly and can handle the load. Finally, this is the part where the training begins. If you have an in-house IT team, the vendor’s representatives will teach them how to manage the ERP in the future.
The first risk here is having too many unusual processes that would require too much customization. The exact costs would depend on the scope and the vendor’s rates, and it might add up so much that you’d be better off with a custom ERP. If little to no customization is needed, a boxed system will allow you to get to the implementation stage faster and cheaper.
Custom
As with other large-scale systems, the best option is one of the Agile development methodologies. The team will work in 2-3 week iterations called “sprints,” and each sprint will result in a completed feature or set of them. This is the way to give the customer working software earlier and help them reliably track the progress that the team makes. The actual time and costs of design and development depend on the scope of the project. In our experience, creating and implementing an MVP version of such a system takes about 6 months.
The knowledge transfer between the developer and your internal team would also occur at this stage. This can be anything from providing detailed manuals to actual training sessions.
The risk, once again, is underestimation. However, the Time&Material model mitigates it.
Step 4. Implementation
Once the system is ready, it can be launched at the customer’s business.
Off-the-shelf
There are two ways to go live with such a system. The first one is “the big bang” where the transition to the new software happens immediately. It requires significant resources and staff support to pull off, but it is easy to understand and allows you to gain the benefits of the system quicker.
The second approach is incremental, where elements of the system launch one-by-one. You have to have a clear go-live schedule and need to keep your employees up-to-date on what they should use and when — otherwise they might be confused. However, this helps your staff learn the new ERP step-by-step, reduces initial productivity loss, and makes it easier to fix any implementation issues.
The first risk is that the vendor will require that you purchase specific hardware even though you already have an alternative installed.
The second risk is the ERP failing to cover all the business processes you need automated. In this case, you would either have to pay for extensive customization or adjust your processes to fit the software.
Custom
The process is pretty much the same as above. The only difference is that the MVP-first approach lends itself better to incremental implementation. The turnkey ERP development company won’t force you to adapt to its practices in either software or hardware — tailoring the system to the client’s needs is the whole point of custom ERPs.
Step 5. Support
This stage is much more prominent with custom systems but is worth mentioning in both cases.
Off-the-shelf
The customer’s IT department gets admin and super-admin privileges to handle the day-to-day activities of the company. The more in-depth technical matters would still be handled by the vendor.
Boxed ERPs typically require regular payments. The exact price would depend on the number of modules, the number of users, payment periods, and other factors. All-in-all, a basic boxed ERP with minimal customization (covering 25%-40% of the processes) and a year’s license would set you back by at least USD 300.000. There really isn’t an upper limit to this number, as it would depend on the size of the company. You will also have to keep paying the subscription fees to keep your system operational.
Custom
With a turnkey system, you could either manage everything in-house or have the same split as with a boxed ERP. The latter case could involve additional work like building extra modules or adding more functionality to the existing ones. The costs would depend on the exact nature of the work. However, an MVP version would cost about USD 400.000, give or take. This includes the core features of the few most important modules that would give the best ROI.
Summary
This is when you should consider boxed ERPs:
- You have few unique business processes;
- You are okay with the high long-term cost of ownership;
- You need to quickly automate a number of critical business processes.
This is when you should choose a custom ERP:
- You have many business processes specific to your company;
- You want a lower long-term cost of ownership;
- You want independence from the vendor.
We understand that the topic is much larger than can be covered in one article. So if you have any other questions, feel free to reach out to us for a free initial consultation! Take full advantage of Enterprise Resource Planning Solutions from Aristek Systems!