Every ERP records what happened. Almost none records how it happened. The order is in the system; the conversation that gave rise to that order, the promise made, the drawing sent, the objection raised, and the decision taken are elsewhere —
often nowhere at all. This section explains why Minerva closes this gap not with an add-on, but with the architecture itself.
Let us look at an order record entered three years ago. It sits complete in the system:
Order record — 2024
Customer: Example Industries Inc.
Product: Fastener, 12 mm stainless steel
Quantity: 4,000 pcs
Unit price: 18.50
Discount: 12 percent
Delivery: 45 days
The record is accurate, complete, and auditable. Now the questions being asked today: Why did this discount end up at 12, and who approved it?How was 45 days accepted, when our standard was 30 days?Was a special promise made about packaging?Did the customer object afterwards, and if so, how was it resolved?
The record answers none of these questions. Because the record is not the process itself, but the residue the process left behind. The process took place between people:
a phone call, three e-mails, a meeting, a technical drawing, and verbal approval obtained twice. Only the result was written into the system.
Visible in the system
Order lines and amounts
Delivery date
Discount rate
The user who entered the record
The subsequent delivery note and invoice
Not visible in the system
In which conversation the price was set
Who approved the 45 days
Which revision of the technical drawing was sent
The customer’s packaging request and the promise made
The production capacity concern discussed within the internal team
The complaint that came after delivery and how it was resolved
Why an exception was made for this customer
Your company’s most expensive decisions are made where your system does not record them.
This is not the result of using a bad ERP. The classic ERP architecture was designed to do exactly this: to record structured transactions without error.
It is extremely successful at this design goal. The problem is that a very large part of an enterprise’s knowledge is unstructured — it lives in conversations, documents, notes, and promises.
Corporate amnesia: how is knowledge lost?
Companies forget. This forgetting is not random; it happens through four regular and predictable channels.
1. When a person leaves
When a sales representative leaves, the order records they left in the system remain; the knowledge of the relationship they built with the customer does not leave, it ceases to exist. What the customer is sensitive about, who was
promised what, how last year’s tension was defused — none of this is in any file.
2. When time passes
Even if the person stays with the company, they do not remember. The rationale for an exception made two years ago is not in the mind of the person who granted it, either. An organization’s memory is only as good as its employees’ memory — and human memory is short.
3. At the system boundary
The information is actually there, but it cannot be reached. The correspondence is in someone’s mailbox, the drawing on the shared drive, the complaint in the ticketing system. All three exist; none of them
is next to the order. Information that exists but cannot be accessed produces the same result as information that does not exist.
4. Because it was never recorded
This is the most insidious one. If keeping a record requires switching screens, it does not get kept on a busy day. An unused document system is not bad — it is simply empty.
The greatest enemy of record-keeping discipline is not unwillingness but friction.
Of these four, the third is the one that receives the most investment: organizations buy search tools, portals, and data warehouses to find information. Yet as long as the fourth channel remains open
— that is, if the information is not being recorded in the first place — no search tool is of any use. There is nothing to search for.
Shadow systems: where does context go?
Context is never actually lost. It simply moves to places the organization does not control. In every enterprise, there is a shadow infrastructure quietly operating alongside the official system. Nobody set it up; it formed on its own.
Personal mailbox
Most customer commitments are here. It closes when the person leaves.
Instant messaging groups
Where daily decisions are made. Not searchable, not corporate.
Where everything the system does not keep is tracked.
Printed files and notebooks
Notes taken in meetings, shared with no one.
The memory of the experienced employee
The most critical and most fragile storage medium.
The common feature of shadow systems is this: none of them is backed up, none of them is audited, none of them is handed over. The company’s most valuable knowledge is kept in the least protected place.
This is not a discipline problem; employees do not behave this way because they are malicious or lazy. They find another place because the official system does not accept that information.
A shadow system is not a trick users play against the system. It is proof of a need the system does not meet.
Count how many WhatsApp groups there are in your company. Each one is the address of a conversation your system does not keep.
Object-centric architecture
There are two ways of organizing information, and the difference between them is the distinction on which this entire page rests.
Application-centric
Information is filed according to the tool that produced it.
E-mails in the mail system, files in the document system, calls in the ticketing system, tasks in the work tracking tool.
To see everything about a topic, you query four applications separately — and first you have to know that there is something there.
Object-centric
Information is filed according to what it is about.
E-mail, document, call, task, and meeting note — all sit on the customer, product, order, or project they belong to.
To see everything about a topic, you open that topic. There is a single address: the object itself.
The human mind already works object-centrically. Nobody thinks in terms of “the information in Outlook”; they think of “the Example Industries job.” Application-centric architecture places a translation layer between the way people naturally think
and the way software files things. The user performs that translation every time — and usually performs it incompletely.
In Minerva, all of the components described on this page are designed at the center of the system. This has a single technical consequence: every component can be linked to every business object in the system.
Information you do not have to search for
This is the least discussed but most important consequence of object-centric architecture.
To be able to search, you first have to suspect that there is something to search for. If you do not suspect that there may be past correspondence about an order, you never
search for that correspondence. Even the best search engine cannot answer a question that is not asked.
In the application-centric world, reaching information requires a hypothesis. In the object-centric world, the information is already there.
Findability
The user suspects, chooses the right system, types the right keyword, and evaluates the result.
If there is an error in any one of the four steps, the information is not found — and the user assumes the information does not exist.
Encounterability
The user opens the order; the related correspondence, documents, open requests, and past calls are already there.
No guessing is required. You also see what you were not looking for but needed to know.
The Most Dangerous Information
Is the information you assume does not exist. Walking into a reconciliation meeting with a customer unaware of the promise your colleague made three months ago — is not a search problem, it is an architecture problem.
The 360-degree view fallacy
In the industry, the “360-degree customer view” is usually sold as a dedicated screen. Yet the need for a dedicated screen is proof that the data is scattered. True unification does not mean going to a separate panel; it means that wherever you look from,
everything related is right there.
The four memories of an organization
Rather than listing Minerva’s central components as a feature list, it is more meaningful to group them by what they protect. An organization has four kinds of memory, and all four are lost separately.
1. Document memory
What did we produce, what did we send, which version was it?
Digital Asset and Document Management
Every kind of digital asset is kept in the system: images, PDF, HTML and XML documents, text, technical drawings, icons. As preferred, they are stored in BLOB fields in the database or as
physical files. Directories are defined and authorized; detailed permissions can be granted for each file. Document versions are kept and tracked.
The importance of version tracking is not technical but legal. The question “Which revision did we send the customer?” is as decisive in a dispute as the contract itself.
Knowing the latest state of the file is not enough; you need to know the state that was sent on that day.
When it is lost:
Which drawing the product was manufactured to becomes disputed. The same document circulates in multiple places in different versions. It is not known who accessed which document.
2. Conversation memory
What did we promise, what did we discuss, why did we decide that way?
E-Mail System
Once the system is configured, all mail can be sent and received through Minerva. Even if your traffic runs through another service, the mail can be transferred into Minerva; in this way it is linked to customer, supplier, and personnel records
and becomes an integrated part of the system. Within the defined hierarchical authorization framework, all non-personal e-mails become visible.
We would like to point out a contradiction here. E-mail is the organization’s most binding communication channel: quotations, acceptances, notices, and commitments pass through it.
And yet, in most companies, it is the least managed infrastructure. Legally corporate, in practice personal. This contradiction is invoiced one day without fail.
Personal Messaging
Every user can send an in-system message to another user or a user group. The difference is not speed but place: the conversation stays where the work happens. When an order’s special delivery condition is discussed between sales and
logistics, that conversation sits next to the order three months later.
Meeting Management
Participants in full detail, the agenda with its discussions and conclusions, and the meeting minutes with their distribution are all recorded.
What is critical in a meeting record is not the decision, but the rationale for the decision. Knowing the decision is enough for you to defend or cancel it. But when circumstances
change, to understand whether the decision is still valid you need to know the discussion that gave rise to it. A decision whose rationale has been lost is either a dogma or a rule that gets broken unnecessarily.
When it is lost:
The same topic is debated anew every year. Promises made surface only when the other party reminds you. The history of the customer relationship leaves along with the departing employee.
3. Action memory
Who did what, who will do what, where did we go?
Tasks and To-Dos
Completed Work
Corporate Activities
Tasks assigned to individuals and the work done by any user or person are kept in full detail. A task acquires its context when it is tied to a business object: a task tied to an order is also visible from the order’s screen.
On the corporate activities side, trade fairs, trips, presentations, sports and arts events are managed in the system. This has a more concrete payoff than it seems at first glance: in most companies, the marketing budget is the
last budget item whose return cannot be measured. It cannot be measured because there is no lasting link between the cause (the conversation held at the fair) and the effect (the order that arrives eight months later). When the event is a business object, that link can be made: contacts, quotations,
orders, and expenses are tied to the same record.
When it is lost:
Where the work stands can only be learned by asking. Handover is left to verbal transfer. Event investment is repeated every year on faith, not on measurement.
A warning
The purpose of the activity record is not to monitor employees but to know where the work stands. Software cannot protect this distinction; corporate culture does. In companies that turn the system into a surveillance tool, record quality drops rapidly,
because people start avoiding keeping records.
4. Friction memory
What went wrong, who complained, is it recurring?
Work and Request Management
Call Center System
All users, within their authorization, can create work and request records and track their outcome. All records can be linked to any kind of business object in the system: order, delivery note, invoice, production work order, project, and others.
All calls coming from customers, suppliers, personnel, and every kind of business partner are kept in the system, managed, and their outcomes tracked. All calls can be linked to all transactions in the system.
The most valuable use of this link emerges not in customer service but in quality. If calls are linked to production work orders, a concentration of complaints about products from a particular batch becomes visible on its own.
In separate systems, this link is made only if someone notices — usually far too late.
When it is lost:
The same error recurs across different customers, and its recurrence goes unnoticed. Complaints are resolved one by one; the root cause is never found. The cost of quality cannot be calculated.
Why can it not be added later?
A reasonable objection: “There are products on the market for all of these; we will integrate them.” Partly true. But two things cannot be carried over through integration.
Identity space
Two systems can send data to each other, but they cannot share a common identity space. The “Example Industries” in the document system and the “Example Industries” in the ERP
are two separate records; there is a mapping table between them. Mapping is a living thing: company names change, mergers happen, new branches open. With every change the mapping breaks, and someone repairs it. This is not a job that ends but one that goes on.
In a central model, on the other hand, there are no two records to be mapped. There is a single record, referenced from different places.
Authorization model
This is a more serious matter. Every system has its own authorization logic, and these do not map one-to-one. Over time, this situation arises: a user can open in the document system the contract of a customer they cannot see in the ERP. Nobody designed this;
it arises from the two models evolving at different speeds.
In Minerva, authorization is defined in one place. Files, e-mail, calls, and business data use the same authorization model — because they are in the same system.
Integration is two systems sending each other copies. Unification is a single record being seen from everywhere. Wherever there is a copy, there is always the question “which one is correct?”
and answering that question is a permanent job.
Integration and unification are not the same thing
These two words are used interchangeably in marketing copy. Technically they are not the same thing, and the difference directly affects your purchasing decision.
Criterion
Integration
Unification
Data
Copied, sits in two places
A single record, referenced from many places
Currency
Delay dependent on transfer frequency
No concept of delay
Consistency
Divergence over time is inevitable
No second copy to diverge
Authorization
Separate in each system, hard to reconcile
A single model, valid in every component
Version upgrades
Every bridge is retested
One system, one version
Cost structure
Setup plus ongoing maintenance
No additional maintenance item
Failure mode
When the connection breaks, data is missing, usually silently
There is no such component as a connection
The most common mistake in integration projects is assuming the cost is one-off. Integration is not an installation but a lifelong maintenance obligation.
When either side moves to a new version, the invoice arrives again — and over the years it usually exceeds the total initial setup budget.
The only asset that gains value over time
Almost everything a company buys loses value over time. Hardware ages, licenses fall behind on versions, vehicles depreciate. The context archive is the exception: it becomes more valuable with every passing year.
This needs to be said honestly, because it has a consequence:
Year one. The archive is almost empty. Users keep records
and see little in return. During this period the system feels like a burden. Let us be honest:
it is one, too.
Year two. The first returns begin. The sentence “we discussed this last year”
is now met with a record.
After year three. The system becomes the primary source of what the organization
knows about itself. Departing personnel are no longer a critical risk.
After year five. A new employee starts the job not by having someone explain it to them,
but by reading. This is the concrete definition of institutionalization.
This is why the worst timing for this investment is “we will do it when we need it.” A context archive cannot be built retroactively. You cannot record a conversation that was not recorded after the fact.
The same reasoning does not require you to roll out these components from day one. Most organizations start with the document and request side; e-mail and calls come in a later phase.
Because the components are already at the center, rolling them out later does not mean a new integration project — it is merely a configuration step.
The counterargument: composable ERP
The argument on this page has a serious opponent, and rather than hide it, we prefer to put it in front of you.
In recent years, Gartner has argued for exactly the opposite direction: (cite index="28-1">moving away from monolithic ERP strategies toward modular, best-of-breed solutions,
thereby adopting new functionality faster and reducing technology risk. The rationale is not to be dismissed either: (cite index="32-1">no ERP package vendor
has best-in-class capability in every area; standardizing on a single package may require compromises.
This criticism is valid, and we say the same thing. Minerva’s document component does not have every feature of a specialist ECM product that does nothing but document management.
The call component does not offer every capability of dedicated platforms designed for large-scale call centers. We do not claim that it does.
The side of the debate that gets skipped
The comparison is usually made over a feature list. Yet unification is also a capability, and it appears on no feature list.
The cost of a feature you do not use in a specialist product is zero; the cost of the context lost every day accrues continuously.
The same sources also acknowledge the challenges of the composable approach: (cite index="33-1">the idea of combining numerous applications, multiple clouds, and various services
offers great opportunity, but in reality brings a variety of challenges that must be overcome. The real names of these challenges are: integration
development, data consistency, federated authorization management, and total cost of ownership.
The real distinction: scale
The composable approach makes sense for organizations that can sustain their own integration team. If you have a permanent architecture team, an API management layer, and
a data governance discipline, combining the best pieces is a truly superior strategy.
A mid-sized enterprise does not have that team. Integration is bought from outside, invoiced again with every release, and usually left unmaintained when the person who wrote it
leaves. At this scale, the “best-of-breed” strategy usually turns into the best pieces combined in the worst way.
The door is not closed. Minerva is an open system. If you truly need a specialist product in a given area, you can integrate it. The difference is this: you do it
because you choose to, not because you have to. The default state is unification; separation is a deliberate decision.
When is this approach not the right one?
A vendor who says the same thing to every customer cannot be trusted. There are also situations in which this approach is not appropriate.
If you depend on a highly specialized product in its field
If you have a call center that requires thousands of simultaneous calls, advanced IVR, speech analytics, and workforce optimization, a specialist platform is the right choice for that area.
In that case, Minerva works integrated with that platform; call data continues to be linked to business data.
If your group standard is locked in
If headquarters mandates a particular document or communication platform, the discussion is corporate, not technical, and cannot be won with a technical argument.
Minerva can work alongside these platforms; using its own components is not mandatory.
If the corporate culture is closed to record-keeping
In a culture where sharing information is considered a loss of power, no system can accumulate context. The tool does not change the culture.
In that case, it is more realistic to start in a narrow area — for example, only in technical documentation — and demonstrate concrete benefit.
If you need only a single component
If you are looking for document management alone, there is no justification for buying a business management system.
The value of these components emerges when they work together and in relation to business data.
10 questions for your own organization
Rather than letting a web page convince you, it is healthier to decide by looking at your own organization. Try answering the questions below with your current system.
Context loss self-assessment
For each question: do you get the answer from the system, or by asking someone?
Why is the discount rate you give your largest customer that particular rate? Who made the decision, when, and on what grounds?
Can you access today the last six months of correspondence between a sales representative who left last year and their customer?
Can you say which revision of the technical drawing you last sent to a customer, together with the date it was sent?
Can you calculate how many conversations, how many quotations, and how many orders resulted from the last trade fair you attended?
Can you see whether there is a concentration of complaints about products from a particular production batch?
Can you read today the rationale for a decision taken in a meeting six months ago?
Can you see on a single screen how many times and on which topics a customer has contacted you?
Do you know where the internal correspondence about an order is? What happens if that person is on leave?
How many work-related messaging groups are there in your company? Is their content held by the organization or by individuals?
Can a new hire learn the history of the customer portfolio they have taken over by reading it?
If you answer most of these questions “by asking someone,” it means your organization’s memory is held by individuals, not in the system. This is the result not of poor management, but of a widespread architecture.
Summary comparison
Topic
ERP plus separate products
Minerva
Organizing principle
Application-centric: information is filed by the tool that produced it
Object-centric: information is filed by what it is about
Reaching information
Requires searching; searching first requires suspecting
Related information is already visible on the object
Identity
A separate record in each system, with a mapping table between them
A single record, referenced from many places
Authorization
A separate model in each product; diverges over time
A single model, valid across all components
Document memory
On a separate platform; version tracking managed separately
On every related transaction screen, together with its version
Conversation memory
Personal mailboxes and messaging groups
Linked to business partner and transaction records, under hierarchical authorization
Action memory
Separate work tracking tool; weak link to business data
Tasks and completed work tied to the related business object
Friction memory
A single undifferentiated record pool in the ticketing system
Five separate types; tied to orders, delivery notes, and work orders
Version upgrades
Every bridge is retested
One system, one version
Over time
Context scatters into shadow systems
The archive accumulates; corporate memory grows stronger
The work itself is in the system; but where is the story of the work?
An order has a record in the system. But the conversation that gave rise to that order, the drawing that was sent, the delivery concern discussed with the internal team, the complaint that came later, and the promise that was made —
in most organizations these sit elsewhere. In personal mailboxes, in messaging groups, in desktop folders, and in the memory of experienced employees.
None of these is backed up, audited, or handed over. Your company’s most valuable knowledge sits in the least protected place.
Minerva does not separate these two. If you would like to discuss where to start, a good opening question is this: last month, whom did you ask most often in order to find a piece of information?
The answer tells you where your corporate memory is held.