Adaptable & Programmable System
The question usually asked when choosing software is: “Does this system fit us?” Yet the answer to this question concerns only the first day of the ten years you will use the system. The real question is harder and rarely asked: “How much will it cost to change the part that does not fit — today, and at every version upgrade?” This page explains how Minerva answers this second question.
On This Page- The wrong question: does this software fit us?
- The industry’s fundamental paradox
- Why does custom software rot?
- The right criterion: the cost of change
- Where the invoice arrives: the version upgrade
- The adaptation ladder: seven layers
- Layer 1: parametric structure
- Layer 2: user-defined fields and tagging
- Layer 3: reports and dashboards
- Layer 4: form and label design
- Layer 5: customer-specific triggers
- Layer 6: additional modules and the open platform
- Layer 7: the industry core
- Who adapts? The matter of waiting time
- Adaptation governance
- When should you not adapt?
- Eight questions to ask your vendor
- Summary comparison
- Conclusion
The wrong question: Does this software fit us?
This question treats fit as if it were binary: it fits or it does not. In reality, fit is not binary but layered. When you break down an enterprise’s requirements, roughly the following picture emerges.
The breakdown of requirements
The proportions vary by industry; the structure does notThe classic mistake made in the industry is this: the entire strategy is determined by looking at the smallest slice. Because of the five percent of unique needs, a decision is made to develop software from scratch; or, conversely, that five percent is ignored, a rigid standard package is adopted, and the enterprise spends years trying to fit itself to the software.
The right question
Not “does this software fit us,” but “from which layer, by whom, and in how much time can the part that does not fit be closed.”
The industry’s fundamental paradox
Application programs like Minerva are designed to be used in many industries and in many different fields. This requires the developer to adhere to standardization and to produce general-purpose systems. Companies, however, demand systems specific to their industry, or even developed solely for themselves.
This demand is uneconomical for three reasons:
- Developing a custom system for the requirements of a single company takes a very long time.
- The need for qualified project personnel and a long timeframe creates an expensive structure.
- After the project ends, the costs of updates, maintenance, support, and adaptation to new technologies are very high.
This is where the industry’s fundamental paradox arises. Either you buy standard software that is far from meeting your requirements but is economical and quick to implement; or you develop a costly custom program that will take a long time. You are on the threshold of a dilemma.
Rigid standard package
Quick to deploy, predictable cost, maintenance handled by the vendor.
In return, the enterprise fits itself to the software. For the parts that do not fit, Excel files, side systems, and manually run processes emerge.
Five years later: the system is still there, but a significant part of the business runs outside the system.
Custom software from scratch
Works exactly the way you want — on the day it goes live.
In return, it takes a long time, it is expensive, and by the time it is finished the requirements have already changed.
Five years later: the person who wrote the system has left, the technology is outdated, and nobody dares to change it.
Minerva aims to eliminate this dilemma. In addition to being standard, economical, and quick to implement, it has layers that can be programmed according to your requirements. The rest of this page explains what those layers are and the real cost of each.
Why does custom software rot?
The sentence “custom software is expensive” is true but superficial. The real issue is not the price but the economic structure. Custom software has three structural weaknesses.
An audience of one
In a standard product, hundreds of customers run the same code. If there is a bug, someone finds it and it is fixed for everyone. In custom software, the only one who will find the bug is you — and usually, by the time you find it, the business has already been disrupted.
An unshared modernization cost
Browsers change, operating systems change, database versions are retired, security standards tighten. In a standard product, the cost of this adaptation work is spread across the entire customer base. In custom software, you pay all of it — and usually you do not want to pay, so the system is left to age.
Knowledge held by one or two people
When the person who wrote the custom system leaves, nobody who knows how the system works remains. There is documentation, but it is incomplete; the code is readable, but the reasoning is not written down. From this point on, nobody wants to touch the system. The software technically keeps running, but it stops evolving.
Custom software does not die; it freezes. And a frozen system becomes a little more wrong every year as the enterprise changes.
This does not mean custom development is always wrong. What is wrong is custom-developing the common and variable layers as well. It is clear that writing your accounting engine from scratch will not give you a competitive advantage. Custom development makes sense only where something is truly specific to you.
The right criterion: The cost of change
The most misleading assumption in software selection is that fit is determined once and stays fixed. Yet requirements change constantly: a new product group, a new country, new legislation, an acquired company, a changing customer demand.
This is why the right criterion is not the degree of fit but the cost of change. And the most overlooked component within it is this: is the cost of the fiftieth change the same as the cost of the first?
Rising cost curve
The first adaptation is easy. Each adaptation makes the next one harder.
Changes become entangled; where each rule comes from becomes unclear. Changing one place breaks three others.
Eventually the decision “let’s not touch it” is made, and the system freezes.
Thus, instead of a cleanup operation, continuous hygiene is established.Flat cost curve
Changes are made in separate, defined layers; they do not mix with one another.
A parameter is a parameter, a field is a field, a rule is a rule. Each stays in its own place and can be reverted.
The fiftieth change is as easy as the first.
The technical reason for this distinction is simple, and it is the key to the rest of the page: where you put a change matters more than how long it takes.
Where the invoice arrives: The version upgrade
The real cost of an adaptation is not paid on the day it is made. It is paid again at every version upgrade. The industry has a name for this: technical debt. And its interest is collected at version upgrades.
Let us draw the distinction clearly. There are two kinds of change, and the two are diametrically opposed:
Extension
Makes use of the defined points the product offers you: parameters, fields, reports, forms, defined rules.
The product’s own code does not change. When the new version arrives, your extensions remain as they are.
These are data — and the data is in your tables.
Thus, instead of a cleanup operation, continuous hygiene is established.Modification
Directly changes the product’s standard code or behavior.
When the new version arrives, it conflicts. Either the change is lost, or the version cannot be installed.
The outcome is usually the third: the version is not installed, and the system stays outdated for years.
A parameter’s resilience to upgrades is not a promise, it is a consequence
This is the most important technical sentence on this page. A parameter is data. Data resides not in the product’s code, but in the tables in your database. A version upgrade renews the product’s code, not your data. This is why parametric configuration is unaffected by upgrades — not because someone promised it, but because architecturally it cannot be affected.
The same logic applies to user-defined fields, reports, forms, and defined business rules. All of these are definition records. They are not code.
When a vendor says “we can customize everything,” there is only one question to ask: “What will happen to this change in the next version?” If the answer is not clear, what you are getting is not flexibility but a deferred cost.
The adaptation ladder: Seven layers
Rather than listing Minerva’s adaptation capabilities as a feature list, we present them as a ladder ordered by cost and risk. With each rung of the ladder, power increases; in return, speed decreases, the expertise required rises, and version sensitivity begins.
A single governance rule: Solve every need at the lowest rung at which it can be solved. If a need can be met with a parameter, do not write a trigger; if it can be solved with a user-defined field, do not develop a module. This rule is the single rule that determines the health of the system five years from now.
Parametric configuration
Determining the system’s behavior through definition records, without writing code.
User-defined fields and tagging
Extending the data model according to your own needs.
Reports and dashboards
The read side. It cannot corrupt data, so it is the freest layer.
Form and label design
The presentation layer. Determines the appearance of the output without touching business logic.
Customer-specific triggers
The behavior layer. The most powerful rung, and the one requiring the most care.
Additional module and functionality development
For the five percent that is truly specific to you.
Industry core development
Concepts that belong to the architecture and cannot be programmed by the user.
The sections below open up these seven rungs one by one. In each, you will find both the capability and what to watch out for.
Layer 1: Parametric structure
In Minerva, almost all transactions can be configured by company, business unit, user group, or user. For example, in credit and risk assessment, how the risk is calculated and when and how the risk check is performed are defined entirely parametrically.
In addition, there are Business Management Parameters specific to the work done in the system. These parameters can be defined along the following dimensions:
Dimensions of business management parameters
- The nature of the work
- For which companies
- For which site of the company
- For which users
- For which user roles
Why do these dimensions matter?
In most systems, a parameter is defined globally: a rule is switched on, and it is switched on for everyone. In real life, however, rules are rarely the same for everyone. The approval threshold of the export department differs from the approval threshold of the retail channel. You may want tighter risk control in a newly opened branch. The flexibility granted to an experienced sales manager is not granted to a newcomer.
Being able to define parameters along the dimensions of company, site, user, and role means being able to define the real rule set, rather than managing a single rule through exceptions. Exceptions reside in the system, not in description fields and verbal agreements.
The most overlooked benefit of the parametric layer is not speed but traceability. If a rule is buried in the code, you have to read the code to understand why it is the way it is. If it stands as a parameter, it is visible together with who changed it and when.
Layer 2: User-defined fields and tagging
User-defined field functionality is one of the most fundamental features Minerva offers its users. On all master records — customer, supplier, inventory item, and others — and in all transactions — order, delivery note, invoice, warehouse slip, work order, and others — customer- and industry-specific fields can be defined.
User-defined field types
- Text – Character
- Numeric
- Currency – Amount
- Date
- Date – Time
- Check Box
- Combo Box
- Definable Combo Box
- Note (long text field)
- Web Link – URL
- Formula
The design decision behind the type list
The length of this list is not a feature race. Each type exists to make the data processable later. If you write a delivery date into a text field, you will never be able to answer the question “how many days do delays average.” If you write it into a date field, you can report the answer.
Practical advice:
Wherever possible, use a definable combo box instead of free text. The difference is three seconds at entry and everything at reporting. A piece of information typed into a free-text field — a customer segment, for example — comes back to you three months later in ten different spellings and enters no analysis. Free text keeps notes, not data.
Record tagging
Records can be tagged in various ways (important, unimportant, and the like) or according to user-defined keywords.
Tagging is the lightweight alternative to defining a field, and it serves a different need. A field is for information you know in advance and that must be present on every record. A tag, on the other hand, is for a distinction you did not foresee, that is temporary, or that concerns only some of the records: this year’s risky customers, the items that caused problems in this shipment, the records to be examined in the audit. Opening a field for every new distinction bloats the data model; tagging solves this flexibly.
An honest warning — field entropy:
User-defined fields have a well-known disease. Three years later there are forty fields, half of them are empty, and nobody knows what Custom Field 7 means. This is a problem of governance, not of the software.
The solution is simple and mandatory: give every field a descriptive name, make sure every field has an owner, and review unused fields once a year. In organizations that do not do this, user-defined fields create more confusion than they resolve.
Layer 3: Reports and dashboards
Any kind of report desired can be created in the system. The reporting system has almost all the capabilities of the tools used for this purpose.
Report formats
- Screen (HTML)
- Printer (HTML)
- Extensible Markup Language (XML)
- Comma-Separated Text File (CSV)
Report outputs
- Display on screen
- Download as an Excel file
- Download as a file
- Save as a system document
- Prepare in the background
- Send as e-mail
On the dashboard side, too, any kind of panel can be created in the system. The components on the panel can be filled with lists, charts, or information in any desired format.
Why should the read side be unrestricted?
This layer has a place apart from the others, and the design principle is this: be generous on the read side, disciplined on the write side. A report cannot corrupt data. An incorrectly written report gives an incorrect result, but it does not affect the system and is corrected within seconds. For this reason, there is no technical justification for being restrictive in reporting.
On the other hand, reporting is the single thing that determines a system’s real usage rate. People keep entering data into a system as long as they get an output from that data. A user who cannot get reports also stops keeping records. Reporting flexibility is not a comfort; it is a prerequisite for data quality.
Background preparation and e-mail delivery seem like minor details at first glance; in practice, they determine whether the report gets used. Instead of a dashboard nobody opens, an e-mail that arrives every Monday morning usually does more work. A good report is not one the user has to go to, but one that comes to the user.
Layer 4: Form and label design
The system provides form design capability for all transactions, and more than one form can be designed for each transaction. Ready-made forms from the form library can also be used.
In-system programming: the barcode label example
In Minerva, programming can be done within the system using HTML and Oracle functions. Barcode labels are the most concrete example of this. Label design varies from company to company; moreover, the same company may need ten different label designs for different purposes.
In Minerva, you can design your barcode labels in any size, in any style, and to any standard (EAN and the like) you wish, and add pictures and images to them.
This example seems small, but it is typical. Label design is an area no software vendor can predict in advance — because it depends on your shelving system, your customer’s demands, and the specifications of your machine. Needs of this kind should be solved on site, not by requesting them from the vendor.
The same logic applies to forms. Being able to design more than one form for a transaction means, in practice, that the same order record can be printed differently when it goes to the customer, differently when it goes to the warehouse, and differently when it goes to the archive. You are not condemned to a single output format.
Layer 5: Customer-specific triggers
This is one of the system’s most powerful adaptation features. Triggers can be defined at the database level entirely for customer and industry needs. These triggers allow you to validate the records entered, or manage all the operations that need to be performed before and after a record is saved.
What it means to be at the database level
This detail seems technical, but its consequence lies entirely on the business side. A check defined at the application layer validates only the records that pass through that screen. When data comes in through a bulk load, an interface, or an integration, that check is not activated.
A trigger at the database level, on the other hand, does not care which route the record came by. This is why it is the only control point you can truly rely on. If a business rule must be applied without exception — for example, no shipments to a particular customer group in excess of their credit limit — that rule should be written here.
The same power demands the same degree of care
Be cautious of a vendor who does not say this. Triggers have three known risks:
Invisibility
A trigger runs in the background. A user who encounters unexpected behavior cannot see the reason on the screen. This is why every trigger must be documented and recorded.
Performance
It runs on every write operation. A heavy trigger goes unnoticed when a single record is entered; on a daily load of ten thousand records, it brings the system to a halt.
Accumulation
Triggers added over the years can trigger one another. In year five, the answer to the question “why was this record rejected” may lie in the combination of three separate triggers.
None of these risks requires avoiding triggers. The only thing they require is discipline: a rationale, an owner, and a record for every trigger. We explain how to carry this out in the adaptation governance section.
Layer 6: Additional modules and the open platform
Minerva runs on an Oracle database. You can develop any functionality you wish using HTML, Java, Oracle programming products, Microsoft programming products, or client-server programming products.
Its real value: insurance against lock-in
Reading this item merely as a development feature would be incomplete. Its real meaning is this: your data resides on an open, standard, and documented platform.
When buying enterprise software, the least discussed but most real risk is vendor dependency. Companies change, relationships can break down, vendors change hands. In that case the critical question is: where is my data, and who can reach it?
- If your data is in a closed format or an undocumented structure, you can do nothing without your vendor.
- If your data is in a standard relational database, it can be accessed, migrated, and extended with skills available on the market.
This is not an invitation to stop working with us. On the contrary: staying because you are able to leave is a healthier relationship than staying because you are unable to leave. This is the most honest assurance a vendor can give you.
Project and modification services
You do not have to do every adaptation yourself, and often it is not the right thing to do. Minerva offers services for creating additional functionality and developing projects according to your requirements. In this way, you do not need to buy new software for your new requirements.
The right division of labor is usually as follows: the first four rungs of the ladder should stay with your team — because they need to be fast. On the fifth and sixth rungs, working with the vendor is safer in terms of both version compatibility and continuity of maintenance.
Layer 7: The industry core
Some industry requirements are not of a nature that users can easily program. The definition of size and color for products in the textile industry is the classic example. Fundamental industry functions of this kind must be addressed during system design and built as part of the architecture.
Why is adding a field not enough?
This is important for understanding the limit of the ladder. In textiles, size and color are not attributes of the product — they turn the product into a matrix. A single T-shirt model, with five sizes and six colors, corresponds to thirty separate stock-keeping units.
Every part of the system has to understand this matrix:
- An order line carries not a product, but a size-color distribution.
- Inventory movements are kept at the matrix-cell level, not the product level.
- The price list sometimes varies by product, sometimes by size.
- Production planning, purchasing, and costing work with the same matrix.
A user can add a field to the system. A user cannot add a concept.
A user-defined field carries data. A concept changes the behavior of every module in the system. Projects that confuse the two get stuck in the third month.
Minerva has many industry-specific capabilities and manages multi-industry applications on a single platform. When evaluating a vendor, the right question to ask is this: “Are the fundamental concepts of my industry in the core, or am I expected to imitate them with user-defined fields?” If you are in the second situation, adaptability will not help you.
You can find detailed information about our industry solutions in the Industry Solutionssection.
Who adapts? The matter of waiting time
The most overlooked dimension in the adaptability debate is not technical but organizational: who is able to make the change.
The reason standard software feels rigid is usually not that change is impossible. Change is possible — but it enters a queue: a request is opened, forwarded to the vendor, analyzed, a quotation arrives, it is approved, developed, tested, and released with the next version.
The six-week queue
The sales manager wants to track a new piece of information on the customer record.
A request is opened, a quotation is awaited, the development is queued.
In week three, the manager opens a spreadsheet. When the change arrives, nobody uses it anymore — because the information is already being kept elsewhere.
The ten-minute operation
The same need is met by the key user with a user-defined field.
The information is kept in the system, can be reported, and is seen by everyone.
The spreadsheet is never opened.
This is the very source of the shadow system phenomenon we described in the previous section. Excel files and side solutions are not a trick users play against the system; they are a rational response to waiting time. Nobody waits six weeks; everybody produces a solution in ten minutes.
A system’s real flexibility is measured not by what can be changed, but by how long the change takes. Flexibility that takes six weeks is, in practice, not flexibility.
This is why the first four rungs of the ladder being doable by the key user is not a convenience, but a mechanism that protects data integrity.
Adaptation governance
An adaptable system, when not managed, turns into an unadaptable system. It is unusual for a vendor to say this, but it is necessary: the greatest enemy of flexibility is flexibility used without records.
The four practices we see in long-lived installations are these:
Keep an adaptation log
A one-line record for every parameter change, every user-defined field, and especially every trigger: what, why, who, when.
In year five, the answer to the question “why does this rule exist” will be here. Without this log, no adaptation can be safely removed.
Give every adaptation an owner
A field without an owner is a field nobody fills in. A trigger without an owner is a trigger nobody dares to remove.
Ownership should be given to the department that requested the adaptation — not to IT.
Clean up once a year
Review unused fields, reports that no longer run, and rules whose rationale has disappeared.
A one-hour annual review prevents the confusion of three years later.
Solve at the lowest rung
If a need can be met with a parameter, do not write a trigger. If it can be solved with a user-defined field, do not develop a module.
This single rule determines the health of the system five years from now more than all the others.
When should you not adapt?
This is the most important thing a company selling adaptation capability should say: most of the time, the best adaptation is no adaptation at all.
To preserve a bad process
If a process has no counterpart in the system, the first question should be not “how do we adapt” but “why is this process the way it is.”
The standard flow is an accumulation of experience tested in hundreds of organizations. When you pay to change it, you are often paying to preserve a bad habit.
For a single person’s habit
Adaptations made on the grounds that “Mr. Ahmet is used to seeing it this way” remain in the system after Mr. Ahmet has left, and nobody knows why they are there.
An adaptation request should come from the process, not from a person.
For a need not yet understood
A significant proportion of the adaptation requests that arrive in the first months of an implementation project stem from the standard operation not yet having been learned.
Practical rule: record the requests of the first three months, but do not implement them immediately. At the end of the third month, you will see that part of the list has dropped off by itself.
For a temporary situation
A one-time need does not deserve a permanent adaptation.
For temporary needs, the tagging and reporting layers are sufficient; do not touch the data model.
8 questions to ask your vendor
Let this page not try to convince you; let it give you a yardstick. Ask the questions below of every vendor you evaluate — including us — and request the answers in writing.
Adaptability evaluation questions
Ask them on the basis of a concrete requirement; do not settle for general answers.
- Who can make this change? My own team, a consultant, or only the vendor?
- How long does it take? Not the development time, but the total time from request to go-live.
- What will happen in the next version? Is the change preserved, redone, or can the version not be installed?
- Can it be reverted? Does removing a wrong adaptation take minutes, or does it require a project?
- Where is the record of this change kept? Three years from now, where will I read who made it and why?
- Is a separate platform or an additional license required? Do I have to purchase a second product for adaptation?
- Are the fundamental concepts of my industry in the core? Or am I expected to imitate them with user-defined fields?
- If I stop working with you, what happens to my data and my adaptations? Does the data reside on an open and documented platform?
The third and eighth questions are the most discriminating. A vendor who cannot give clear answers to these two questions is selling you not flexibility but deferred cost.
Summary comparison
| Topic | Rigid standard package | Custom software from scratch | Minerva |
|---|---|---|---|
| Deployment | Fast | Very long | Fast, on the standard core |
| Day-one fit | Partial; the enterprise fits the software | Complete | High, through layered adaptation |
| The fiftieth change | Usually not possible | Much more expensive than the first | At the same cost as the first |
| Who makes the change | Vendor only | Development team | First four layers by the key user |
| Typical waiting time | Weeks | Weeks | Minutes or hours for layers 1-4 |
| Version upgrades | Trouble-free but no flexibility | No concept of versions; the system freezes | Definition records preserved, code layer tested |
| Maintenance cost | With the vendor, shared | Entirely yours | Core with the vendor, adaptations yours |
| Industry concepts | There if they exist, absent if not | There if written | Defined in the core, extensible |
| Vendor dependency | High | Dependency on the developer | Open and standard data platform |
| Five years later | Part of the business runs outside the system | System frozen, nobody touches it | Keeps changing |