An industrial waste business differs from an ordinary product business in one respect. What the contract fixes is not a number of items but a weight to be collected and disposed of within a period, and the collection happens over many rounds across the life of the contract. So the question that has to be answerable every day is a single one: how much has been collected against this contract, and how much is left.
This article describes one real enterprise resource planning implementation, carried out for WASTE CONTROL CO., LTD., a company within the same group as ours. It covers the brief we were given, what the standard modules handled, what had to be built, and what was handed over. The scope described here is the first phase, covering the path from lead through to payment, which has been delivered.
The brief
There were three main requirements, and all three came from how the client actually works rather than from any software feature list.
| Requirement | Why it mattered |
|---|---|
| Quotations had to closely resemble the form already in use | The client's own customers were familiar with the existing layout, and changing it abruptly raises questions nobody needs |
| It had to be possible to know at any time how much of a contract has been collected and how much remains | That figure decides whether more work can be accepted, and it is the basis for planning vehicles |
| Work for a single client recurs many times | Setting up each round by hand costs time and things get missed |
What the standard modules covered, and what had to be built
Most of the project was configuring standard modules to match how the business works, rather than writing something new.
| Area | Standard configuration or built |
|---|---|
| Chart of accounts, journals, taxes, and products | Standard configuration |
| Sales teams, user permissions, and document numbering | Standard configuration |
| The path from opportunity to sales order to project | Standard modules joined together, adjusted so a project can be created straight from the sales screen |
| The look of the quotation | Built, to closely match the existing form |
| Tracking collected weight against the contract | Built entirely. There is nothing standard for this |
| Linking the site survey to pricing | Built |
Drawing that line matters to a reader assessing their own project, because the built part is where the time and the risk sit, while standard configuration can be estimated far more accurately. The scope of the standard system is set out in more detail in our article on the website that comes with an ERP
The three things that had to be built
First, tracking weight against the contract. The system holds the agreed target weight, subtracts what has been collected in each round, calculates the proportion remaining, and warns when the balance falls below a set threshold. The result is that the team sees one figure rather than assembling it from several documents.
Second, creating a project straight from the sales screen. Where work for one client recurs many times, the system takes a prepared project template and creates a new project already linked back to the original opportunity, in a single step, instead of setting up each item by hand.
Third, linking the site survey to pricing. What the site survey records is attached directly to the opportunity and then used to price the quotation, rather than the same information being typed into two places.
All three share one characteristic: they do not add capability to the software, they reduce the number of times a person re-enters the same information, which is where data most often goes missing.
What was delivered besides the system
A configured system is not yet a system in use. What was handed over therefore included:
- Cleaning the data before import, covering contacts and companies, opportunities, and products
- Importing the existing data into the system
- Training on how to use it, covering customer relationship work and the path from lead to sales order
- Six user manuals, covering the main work path, issuing quotations in detail, the weight tracking, creating products, and the other areas involved
Manuals are the part most often cut when budgets are tight, yet they decide whether the system is still in use a year later, once the people trained in the first round have moved on or changed roles.
What carries over to other projects
Reduced to lessons that generalise, there are three.
First, the hardest requirement is usually not a technical one. It is keeping the documents that reach the client's own customers close to what they were, because changing them affects people outside the organisation who had no say in buying the system.
Second, the part that has to be built is usually the number the business decides on every day. Here it was the weight remaining on a contract, which is absent from standard systems precisely because not every business needs it.
Third, finishing the configuration is not the same as delivering. What keeps a system alive is the data cleaning, the training, and the manuals, and those take no less time than the configuration did.
Closing
This project is an example of work that a standard system covers almost entirely, where the remainder happens to be exactly what the business decides on. The job of whoever implements it is therefore not to pick the right software, but to separate what standard configuration can cover from what has to be built, and to agree that with everyone before starting.
Once the system has been in use for a while, we will collect the actual results with the client and write up how much difference it made.
If your organisation has particular conditions you believe a ready-made system will not cover, you can read more about our ERP work on the ERP Odoo page