ERP Solution Design

Why ERP solution design is often skipped, and what it costs

In many ERP projects, design happens inside configuration. A consultant sets up the company, creates some accounts, adds a few approval rules and moves on. It feels fast, but each of those choices shapes years of daily use and reporting, and many are made without the people who will live with them.

The consequences tend to appear months later:

• management reports cannot be produced because the data was never captured at the right level;
• the chart of accounts has to be restructured mid-year, with all the reconciliation work that implies;
• approvals are either so loose that controls fail or so tight that people work around them;
• integrations duplicate customers or items because nobody decided which system owns them;
• customizations are added one by one, without a view of how they fit together.

A solution design phase prevents most of this. It turns the requirements from your BRD and the decisions from your gap analysis into a coherent blueprint before configuration starts. It does take time up front, but it is far cheaper to change a design document than a live system.

What goes into a solution design document

The solution design document is the central artifact. Its structure varies by platform and project size, but it usually includes:

1. Design scope and principles: what is covered, and agreed principles such as "standard first, customize only for Must requirements".
2. Organizational structure: legal entities, branches, warehouses, cost centers and how they relate.
3. Module design: for each module in scope, the key configuration decisions and settings.
4. Process design: how each to-be process runs in the system, step by step, linked to the process maps.
5. Master data design: customers, suppliers, items, price lists and accounts, with naming and coding rules.
6. Roles and security: role definitions, permissions and approval matrices.
7. Integrations: an interface list with direction, frequency, method and data ownership.
8. Reporting: report and dashboard catalog with data sources and audiences.
9. Customizations: each one justified, specified and linked to its requirement.
10. Decision log: design choices, alternatives considered and who approved them.

I write it so a business owner can read the sections that concern them, while the implementer has enough detail to build and test.

Chart of accounts, entities and roles

Three design areas deserve special attention because they are hard to change once the system is live.

Chart of accounts and dimensions. I work with finance to design an account structure that supports statutory reporting, tax, and management analysis together. The key decision is what lives in the account code and what lives in dimensions or analytic tags, such as department, project, product line or region. Get this right and most management reports come straight from the ledger. Get it wrong and finance rebuilds reports in spreadsheets every month.

Entity and location structure. How companies, branches and warehouses are set up determines how stock moves, how intercompany works, and how consolidated reporting is produced. These choices depend on your legal structure, tax registrations and how you actually manage the business.

Roles and approvals. I design roles around real job functions, then build an approval matrix covering purchasing, sales discounts, credit limits, expenses and journals. Segregation of duties is checked so that, for example, the person creating a supplier cannot also approve payments to it. The aim is control that people accept, not rules they route around.

Integration, data model and reporting design

An ERP rarely stands alone. It usually connects to a CRM, an eCommerce store, banking, payroll, a warehouse or logistics tool and a reporting layer. In the design I document every interface: what data moves, in which direction, how often, by which method, and what happens when a sync fails. The most important decision for each data object is which system is the master. Customers might be created in the CRM, items in the ERP, prices in one place only. Without that rule, duplicates and mismatches follow. My ERP integration service covers the build and monitoring side.

The data model design defines how master data is structured and coded, which fields are mandatory, and what history will be migrated. This links directly to ERP data migration planning.

Finally, I design reporting from the top down. Starting with the decisions management needs to make, I list the reports and dashboards required, the data each needs and where that data is captured. If a report needs a field that no process captures, the design catches it now rather than after go-live, when the history is already missing.

Independent design oversight for your ERP

Implementation partners produce design documents too, and good ones are valuable. But a design written by the party who will build it can lean toward what is quickest for them to deliver, or toward custom work they are comfortable billing. And once the design is signed, it becomes the reference for any later discussion about scope.

I can play two roles here. On some projects I write the solution design myself, working with the implementer to confirm feasibility on the chosen platform, whether that is Zoho, Odoo, ERPNext or Microsoft Dynamics 365. On others I review the partner's design on your behalf, checking that it traces to the requirements, uses standard features where possible, and will produce the reports you need.

Either way, you get a design you understand and own. The same blueprint then guides configuration, testing and training through ERP implementation. Contact me to discuss the design stage of your project.