Time to ditch the duct tape?
When to replace third-party services with your own ERP
We all love duct tape, but have you ever reached the limits on what even duct tape can do? I reached the tape’s outer limits when trying to repair the bottom of a hummingbird feeder last month. The tape needed to hold the bottom in place, battling gravity against the sugary water the feeder held. I’m sure the duct tape tried to hold on as hard as it could, but it wouldn’t do. Sometimes even the best fixes fail, and you’ve just got to get a new one.
Third party services can be duct tape
Picture this: a rapidly growing real estate company has been using over 13 third-party systems duct taped together to manage their internal operations. This includes parsers, API integrations, multiple CRMs, documentation for compliance, contract approval flows, vast lists of data, and complex reports on nearly 1,000 agents and all of their buyers and sellers. Whew.
Third-party systems were perfect when they first got off the ground, but with their business success, these third parties have become expensive and cumbersome. Webhooks didn’t always post properly, data was isolated in separate systems so it was difficult to use it, and entire teams were occupied with ensuring compliance data (the data you gotta have right) was accurately shared between the systems.
An Enterprise Resource Planning system, or ERP, is a big upfront investment that only companies at a certain stage of maturity should embark upon. In this case, however, this company needed to invest in this system.
When my client first explained the next project they needed me to design, I was nervous. I know how robust ERP systems need to be if they are to be effective, and the cost that would come with that need. My chief goal is to catapult my clients into success and help them avoid pitfalls. Yet, as I delved into their business needs, I quickly saw what they saw: a system duct taped together that was beginning to break under their incredible success as a real estate company.
Diagnosing the need
Ultimately, your decision to move to an ERP model is based on one thing: The cost of an entirely new system outweighs the cost of using your current system.
It can be difficult to grasp a clear picture of the costs in the immediate reality, but time is the key component to all of this. You are not only making a decision for your current company, but also your future company.
- Were do you see your business in 5 years?
- What about in 10 years?
- How many users will you have by that point?
- How much revenue will you have by then?
With this in mind, let’s get into the details.
The cost of your current system
- Your internal processes are repetitive and annoying.
If you’re asking yourself, “Isn’t there a better way?” and drowning in a monotony of inefficiency, it sounds like it’s time to come up with a systematic solution. The more established a process, the more frustrating the small inefficiencies become.
Multiply this by company growth and the pressure this creates to complete a frustratingly meticulous task quickly. Sometimes annoyance is a good indicator that something needs to change!
2. Your internal processes are established.
A company just getting off the ground must go through a stage of pivots and adaptations to find their niche and consumer base in the market. This is not the stage to be building your ERP system. When a company is young, it needs to be agile and flexible. Generally, it is as the company gets more established that the positive affordances of flexibility and agility get quickly overshadowed by the inefficiencies in the process.
3. Your current system is an obstacle to growth.
Every third-party system must be general enough to suit a number of different customer needs, and has had to make decisions that limit certain features in order to focus on other use cases. As a company evolves to find its right fit in the marketplace, it often creates unique needs that these systems cannot handle, simply because they are not built to.
The ingenuity of your business leaders and the creativity of your teams can quickly knock hard against a third party system’s limitations. I am all in favor of getting by as long as you can with what you have. But it’s important to recognize when the obstacles are inhibiting your growth.
4. You can’t trust your current system.
You have data that must be accurate, which means you need a high level of trust inthe accuracy of your system without you waking up in the middle of the night or have your heart race as you open your computer in the morning. We all count on the tools we use, and should have a measure of peace with them.
This was a clear indicator to my client that it was time. They needed their documentation system to flow seamlessly with their CRM for government compliance. They depended on this, and the stakes were high. As they grew, the holes in the data transferred through the API also grew.
Some systems naturally require human oversight. These are often very technical, such as managing servers, upgrades, etc. In this case, an established API that should successfully talk between systems, but was failing, was out of this company’s ability to maintain. It should have worked, but it didn’t. Having to employ people to pull up two pages on their computers just to make sure the patch went through is no good.
5. Third party systems are upper pricing plans
It’s common for third party systems to have cheap or even free starter plans. These are perfect for small businesses or start ups; however, there reaches a specific benchmark where the cost grows exponentially. Unfortunately for this company, they had originally configured their CRM to require multiple accounts which, in their rate of growth, had become very expensive.
Is the duct tape working? Or is the important stuff — the value your company delivers and the time of your employees — leaking out? Can the duct tape last 5 years? What about 10 years?
The cost of a new system
A new system is an upfront expense. It’s sort of like buying a new home, where it will most likely be very worth it, but you have to look beyond the massive down payment and total cost of the home to see the potential.
There are three major costs associated with building an ERP system: design, development, and maintenance. The cost of each of these is directly related to the size of the system you need to build. Since it is difficult to put a cost to this (am I building a shack or a mega-mansion?), I will instead lay out the aspects of cost. This can give you an idea of the questions you need to ask and the info you need to bring to an agency or whomever you want to build this system.
The three big costs
- Design
Okay, am I biased here? Maybe, but I actually don’t consider design a cost as much as a cost-saver. A commonly-cited report by Forester estimates that every dollar invested in UX design yields $100 in profit!
I have seen products on both sides: products with scoping and development that skipped design, and products that incorporated a designer early on. Your system is going to get designed by someone. Would you rather it be designed by an experienced UX designer who focuses purely on the designs, knows the use cases to anticipate, and how to communicate between the developer and you, the stakeholder? Or would you rather skip design and have the developer, who is not focused on designing the system for its users, but just making it work design the system? It’s a rhetorical question. Please use a designer, and you will save yourself, your team, and your developers from the pitfalls and extra cost that can come from trying to skip this step.
Ultimately, using a UX designer to design your system rather than yourself + a developer saves you money and may just save your product.
2. Development
Different dev teams charge different rates, but this is often closely correlated with the quality of code and inversely the technical debt you could incur. The more expensive, the higher the upfront cost, but hopefully the lower to cost to maintain and scale. I have watched startups try to put out MVPs that are so cheap, they have to rewrite the entire code base within a couple of years. This is, ironically, more expensive and technical than if they started with the right foundation but a limited scope at the beginning. If you’re looking to build an ERP system, you’re way past the MVP stage where it could possibly be worth it to incur technical debt. You’ve already been just getting by with your third party systems. It’s time to find a quality group to develop your system.
3. Maintenance
Do not underestimate the ongoing costs of maintaining your own system. Think of a product like a garden; it requires attention and care to stay healthy. You will need to keep it healthy on the technical side, staying on top of software updates and data needs. However, you will also need to stay on top of the user experience, ensuring that as your company grows and evolves, your system is staying up to date with your needs.
When you get an initial estimate for designing and building an ERP, also be sure to get an estimate for ongoing maintenance costs. This will include the necessary services the system is built on, such as servers, but it should also include estimates for ongoing dev and design time. Many development agencies estimate this cost to be up to 50% of the original cost in the first year, and 20% of the original total in following years. Compare this to the costs of your current system operating — the tools and the dev hours to keep this running.
Last but not least, take into account if your current system is getting in the way of business growth. How could your business grow and increase revenue if it had the proper system in place to operate efficiently?
Clarifying questions to determine cost to build
- How many user types does your system need?
Chances are, you have teams with different functions who all need to use this system. In the end, the point of building your own system is to seamlessly integrate these users’ functions so that all of your operations can talk and move fluidly together.
Look at these different teams in and write down each team, what they do, and what they need. This will be the starting point for your entire system.
2. What is the relationship between users and organizations? Do you anticipate having multiple organizations using this software independent of each other?
If the answer is “yes” or even “maybe,” you may need to build using a multi-tenant architecture. Multi-tenant architecture is a foundational decision that enables organizations (often entire companies) to have isolated resources for security requirements and other needs. There are different degrees this can be scoped. With the most extreme security requirements, an organization could be given its own cloud server.
These decisions need to made not only with your immediate business needs in mind, but also your future needs. These architectural decisions are foundational to your system, so even though it may take more time to build using a multi-tenant architecture upfront, it can save you from the much higher costs of fixing this later or becoming pigeonholed.
These questions can aid with your initial scope:
- Will you have multiple organizations using this system?
- Can a user belong to multiple organizations?
- What are the security requirements organizations will need?
- What will this look like in 5 years? In 10 years?
Your business’ use case will be unique, requiring a unique solution. A software architect will be able to scope the best solution from the technical side, ensuring that your system will be able to scale in the future.
3. What are the key actions each user type performs?
Detail out simple flows for each user type. This will give your designer and developer a clear understanding of how complex the needs are for each user type. A flow can be as simple as:
Account team → reviews invoice → pays invoice → records payment in system
Now you’re starting to get a picture of the system you need!
4. What is your critical data and what needs to be done with that data? (What is your business’ “thing”?)
The data your system revolves around and what is done with that data is usually the core of your business operations. “Data” sounds pretty technical (which it is) but simply said, what is the thing your business revolves around? Here’s an example from my real estate client:
Data:
- a list of contacts who want to buy or sell a home
Actions:
- assign contacts to agents
- edit info on contacts
- Create a transaction associated with that contact
Another business may revolve around e-commerce products, another around business listings, another around advertising devices. The nature of the thing you work with and how you work with it determine the cost as well as the type of designer and developer you want to find.
Conclusion
These are not only good questions to explore the cost of an ERP system, but also the initial questions to begin scoping your ERP system!
Use this information to get a feel for where your business is at, and if the cost of building an ERP really does outweigh replacing your duct tape system.
