This article is for…
- IT leaders exploring and justifying the need for a new enterprise application (i.e., ERP)
- Business managers learning about and understanding true investment scope to deploy an ERP
This article will help you…
- Reach confidence in estimating the costs of a prospective application
- Determine steps needed to achieve a workable ERP investment estimate
- Articulate inputs required to answer ERP pricing questions and defend those answers
A common dilemma in a simple example
One of my friends owns a relatively small tile distribution and installation business in Ontario, Canada. When he decided to move his inventory and operations to a new warehouse, he began to contemplate automating some operations and asked me how much an adequate software package would cost him to do just that. Because of my familiarity with the business, I had a fair understanding of what operations could be automated and had already thought of Odoo Inventory as a potential fit. Despite having that knowledge, giving my friend a straight answer to his seemingly reasonable question was difficult, even considering such a small scope, most likely limited to warehouse operations.
If I were a shrewd salesman casting a bait, I could have said, “It will cost you nothing.” And this answer would not be entirely false! At the end of the day, one online Odoo application, like Inventory Management, is indeed free – it even comes with mobile barcoding, which can be further enhanced with Ventor application for only a marginal price. And my friend was asking about the cost of just software, so why not give him an answer of “Zero $”…
What’s in a way
First and foremost, any Enterprise Application deployment and its use, ERP especially, does not cost just the software. The so-called “total cost of ownership” (TCO) of an ERP system includes implementation efforts and many other aspects as described in this article. So, offering $0 as an automation price tag to my friend without deliberating on how misplaced his question was in the first place would be effectively cheating.
For example, I’ve seen over a 1000 SKUs listed on 30+ pages of an SAP proposal for a large enterprise. When you don’t know who your ERP vendor choices might be, it is entirely unthinkable to begin your estimate with “software costs.” More productively, due attention is paid to the “collateral costs” of the implementation, which tend to go far beyond a mere software subscription. Such additional costs are often underestimated or even overlooked altogether.
Secondly, at the stage of merely contemplating ERP or any application expected to automate and guide business processes and operations execution, the scope and nature of these processes are nebulous, which effectively inhibits the exploration of functional and technical capabilities. This ultimately inhibits estimating investment costs with any reasonable accuracy.
The picture below is designed to visually present an ERP journey from its investment estimate accuracy perspective. While not pretending to rely on any statistically derived and sound numbers, the chart shows that knowing the cost of a given ERP implementation is a staged iterative process that could begin with having no idea about the costs involved (zero accuracy) and would only reach its 100% accurate number at ERP project closure.
Evolution of ERP Investment Estimate Accuracy
The contract gets finalized at the “contract signing” step, but there are still some unexpected turns along the way of the actual implementation, and that’s why a good project management practice sets aside some contingency funds (typically around 10% of the total ERP implementation allocation) to account for hiccups, a practice reflected in the graph. Executing previous stages well minimizes surprises, which leads to more accurate budget estimates while preventing so-called “scope creep”, which is a prevalent challenge in ERP implementation projects, and can increase costs above and beyond the 10% contingency (50% and more is not unheard-of).
This scope creep phenomenon occurs when the project’s deliverables, originally defined during the planning phase, expand beyond their initial boundaries. One of the primary drivers of scope creep is inadequate initial requirements gathering. When project stakeholders fail to articulate their needs comprehensively or anticipate future changes, the project scope may not adequately address all the needs. Additionally, insufficient stakeholder involvement and communication can result in misunderstandings or unaddressed expectations, leading to subsequent inflight scope changes. So, if you are “new to Odoo” (as pictured above) and hear, “It is going to cost you $10,” then don’t jump straight into implementation – that “$10” can turn into $50,000 very quickly!
In my friend’s situation, the most obvious scope creep risk was related to feeding the warehouse with orders, which was, at the time, done by printing paper forms from a custom-made application with no integration interfaces. Considerations needed exploration. For example, do we continue with manual entry from the same paperwork? Do we add interfaces to that in-house development? Shall we consider replacing that custom-made order management application with, for example, another Odoo module? While sounding technical, those questions should be answered by working with non-technical stakeholders who know the current state of respective process execution through that app and other means.
The iterative nature of cost estimation is reflected in another common factor contributing to scope creep – the dynamic nature of technology. Like in the simple aforementioned example, ERP systems often require integration with various existing systems, data migration, and customization to align with organizational processes. As technology evolves, new functionalities and capabilities emerge, tempting stakeholders to incorporate additional features into the project scope, thereby expanding the project’s boundaries. Developing appetites for sweet and shiny novelties can become quite unhealthy and should be restrained to align with project objectives stated at the very early stages of the journey. Otherwise, conflicting intentions can lead to competing priorities and incompatible agendas, further complicating project scope management and resources, resulting in delays and budget overruns.
Continuing with my friend’s business operations example, one of his major goals was to eliminate picking errors that had severe negative snowball effects on the installers of the product shipped from the warehouse. Barcoding and scanning had great potential for minimizing those errors, but they might require special equipment. “Might” – because Odoo’s Barcode (included with Inventory) or its enhanced third-party Ventor’s app can happily live and be used on a regular smartphone connected to a regular cellphone network (i.e., LTE), meaning that no investment in infrastructure or equipment is required as long as the warehouse operators agree to use their personal phones for the purpose. The convenience (e.g., holding a phone while moving product), capabilities (e.g., range), and reliability (e.g., connectivity) of such a setup, however, would likely be questionable, running the risk of ruining the very intent of making warehouse operations more efficient and accurate. So, for a plan of adjusting the warehouse IT infrastructure (i.e., adding reliable Wi-Fi connectivity) and adding barcode scanning, printing, and other equipment, in my friend’s case, I estimated the whole project to be up to $15,000; that’s quite a jump from theoretical $0. But the sky is the limit when it comes to computerized gadgets and their support contracts, and it’s important to not be carried away by useless niceties as well as to not cheap it out and blow the budget later by means of a hardware adjustment scope creep.
What can be done
In the end, I estimated this tiny project for my friend (which typically would not be even called “ERP”) as a first-year cost (with implementation) at $8,000 to $40,000, plus the second year (and ongoing) cost at $2,000 to $5,000. This “experiential guess” held 20% accuracy in the ERP investment estimate graph above, which effectively translated to circa $27,000 +/- 80%. Not very accurate for sure, but that was a start with a much better position than having no clue.
The next step, “guided estimate,” aims at significantly improving your budgetary estimate (to about 50%) to make it workable for project justification and meaningful ROI calculations. It is intended to be done by an experienced professional following through on a particular methodology and without any heavy engagement of ERP vendors with quotes, demos, or detailed requirements gathering. Rather than comparing vendor quotes for the yet-to-be-determined needs, the following aspects are considered to evaluate the nature of the solution, its likely vendors’ landscape (aka product tier), high-level architecture, and, as a result, the implementation effort with more accurate costing:
- Industry specifics including major functional capabilities, role profiles, risk tolerance, and regulatory environment;
- Size and complexity of the business and its growth aspirations, which drive the number of licenses and inform the desired product tier;
- Assessment of organizational factors important for successful implementation like change culture, Project Management Office (PMO) capabilities, Business Process Management maturity, and organizational complexity;
- IT maturity with emphasis on data quality, application landscape complexity, and previous staff experience with similar initiatives
While that list might look quite heavy for a small business like my friend’s, these principles of assessing and scoping out an ERP solution still apply even for a tiny company. Indeed, in my friend’s situation, current and anticipated growth can be a tie-breaker in choosing between continuing with the in-house development or replacing it with an off-the-shelf application. A property ownership alone can significantly influence the decision about upgrading IT infrastructure, for which the prospect of automating warehouse operations can be just a trigger; staff availability and experience with similar projects should guide the need for contracting additional resources, whether they would be for running the warehouse or for attending to project tasks. And all of that bears on costs, of course.
At the end of the “guided estimate” step, the costs can be broken down into the following general categories based on not specific ERP vendor quotations, but on relevant engagements from the same industry and similar organizational parameters:
- Subscription Costs
- Core Licenses & Additional Capabilities
- Support
- Deployment (Project) Costs
- Strategy & Selection
- Configuration & Customization
- Process Re-engineering
- Data Migration
- Integration
- Training & Change Management
- Project Management
- Project Contingency
ERP costs
Describing these categories (as well as discussing ERP implementation phases and activities, such as RFI/RFP) goes above and beyond the scope of this article, but a good starting point is this ERP TCO article, and, those interested in Odoo pricing specifically will want to read The True Cost of Odoo ERP: Pricing and Ownership Insights.
In summary
Estimating licensing costs is not and cannot be accurate at the “justifying” stage and tends to be even less so when merely contemplating ERP. However, the software costs alone do not represent the major expenses of an ERP project anyway. You will want to consider keeping a clear focus on building confidence in understanding your organizational factors and how they bear on potential costs. Such a strategy can eliminate the need for tedious, labor-intensive, and potentially misleading software price research, and instead provide you with a realistic outlook on true investment magnitude sufficient for high-level decision-making.
Have difficulty estimating the costs correctly? We’re here to help!
Recommended articles: