Every business management system has a single fundamental function: to model real business life on a computer. How much benefit a system will bring you depends, before its interface or its number of modules,
on how closely this model approximates reality. Most of the differences that set Minerva apart from other systems originate precisely in this modeling layer.
All business management systems in the world do the same job: they translate the real-life company, its people, goods, locations, and processes into a data model. Modeling is the effort to approximate
reality as closely as possible — and every model has a degree of approximation.
There is a two-way balancing problem here. If the system is built with too few parameters, its ability to reflect reality diminishes; the enterprise cannot find itself in the system. If it is built with too many parameters,
it comes closer to reality, but deploying and operating the system becomes difficult.
The critical point is this: the number of parameters alone is not decisive. Whether the parameters are chosen correctly or incorrectly directly affects the success of the model. With the same number of parameters,
it is possible to build systems that are both far from reality and quite close to it.
It Didn't Fit Us
The most common reason an ERP project ends with "it didn't fit us" is not a missing function, but a model that cannot describe the enterprise as it is. Functions can be added; the model, however, is the deepest layer of the system and cannot be changed afterwards.
Minerva's approach
We have been serving the business world since 1987. The principles that nearly 40 years of software development experience have taught us are these:
To base modeling and system design on the customer's business environment and requirements, not on the product's assumptions.
To understand universal business approaches correctly, in order to build the right model and make value-creating recommendations.
To map requests to functional concepts while building the system with an integrated and relational approach.
To choose technologies that are fit for purpose, cost-effective, easy to use, and future-oriented.
To work in a focused and disciplined manner, without forgetting that the work has a side that relies on creativity.
Where does the classic ERP model get stuck?
The majority of ERP systems on the market model the enterprise through four concepts: customer, supplier, inventory, and warehouse. This pattern was a reasonable abstraction for the manufacturing and distribution
companies of the 1980s. Today's enterprise, however, does not fit into these four boxes.
The typical bottlenecks this model produces:
Duplicate records for the same party. If a company is both your customer and your supplier, two separate records; if you work in different currencies, one more record for each currency.
No place for goods you do not own. Goods held in custody, consignment goods, rented equipment, competitor products — because they do not fall under the definition of an "inventory item," they are either not tracked at all or imitated with fake inventory records.
Location = warehouse. Real locations such as rooms, floors, buildings, tanks, silos, field vehicles, and production work centers are squeezed into warehouse / storage-bin fields.
Organization = a single hierarchy. The management structure, physical layout, and sales organization are usually merged into a single tree; when one changes, the others break.
Repetition across group companies. The same customer, the same product, the same personnel are redefined in every company; consolidation is left to manual matching.
The result
When the enterprise does not fit the system, the gap is closed — but with Excel files, notes typed into description fields, meanings buried inside codes, and the sentence "we track this outside
the system." This cost does not appear on an invoice; it is paid again and again every month.
Minerva's five fundamental elements
Minerva models the enterprise not through the customer–supplier–inventory–warehouse pattern, but through its real-life counterparts. There are five elements at the core of the system:
Persons — all individuals the company interacts with.
Organizations — all companies and institutions interacted with.
Objects — including products, raw materials, assets, services, and everything you do not own.
Physical Locations / Organizations — the enterprise's layout and logistics structure.
Management Organizations — the company's managerial and operational structures.
Where the difference lies
The difference here is not a naming preference. Customer, supplier, bank, competitor, employee are not entity types, but roles. Minerva places this distinction at the very bottom of the data model:
first the identity is defined, then roles are added on top of the identity.
Minerva Enterprise Business Modeling
Central definitions, the company layer, and mutually independent organizational structures
Central System
Persons
Organizations
Objects / Items
Services
Premises and Logistics Organizations
Business Area Organization
Management Organizations
User Organizations
Business Parameters
Corporate Organization
Roles and records at the company level
Company
Sites - Branches
Customers
Suppliers
Personnel
Other Business Partners [Organization / Person]
Products
Services
Assets
All Auxiliary Objects
Premises and Logistics Organization Relationships
Business Area Organization Relationships
Management Organization Relationships
An important difference
The organizational layers are not dependent on one another. When your management structure changes, your warehouse structure is unaffected; when your sales organization changes, none of your past or future transactions are affected.
Corporate groups and the central system
Minerva is designed not only for single companies but for corporate group operations. A corporate group consists of parent and subsidiary companies that, while legally independent, operate like a single economic entity
under a common source of control. Minerva models this structure directly.
The master information for organizations, persons, products, and objects is defined only once in the central system. All companies in the group make use of the same record. Company-specific information about the same party or
the same product, on the other hand, is kept separately in each company.
The classic approach
Each company defines its own customer, supplier, and product records separately.
The same firm's code differs from company to company; consolidation requires mapping tables and manual checks.
When an address or tax detail changes, the update is repeated in every company.
Minerva
The person, organization, and object master record is created once at the center and transferred to the relevant companies.
Because there is a single identity across the group, the consolidated view needs no mapping.
Central information is updated from a single point; company-specific terms remain separate at the company level.
What this means in practice
What this means in practice: across your group companies, you can see your shared customer portfolio, your shared supplier risks, and your shared product structure in real time — without having to purchase a separate master data management (MDM) product to do so.
Business partners: identity, not role
In Minerva, business partners are classified not as customers and suppliers, but as persons and organizations. Customer, supplier, employee, bank, competitor, contact person — all of these are roles that the same identity can assume.
Central System Standard Business Partner Types
Business Partner
Group Company
Group Company Site
Tax Administration
Tax Office
Social Security Institution
Social Security Branch
Customs Administration
Customs Gate
Bank
Bank Branch
Stock Exchange
Company & Organization Business Partner Roles
Address - Contact
Customer
Supplier
Business Partner Branch
Job Candidate
Personnel Personnel
Medical Customer
Student
Bank
Bank Branch
Tax Authority
Tax Office
Social Security Institution
Social Security Institution
Customs Gate
Customs Administration
Group Company
Group Company Site
Our Company
Our Company Site
Company & Organization Financial Account Types
Current Account
Project - Contract
Retail Customer
E-Commerce Customer
Our Site
Supplier
Personnel Current Account
Social Security Site Account
Tax Account
Customs Gate Account
Bank Commercial Deposit Account
Bank Time Deposit Account
Bank Cash Loan Account
Bank Installment Loan Account
Bank Direct Debit System (DBS) Loan Account
Bank Non-Cash Loan Account
Credit Card POS Account
Cheques Under Collection at Bank
Cheques Held as Collateral at Bank
Notes Under Collection at Bank
Notes Held as Collateral at Bank
Cheques Receivable
Bounced Cheques Receivable
Cheques Payable
Notes Receivable
Dishonored Notes Receivable
Notes Payable Account
Credit Card Account
Why is this distinction necessary?
An organization that is a customer of group company A may be a supplier of group company B.
A person or organization may be both a supplier and a customer of the same company.
In reality there is a single party; keeping duplicate records for the same party is unnecessary.
For this reason, the master record for the relevant person or organization is created once in the central system; it is then transferred to the company system with the role of customer, supplier, etc. All information at the center is carried over to the company system in full.
Duplicate records are not merely a data cleansing problem. Credit limits, risk tracking, account reconciliation, discount policies, and customer profitability analyses all depend on the party being gathered under a single identity.
Financial accounts and multi-currency
You may need to work with a supplier or customer in more than one currency. In most ERP systems there is only one way to do this: opening
a separate customer / supplier record for each currency you work in. The reason is that in the classic approach, financial accounts are held directly on the master record.
In Minerva, these are two separate concepts. In reality there is a single customer; the financial account is a structure created to group transactions according to predefined criteria — for example, by business partner type and currency.
Multiple financial accounts can be defined on a single master record.
Separate financial accounts are opened for different currencies; the master record is one.
When a customer master record is created, the system automatically opens a financial account of the customer type.
An additional account with the financial account type "supplier" can be defined on the same record; in this way, both the customer and the supplier relationship are managed with two accounts on a single record.
The classic approach
If you work with ABC Inc. in TRY, EUR, and USD, and the firm is also your supplier: 6 separate records.
For total risk, the balances of six records are added up by hand; offsetting is carried out manually.
Minerva
A single master record for ABC Inc.; beneath it, currency-based financial accounts of the customer and supplier types.
Total risk, reconciliation, and offsetting are seen naturally through a single identity.
This section also forms the basis of the topic "Real Transaction-Based Multi-Currency Management." Multi-currency must be solved at the model level, not by multiplying records.
Objects: not just inventory
In Minerva, records can be kept not only for inventory but for every kind of object. Alongside product, raw material, and fixed asset records, assets that do not belong to your enterprise are also
included in the system: objects held in custody, consignment products, items rented from outside, and even competitor products.
Records can be created in the central system and then transferred to the companies.
Central System Standard Object Types
General
Chemical
Land Vehicle
Marine Vessel
Vehicle Tire
Real Estate
Apparel
Service
Transport Unit
Biological Sample
Biological Product
Company & Organization Standard Object Roles
Trade Goods
Finished Product Finished Product
Semi-Finished Product (WIP)
Raw Material
Material
Phantom
Spare Part
Asset - Fixed Asset
Asset - Transport Unit
Asset - Rented / In Custody
Serviced Products
Competitor Product
Information
Service
These definitions are not a closed list; new object types can always be added in Minerva.
Why should "competitor product" be an object type?
Because if you want to perform market share, price comparison, and lost sales analyses, the competitor product must have a real record in the system — not a name typed into a free-text field.
Physical Locations and the Logistics Organization
In Minerva, organizations are created to define physical locations and to reflect the enterprise's logistics structure in the system. Multiple organizations can be set up
as needed, and the locations within an organization can be modeled at whatever level of detail you require: units, work centers, warehouses, and more.
If you operate at a location that does not belong to you — equipment on a customer's premises, a third-party warehouse, a construction site — you can create a separate organization to track your assets at this location, which lies entirely outside your own organization.
Main unit types
Organization Group
Premises Unit
Warehouse
Store
Production Work Center
Mobile Unit / Fleet Object
Tank – Silo
Linear Location
Geographic Area
Complex
Building
Detail unit types
Apartment
Section
Room
Corridor
Office
Open-Plan Office
Executive Office
Meeting Room
Reception
Restaurant
Sports Facility
Production Facility
Production Department
Production Work Center
Warehouse / Warehouse Storage Location
Tank – Silo / Compartment
Store / Store Section / Shelf
Classroom
Garden, Open Area, Parking Lot
Construction Site
Warehouse unit types
Organizational Unit
Bulk Storage Area
Staging Area
Picking Area
High-Rack Area
Storage Bin
Wire Basket
Door
New unit types can always be added in Minerva.
Where is the difference?
In classic ERPs, this level of detail usually requires a separate warehouse management system (WMS) and a separate facility / asset management system (IWMS, CAFM). In Minerva, a single location model
carries the storage bin, the meeting room, and the field vehicle within the same structure.
Management organizations
Management organizations are created to reflect the enterprise's organizational structure in the system. Organizational units and the persons responsible for these units
are added to these structures; teams can be assigned to units.
Multiple management organizations can be defined as needed. This means being able to keep today's structure and the target structure side by side, or managing the legal organization and the actual reporting line separately.
The management structure is one of the most frequently changing components of an enterprise. For this reason, in Minerva the management organization is a layer independent of the physical layout and the accounting structure.
When departments merge, you do not need to rebuild your inventory structure.
Departments and operational organizations
Alongside the management structure, the operational organizations in which the work is actually carried out are also modeled separately. The operational organizations that can currently be created in the system:
Operational organizations
Sales Organization
Procurement Organization
Service Organization
In Minerva, an operational organization is defined using the following components:
Operational organization components
Geographic Regions
Business Channels
Business Units
Business Partner Segmentations
New operational organization types can always be added in Minerva.
Once these components are defined, all reporting, from sales targets to commission calculation and from region-based profitability to channel analysis, runs on the same structure. When a region boundary or channel definition changes, the reports are not rewritten.
What changes in practice?
Modeling seems like an abstract subject. The situations below are the concrete counterparts we encounter most often in the field.
The same firm is both customer and supplier
In the classic system, two separate records, two separate balances, manual work for offsetting.
In Minerva, a single identity, two financial accounts. Total risk and offsetting are visible on a single screen.
A supplier you work with in three currencies
In the classic system, a separate record for each currency; because the risk limit is defined per record, the total risk is visible nowhere.
In Minerva, the master record is one; currency-based financial accounts are gathered under a single identity.
Your devices on the customer's premises
In the classic system, because they are "not our warehouse," they are either not tracked or imitated with fake warehouse records.
In Minerva, a separate location organization is defined outside your own organization; the device is tracked at its real location.
Consignment goods and goods in custody
In the classic system, because ownership and physical presence cannot be separated, inventory valuation is distorted.
In Minerva, thanks to the object type distinction, goods you do not own are tracked in inventory under a separate status.
A departmental merger or regional change
In the classic system, because the organization is a single tree, the change corrupts historical data; comparative reports cannot be produced.
In Minerva, the management, premises, and operational organizations are separate layers; when one changes, the others are preserved.
A shared customer across group companies
In the classic system, a separate record in each company; the group total can only be produced in Excel.
In Minerva, thanks to the central identity, portfolio, risk, and profitability are reported directly at the group level.
A single master record, currency-based financial accounts
Goods you do not own
Usually cannot be modeled; imitated with workarounds
In custody, consignment, rented, competitor product — each with its own object type
Physical location
Limited to warehouse and storage location
Building, room, storage bin, tank, silo, field vehicle; at the desired level of detail
Organizational structure
A single hierarchy; changes corrupt history
Management, premises, business area, and user organizations in separate layers
Group companies
Redefinition in every company, manual matching
Central definition, company-specific information kept separately; a natural consolidated view
Need for a new type
Development or waiting for a release
New object, unit, and organization types can always be added to the system
The accuracy of the model determines the lifespan of the system
You use a business management system for five years, ten years. During this time your product range changes, you acquire companies, you expand into a new country, you restructure your organization.
Whether the system can keep pace with these depends on the modeling decisions made on day one.
Minerva's new-generation business modeling treats these changes as the normal operation of the system — not as exceptions. If you would like to see how your own enterprise
would be reflected in this model, let's work through it together using your current structure.