ERP implementation, from the process map to the cutover.
Chart of accounts, inventory, dispatch and invoicing in one system that matches how the company actually works, built and run by the team behind Alibera, our own field service and ERP platform.
What this is
ERP implementation is not installing a piece of software. It is taking whatever the company actually runs on today, a mix of spreadsheets, a basic accounting package, paper job sheets and a few disconnected tools, and rebuilding it as one system where the chart of accounts, the inventory, the sales orders and, for a service business, the work orders all point at the same records. The difficulty is almost never the software. It is that every department has its own private version of a process the company thinks it has one version of, and the implementation is the point where that stops being possible.
We build and run this ourselves. Alibera is our own field service and ERP platform: we hold the source, we extend it, and we operate it, with the same team doing the implementation. It is not a licence to somebody else's product that we configure and hand back. That matters at the exact moment it usually goes wrong: a client's process does not fit an existing module. On a licensed platform that means a workaround bolted to the side of it, or a change request that sits in a vendor's backlog. Here it means we change the module. We are not a reseller or a certified implementer of anyone else's ERP, and this page should not read as if we were.
The order of operations decides whether this works. Master data first: the chart of accounts, customers, suppliers, inventory items and opening balances, migrated and checked before anything transactional touches the new system. Then the modules the business actually needs, financials and inventory before the parts specific to the operation, dispatch and technician scheduling for a company with crews in the field, custom modules for whatever standard ERP does not cover. Old and new run in parallel for a defined stretch before cutover, so a mistake shows up on a report rather than in a paycheck or a customer's invoice. The projects that stall are almost always the ones that tried to migrate ten years of transaction history instead of a clean opening balance, or that went live everywhere at once instead of in an order that kept something usable at every stage.
For a business with crews in the field, forklifts, hydraulics, generators, construction machinery, the implementation usually includes dispatch, mobile field reports and service history alongside the accounting, because those companies lose the most to a system that only handles the office half of the operation. Fiscalization and invoicing get wired in as part of the same build rather than left for later. If fiscalization and e-invoicing are the only piece that actually needs fixing and the rest of the operation already works, that is a narrower job, E-invoicing and fiscalization, not a full implementation.
What you get
Process map
A written record of how work actually moves through the company today, exceptions included, produced before anything gets built rather than assumed.
Master data migrated
Chart of accounts, customers, suppliers, inventory items and opening balances, carried across and checked rather than retyped.
Core modules configured
Financials, inventory and purchasing built around the accounts and processes that came out of the process map.
Dispatch and field service, where it applies
Technician scheduling, mobile field reports and service history for companies with crews and equipment in the field.
Custom modules for what standard ERP does not cover
Written and added to the platform, not worked around with a spreadsheet next to it.
Fiscalization and invoicing wired in
Compliant with Slovenian fiscalization from the first invoice the new system issues.
Integrations to what else the business runs
Banking, e-commerce or an existing point of sale, connected rather than re-keyed.
Parallel run, cutover and support
Old and new side by side before go-live, then training and support for the people who run it daily.
When this fits, and when it does not
A good fit
- Running the business on spreadsheets, paper job sheets and a handful of tools that do not share one number for stock, revenue or who is where.
- A service or maintenance company with crews in the field, forklifts, hydraulics, generators, construction machinery, and field records that currently get retyped back at the office instead of feeding straight into invoicing.
- Outgrown a basic small-business accounting package and need inventory, purchasing and service history to live with the books instead of beside them.
- Willing to let some internal process change to fit a system built for the company, rather than adding one more spreadsheet next to the ones you already have.
- Fiscalization and invoicing need to be correct as part of a bigger rebuild, not as the only thing wrong with an otherwise working operation.
Not a good fit
- A team of one to three people running fine on a spreadsheet and a basic invoicing tool. The disruption of a switch costs more than the disorganization does at that size.
- You already run a mainstream ERP or accounting platform and it works. The actual complaint is one missing integration or a report that does not exist, and that is System integration, not a re-implementation.
- Your board or an auditor requires a named vendor's certified implementation, SAP, NetSuite or similar. We build our own platform, and we will say that upfront rather than take the project and get stuck relearning someone else's system.
- The real problem is a legacy application nobody can touch, not the absence of an ERP. That is Legacy modernization.
- Fiscalization or e-invoicing is the only thing actually broken and the rest of the operation already works. That is E-invoicing and fiscalization, a narrower and faster piece of work than this.
How it runs
- 01
Map the process
Talk to the people doing the work, not just the owner, and write down the exceptions and the workaround everyone already uses.
- 02
Migrate the data
Chart of accounts and master data first, opening balances checked, before anything transactional touches the new system.
- 03
Build and configure
Financials and core records live first, then dispatch, service history and whatever custom pieces the operation needs, kept demonstrable at every stage.
- 04
Run parallel
Old system and new side by side for a defined stretch, so a mistake is caught on a report rather than in a live invoice or a paycheck.
- 05
Cut over and support
Go-live, training for the people who run it daily, and support afterward.
Questions we get
Are we buying a licence to somebody else's ERP product?
No. Alibera is our own platform: we hold the source, we extend it and we operate it. We are not a reseller or certified partner of another vendor's ERP, so when your process does not fit a module, we change the module rather than asking you to change your business around someone else's roadmap.
Do you handle field service, or just the back office?
Both, and for a lot of our clients field service is the harder half. Dispatch, technician scheduling, mobile field reports and machine or service history are core to the platform, built for companies with crews and equipment in the field rather than added on afterward.
How much of our historical data has to move?
Master data and opening balances: customers, suppliers, inventory items, the current chart of accounts. Years of old transactions usually do not need to move, and trying to bring all of it across is one of the more common ways an implementation stalls.
Who supports the system after go-live?
We do. Alibera is hosted and run by the same team that builds it, so support, monitoring and the roadmap stay in-house rather than getting handed to a reseller once the project ends.
More digitalization
Running the company on spreadsheets and a hope?
Send a description of how the work actually moves through the company today. The Alibera team reads it and tells you straight whether a full implementation is the right size for it.