Every ERP sales pitch includes the same phrase: "Our system is built on industry best practices."
Translated: "We talked to 50 manufacturers, averaged their processes, and built a system for the average. Your business is not the average. But we will charge you to make it fit."
What "best practices" actually means
In ERP terms, "best practices" means predefined workflows. The procurement "best practice" is: create requisition, convert to PO, send to vendor, receive goods, three-way match (PO, receipt, invoice), pay.
That is a fine default. But here is what happens when your procurement does not work that way:
Your furniture manufacturer consolidates purchase orders per wood species across multiple jobs. That is not in the "best practice." Customization.
Your apparel operation buys from brand-nominated suppliers where the brand specifies the vendor, not you. That is not in the "best practice." Customization.
Your distributor accepts partial offers from suppliers, declines the rest, and re-ranks the offer pool by recency. That is not in the "best practice." Customization.
Each customization is a departure from the default. Each departure costs money and time. And after 10 departures, you are no longer running the "best practice" system. You are running a patchwork of customizations on top of a default that never fit you.
The problem with averaging
"Best practices" are averages. They describe how a generic business of a certain type operates. But no business is generic.
A furniture manufacturer with 600 employees, 20+ components per SKU, component-level wood tracking in cubic feet, and assembly-level SKU tracking has a fundamentally different operation than a metal stamping shop with 200 employees, 50 dies, and unit-level batch tracking.
Both are "mid-market discrete manufacturers." Both would be sold the same ERP modules. Both would spend $100K+ making those modules match their actual operation.
The average does not help either of them. The average helps the vendor, because it reduces development cost. Build once, sell to everyone, charge for customization. That is the business model.
What your business actually needs
Not best practices. YOUR practices.
Your approval chain. Your receiving logic. Your production stages. Your QC gates. Your contractor settlement formula. Your vendor consolidation rules. Your size system. Your dispatch constraints.
These are not "customizations." They are the business. (Module-based vs SG Schema architecture, in detail The ERP's job is to model them, not to override them with a generic default.
When an ERP vendor says "that is not how our system works," what they are really saying is: "we built for the average, and you are not the average."
96% of manufacturers need customization. That is not 96% of manufacturers being difficult. That is 96% of manufacturers having businesses that do not match the vendor's template.
A different approach
Instead of starting with pre-built workflows and modifying them, start with the business itself. Write the SG Schema. Define the entities that exist, the states they live in, the rules that govern them, the chain reactions that fire when something happens.
The output is a complete operational blueprint of YOUR business, not a configured version of someone else's template.
SG Engine reads the SG Schema and generates the application: forms, workflows, validations, dashboards, APIs. No "best practice" to depart from. No customization budget. No gap between what the system does and what the business needs.
Your practices. Your language. Your rules. Specified, not templated.
SimpleGrid does not sell "best practices." We write your SG Schema. Your rules. Your language. Your process.