A council is a large business with a small team. It sets and collects rates, pays staff and suppliers, maintains roads and parks, issues permits and answers residents. An ERP (enterprise resource planning) system is the software that holds all of that work in one place. This guide explains what a local government ERP does, and how a resident's report should flow into a work order and back to the resident.
We wrote it for council executives, finance managers, works managers and IT staff who plan a system change, or who want to know what to ask a supplier.
What an ERP is
An ERP is one system with many modules that share one database. A transaction in one module is visible in the others. When a crew uses materials on a job, the cost reaches the job, the asset and the general ledger. Nobody types it twice.
The alternative is many separate systems with links between them, or with spreadsheets and email between them. Separate systems can work, but every link is something to maintain, and every gap is somewhere that information stops.
What a council ERP does
A local government ERP covers the work that most councils have in common. The exact list differs between suppliers and between councils, but these are the usual areas.
Finance
- the general ledger and the chart of accounts
- budgets and forecasts
- accounts payable and purchasing
- accounts receivable and debtors
- bank reconciliation
- the annual financial statements
Property and rating
- the property and land register
- owners and occupiers
- rates, levies and charges
- rate notices, payments and arrears
Rating is the part that most separates a council ERP from a business ERP. Property is the centre of a council's records, and many other modules link to it.
Assets and works
- the asset register, with condition and valuation
- maintenance plans and inspections
- work orders for crews and contractors
- labour, plant and materials costed to each job
People
- payroll and timesheets
- leave and award rules
- employee records
Customers and regulation
- customer requests from residents
- permits, licences and applications
- animal registrations
- records management for all of the above
Where resident reports fit
Customer requests sit between the resident and the works crew. A pothole report is a customer request. Filling the pothole is a work order. The cost of filling it belongs to a road asset and a budget line.
When these are in separate systems, the flow often looks like this:
- A resident reports the pothole by phone, email, web form or an app.
- A customer service officer types it into the request system.
- A works supervisor reads the request and creates a job in the works system, or writes it on a list.
- The crew fills the pothole and records the time on a timesheet.
- Somebody, sometimes, goes back to the request and closes it.
- The resident hears nothing, or hears weeks later.
Each step is a chance for the request to stop. The council also cannot easily answer simple questions, such as "how long do we take to fill a pothole?" or "what did potholes cost us on this road last year?".
The flow when it is one system
When customer requests and works share one ERP, the same pothole follows a shorter path:
- Report. The resident sends a report with photos, a map pin and their contact details.
- Request. The report arrives as a customer request with all of that attached. Nobody retypes it.
- Assign. Routing rules send it to the roads team. A supervisor assigns it to a crew.
- Work order. The supervisor turns the request into a work order in one step. The work order links to the road asset.
- Cost. The crew's labour, plant and materials are costed to the work order and the asset.
- Close. When the job is done, staff close the request. The request and the work order stay linked.
- Tell the resident. The resident sees the status change: received, scheduled, in progress, completed.
This is how a council ERP generally works when customer requests and works share one system. With Localtech Core (in development): the LTP council ERP will have a Customer Requests module that follows this flow. Reports from Localtech Eye will arrive as customer requests with the photos, map pin, address and the resident's contact details. The module is not available yet. Today, councils receive Localtech Eye reports by email, with the photos, the map point, the address and the resident's contact details.
For a longer walk through the council side of this flow, read From resident report to work order: closing the loop.
Why the work order matters
The work order is where a council spends money. If a resident's request does not link to a work order, the council loses three things.
It loses the cost. The council cannot say what a type of request costs, or which roads cost the most to keep safe.
It loses the history. The next time a resident reports the same spot, staff cannot see that a crew patched it three months ago. That history helps the council decide when to repair and when to replace.
It loses the resident. The resident does not know that the job is done. They report it again, or they phone the council. Each call costs staff time.
What to look for in a council ERP
If you plan to change your ERP, or to add customer requests to the one you have, ask suppliers these questions.
About customer requests
- Can requests arrive from an app, a web form and email without retyping?
- Does each request keep its photos, exact location and the resident's contact details?
- Can routing rules assign requests by category and area?
- Can staff turn a request into a work order in one step?
- Does the resident get status updates without extra work from staff?
- Can staff mark a request as a complaint, and send it to the complaints process?
About works and assets
- Do work orders link to assets in the asset register?
- Are labour, plant and materials costed to the work order?
- Can supervisors see open requests and open work orders on one map?
About data and hosting
- Where is the council's data held, and in which country?
- Is each council's data kept apart from other councils' data?
- Can the council export all of its data in a standard format?
About the change itself
- How does the supplier move data from the old system?
- How long does a typical move take, and who does the work?
- What does the council's team need to do, and when?
The last group of questions deserves its own guide. Read Moving off an old council finance system: a plan.
Common problems with older council systems
Many councils run finance systems that were designed many years ago. Some common problems:
- Separate modules that do not share data. The request system, the works system and finance each hold their own version of the truth.
- Web forms with no map or photos. The property system's portal may create a request directly, but often with only a typed address.
- Customisations that nobody can maintain. Reports and interfaces built for one person who has since left.
- On-premises servers. The council carries the cost and the risk of backups, upgrades and security.
- Licences that grow with every module. A module the council needs can cost more than the value it brings.
None of these is a reason to change systems by itself. Together, they are often the reason a council starts to look.
Small and rural councils
Large councils can afford a team to link separate systems. Small and rural councils usually cannot. A small council may have one IT officer, or none. It needs a system where the links already exist.
For a small council, the value of one system is simple. A request arrives, a supervisor assigns it, a crew does the job and the resident hears back. Nobody in the office copies anything between systems. We write more about this in Issue reporting software for small and rural councils.
Resident reports without an ERP change
A council does not need to change its ERP to take better reports. Localtech Eye sends reports to every council it serves:
- Today, councils receive Localtech Eye reports by email, with the photos, the map point, the address and the resident's contact details.
- The council then contacts the resident directly.
- With Localtech Core (in development): the Customer Requests module will receive Eye reports as customer requests, ready to assign, and residents will see status updates in the app.
This lets a council start with better reports today, and connect them to work orders later.
Localtech Eye is live for Queensland councils. New Zealand, the United Kingdom, the United States and Canada are now taking councils, but there is no resident service there yet. See Australia or New Zealand for details.
See the flow with your own data
The best test of a council ERP is to watch one request travel from a resident's phone to a closed work order. Book a demo and we will show you Localtech Eye with your council's categories and boundary, and talk you through the plans for Localtech Core. You can read more about Localtech Core on the Local Technology Partners website, and more about Eye on the page for councils.