Implementation & Services
What to Expect from an ERP Implementation
An implementation team can know the software inside out and still not know how your business should run.
They do not know which customer exceptions matter. They do not know why one team keeps a spreadsheet outside the current system. They do not know which old records are still useful, which integrations the business depends on or what happens when an order does not follow the normal path.
Your team does.
That is why ERP implementation is not something a distributor simply hands over to a software company. The implementation team brings product and technical knowledge. The distributor brings the operating knowledge needed to make the system fit the business.
Show how the business really works
Documented processes are useful. So are the things people do that never made it into the documentation.
If customer service keeps a spreadsheet because the current system does not show something clearly, that spreadsheet is part of the process whether anyone intended it to be or not.
If one employee knows how to fix a particular order problem and everybody calls that person when it happens, that matters too.
The same goes for information maintained in more than one system, reports people build manually and steps that exist because one application does not communicate with another.
An implementation team needs to see those realities.
DemandBridge's Professional Services intake starts with similar questions: what is the customer trying to accomplish, what is the goal and how does the current process work? That context helps define the work before configuration begins.
The objective is not to recreate every workaround in a new system. It is to understand why the workaround exists before deciding what replaces it.
Be ready to make decisions
ERP projects surface questions the business may not have had to answer explicitly before.
- Which system owns the customer record?
- Does this approval still need to happen?
- Which users should be able to change this field?
- How should a stocked order behave differently from custom work?
- How much historical data should come across?
- What happens to an application the business intends to keep?
The software team can explain what the system supports. It cannot make every business decision on the distributor's behalf.
Some old processes should survive because they reflect customer requirements, financial controls or the way the company genuinely operates.
Others exist because the previous systems forced people to work around limitations.
Knowing the difference takes people who understand the work and have enough authority to make a decision when the project needs one.
Data migration is a business exercise too
Moving data sounds technical until somebody has to decide what the data means.
Customer records may be duplicated. Old vendors may no longer be relevant. Required information can be missing. Codes that made sense years ago may have little value in the new environment.
Historical information also needs a purpose. Keeping everything simply because it exists can make a conversion harder without making the new system more useful.
Pre-conversion preparation can include reviewing retention settings, archiving and purging appropriate records, running diagnostics and rebuilding data files before conversion or migration.
The exact preparation differs by project.
What does not change is the need for someone on the business side who understands the records well enough to answer questions about them.
An implementation team can move data. It should not have to guess which duplicate customer is correct.
Integrations need decisions before they need code
Most ERP projects do not replace every other application in the company.
Some systems stay.
That creates another set of questions: what information needs to move, which system owns it, when should it cross over, and what happens when something fails?
DemandBridge Professional Services scopes integration and SSO/Punchout work alongside other new-work engagements.
The important work begins before anyone builds the connection.
"Integrate ERP with accounting" is not enough direction for a technical team.
Which customers need to move? Where are invoices created? Where are payments recorded? What happens if a transaction is rejected?
We cover those questions in more detail in Connecting ERP to Your Accounting System, but the same thinking applies to ecommerce, CRM and other applications.
Clear ownership makes the technical work much easier to define.
Test the work that usually causes trouble
A clean login page is not an implementation test.
Neither is entering one perfect sample order.
Use the work your team actually handles.
- Enter a normal inventory order.
- Try custom work that requires a supplier.
- Change an order after purchasing has started.
- Receive inventory.
- Test a warehouse release.
- Run the integrations that matter.
- Use the customer or program rules that regularly create exceptions.
- And include the awkward scenarios people mentioned when the project began.
Testing should give the business a chance to find where its assumptions and the configured system disagree.
That is much easier to deal with before go-live.
Training should answer "what do I do now?"
People do not all need to understand the ERP in the same way.
A warehouse user, customer-service representative, finance user and system administrator have different jobs.
Training becomes more useful when it connects system knowledge to those jobs.
- What changes when an order comes in?
- Where does this information live now?
- What should I do when the normal process does not apply?
- Who can change this?
- Where do I go when I need help?
DemandBridge provides ongoing learning through the DemandBridge Learning Center and DB University, including guided, self-paced and webinar-based training across the product family.
Those resources support product knowledge. The implementation still needs to connect that knowledge to the processes the business has decided to use.
Know who owns what after go-live
Going live changes the kind of questions people ask.
Some are product-support questions.
Some are training questions.
Others are requests for new work or changes that need to be scoped.
DemandBridge's current service model separates ongoing Support from Professional Services and new-work requests. Professional Services includes areas such as integrations, training, template/site work and other scoped engagements.
That distinction is worth understanding before the first issue appears.
The distributor also needs ownership internally. Someone needs to know who can make process decisions, who owns integrations and who is responsible for deciding whether a requested change is necessary.
A new ERP does not remove the need for those decisions.
What the implementation team needs from you
The implementation team can bring product knowledge, technical experience and help with configuration, integrations, data and training.
What it cannot do alone is decide how your business should operate.
The strongest preparation a distributor can bring to an ERP implementation is not a perfect requirements document.
It is access to the people who understand the work, authority to make decisions when questions come up, and enough time to test whether those decisions hold up in the system.
DemandBridge Services supports scoped implementation-related work, integrations and training around DemandBridge environments.