Everyone understands custom code because everyone recognizes that it is a customization. However, many times, people don't understand custom fields. People consider custom fields to be harmless. Creating a field typically takes a few minutes and then they begin to slowly become part of reporting, integrations, and other business processes where people cannot remember if anyone approved their inclusion in the first place.
Most ERP teams are very cautious with regards to developing custom code.
When you want to develop a new module within your ERP software, there will usually be some sort of formalized requirement process. That formalized process typically includes estimating how long the work will take (and thus how much it will cost). There is also testing of the code prior to its release to production.
Fields can be created before lunch:
- “Can we add a Contract Type?”
- “Can we track the sales person here?”
- “Can we add another status?”
All three of these questions seem reasonable; all three of these questions represent small individual changes.
However, three years from now, the customer record will have 47 additional fields added. Only eleven of those additional fields will be required. Eight of those additional fields will be feeding into reports. Six of those additional fields will be being utilized through integrations. Additionally, nobody will fully understand exactly what the remaining twenty eight additional fields were intended to do.
Again, the issue isn't the fields.
The issue is that nobody was treating the creation of those fields as the design of the system.
The cheapest change rarely feels like customization
An individual field doesn't resemble an individual piece of code.
There is no developer involved. Therefore, there are no changes made to a repository. There are no changes made to a deployment process.
Therefore, based upon the above reasons alone, a field is perceived as having little or no cost associated with it.
But that is incorrect.
Each time an individual field is created, that represents yet another potential configuration for an individual record. And therefore somebody has to make decisions regarding who will enter this data, when this data will change and whether this data is mandatory. In addition, each report must determine if this field affects the report's output. Each integration must determine if this field must be sent along with the data. Finally, permissions may require modification.
Although the technical costs associated with creating a field could be virtually non-existent once the field exists, the operational costs associated with creating a field can occur immediately after the field is created.
Custom code causes the technical costs associated with creating such code to be visible at the time the code is developed.
In contrast, custom fields often mask the technical costs associated with creating custom fields until some future date.
Every field creates downstream obligations
Consider a field named “Customer Tier.”
Initially, sales wishes to utilize this field as a means of segmenting customers. The available options for this field include Gold, Silver and Bronze.
Simple.
Later on, finance wishes to utilize this field in determining payment terms for customers. Customer Success wishes to use this field in establishing service levels for customers. Lastly, a dashboard displays revenue grouped by tier.
Then somebody adds “Strategic.”
This change is not simply updating the dropdowns for “Gold,” “Silver” and “Bronze.”
Will Strategic receive Gold payment terms? Should historical dashboards display this tier separately? Does the CRM already contain the new value for Strategic? Will an integration fail when attempting to send the new value for Strategic?
This single field has now become a tiny piece of business logic.
Because this single field appears so simple, this occurs quietly without anyone realizing it.
As soon as one additional process relies upon a field, that field becomes part of the overall architecture of a company's system.
Thus, just as with custom code, the maintenance of that field should reflect that.
Empty does not mean optional
Missing values are also caused by the same fields as ambiguity.
Consider an implementation that adds “Renewal Type”. Half of all existing contracts were migrated without a value for this field. What does blank mean? (blank) might represent that there is no renewal. It may be that the team has not been identified. Or, (blank) could indicate that the migration missed to capture the value. Those are three different facts. The report will not know which fact they are trying to identify.
In most cases teams solve this problem by making the field required. However, this creates another problem. Users enter whatever information gets them past the screen. “Other” becomes the most popular answer.
Only when users know the answer and the options describe reality do required fields improve data quality. Otherwise, the system collects cleaner-looking bad data.
Reports expose the real cost
When someone wants to run a report on a new field in the application, usually at that point the field becomes expensive. The request sounds straightforward.
Example — show revenue by customer segment.
However, then questions start coming up. Was the customer segment captured historically? Can the customer segment change over time? If the customer moves from Mid-Market to Enterprise today should last year's revenue move with it? That question matters.
If the report uses the current value of the customer segment historical results can change when the business changes the field. If the business needs the value to exist as it existed at transaction time then it may belong on the transaction instead.
That is a data model decision.
It should not have been made because one screen had an easy button called “add field.” Reporting requirements often reveal that the business did not really want a new field. They wanted a dimension, classification rule or historical attribute.
Duplicate fields are usually a governance problem
Duplicate fields are probably one of the easiest forms of ERP debt to find.
“Sales Region.”
“Customer Region.”
“Territory.”
“Reporting Territory.”
Each may have had its reason. Maybe someone could not locate an already existing field. Maybe some other team needed slightly different values. Or, maybe another team just did not trust the first field's data. Creating a new field solves the immediate problem. But it makes the underlying problems worse.
Before adding a new field ask yourself if the information already exists elsewhere. If so, ask why that value cannot be used. The answer may reveal a real difference between how two teams view their customers. Or, it may reveal who owns a given piece of information. A new field is a very poor substitute for deciding who has authority for an existing value.
Put a gate in front of new fields
Custom fields do not need a six week approval process. But they need a small gate. Write down these things before creating any new field.
- What business decision will use this field?
- Who will own the definitions of this field?
- Who will enter and/or update this field?
- Is this field required?
- What does a blank mean in relation to this field?
- What values are allowed for this field?
- Must we keep track of historical values for this field?
- Will people run reports using this field?
- Will some other system read/write against this field?
- What will happen if/when we eventually decide to remove/retire this field?
All of these take a few minutes to complete for even a very simple field. And that is enough. We are not looking for bureaucracy here. We are simply looking for evidence that someone thought about the consequences of adding this field before it became permanent. Fields that cannot answer any of these questions may not be ready to live yet.
Where this argument is weak
Custom fields are useful tools.
A rigid ERP that cannot represent information specific to your business forces users back into spreadsheets – which is much worse than using custom fields.
There are many fields that remain very simple. Delivery instructions, internal references or secondary identifiers may require little governance. Creating a custom module for such information would clearly be absurd.
The argument is not that custom fields are unacceptable.
But rather, that light configuration should never be confused with zero-cost configuration.
Lighter technical changes are more likely to occur without design discipline than larger ones.
And that is exactly why it needs discipline.
Customization should leave evidence
Just like good custom code comes with a specification and an owner – custom fields deserve a smaller version of the same treatment.
Record purpose and ownership of each field. Record dependencies for each field. Regularly review fields and retire any that no longer serve an active process.