Businesses Are Different, but Not Everything Needs to Be Rebuilt
At a high level, many businesses look similar. There is a customer. There is something the company sells. There is an order. There is money. There are people who perform the work.
But one level deeper, the differences become significant.
A retailer sells products from stock. A manufacturer may first purchase materials, plan work, produce an item, and only then ship it. A service company may have no product inventory at all, while specialist time, scheduling, delivery stages, and the service result become critical.
A universal system therefore should not mean that every business receives exactly the same workflow.
What Is Often Shared
The names may differ slightly, but these parts appear across very different companies.
Customers and Partners
A company needs to know who it works with, how to contact them, what agreements exist, and what happened before.
Products or Services
Every business has something it sells or delivers, whether that is a physical product, specialist time, or a complex service.
Orders
The company needs to capture what the customer wants, the quantity, price, and current state of the work.
Money
Payments, debts, expenses, amounts, and the financial state of an operation matter across business types.
Documents
Invoices, acts, delivery documents, internal records, and other confirmations follow business operations.
People and Access
Employees have different roles, see different information, and carry different responsibilities.
Analytics
Management needs visibility into operational state, results, problems, and trends.
Change History
For important operations, it should be possible to understand what changed, when, and who performed the action.
| Business Type | Shared Foundation | What Adds Domain Specificity |
|---|---|---|
| Trade | Customers, products, orders, payments, documents | Warehouses, reservations, transfers, returns, available stock |
| Manufacturing | Customers, products, orders, money, documents | Materials, production stages, resources, output, actual consumption |
| Services | Customers, services, orders, payments, documents | Scheduling, specialist time, delivery stages, work result |
Even a concept that looks universal can have different meanings.
A product in trade can exist across several warehouses. In manufacturing, a finished item may depend on materials and pass through several stages. In a service business, the offering may have no inventory at all.
For the customer, however, all three can begin in a similar way: the customer wants something from the company, the company needs to record the request, determine the price, fulfill the obligation, and receive payment.
This is where the idea of a shared foundation becomes useful: do not pretend that workflows are identical, but also do not build every business as a completely separate world.
How I Would Find the Boundary Between Shared and Specific
This should not be decided only by the industry name. The real rules are more useful.
Find the Same Business Concept
If a customer remains the same customer across workflows, there is little value in creating independent copies for every area.
Understand Who Owns the Data
Identify where the authoritative state begins and which other workflows only consume it.
Compare the Rules for Change
If two workflows change data according to fundamentally different rules, that is a signal not to force them into one model.
Separate the Specialized Workflow
Production routing, warehouse reservation, or specialist scheduling can remain separate without duplicating the entire business foundation.
Connect the Result Back to the Shared Foundation
The specialized workflow should still produce understandable business outcomes: an order fulfilled, a product ready, a service completed, or a payment expected.
Do Not Generalize Too Early
If a new business type has no real scenario yet, avoid building a complex abstraction only for a possible future need.
The same principle applies to analytics.
Almost every business needs visibility into orders, payments, debt, customer activity, and results over time.
A manufacturer additionally needs material consumption, production output, and process load. Trade needs stock, turnover, and product availability. A service business may care more about specialist utilization, delivery time, and repeat requests.
Shared analytics can give management one view of the business, while specialized analytics should explain how that particular business creates its result.
This approach also matters when the company itself changes.
A business may begin with trade, later add its own manufacturing, and eventually offer service and maintenance. If every direction lives in a completely separate system, customers, documents, permissions, and analytics begin to diverge again.
With a stable shared foundation, a new direction does not necessarily require another independent information system.
But the opposite extreme should also be avoided: a new business activity needs its own rules where the existing rules no longer fit.
A Few Questions About Shared Foundations and Business Specificity
Generality is useful only when it does not erase the real differences between workflows.
Does a shared foundation mean every company needs the same modules?
What can manufacturing and services really share?
Why not use one extremely flexible table with any fields?
When does separate logic become necessary?
Can new business directions be added gradually?
Does this mean AVN Center already supports all of these scenarios?
AVN Center: From Business Needs to Product
This series gradually moves from individual business problems toward the question of how a system can preserve a shared foundation without erasing the specifics of real work.
A Shared Foundation Should Help the Business Grow, Not Limit It
I see AVN Center as an environment where basic business capabilities do not need to be rebuilt for every workflow, while manufacturing, trade, services, and other directions can gain their own logic where real operations require it.
