Contingency Factors in Data Governance Design for Revenue Systems

Data governance in revenue systems is usually implemented from a template: form a council, publish standards, add an approval step, run a cleanup. The template is applied largely unchanged whether the organisation has forty employees or four thousand, and it fails at a rate that suggests the template rather than the execution.

The research on governance design says something more specific and more useful than the template does, and it says it in the title of the paper.

1. The contingency finding

Weber, Otto and Österle [1] develop a contingency approach to data governance, and their central conclusion is that no single governance configuration fits all organisations. The appropriate structure — how centralised, which roles, which decision rights sit where — depends on identifiable organisational factors rather than on a universal best practice.

This is a direct contradiction of how governance is typically sold and implemented. It also explains a common pattern: a governance model that worked at one company, imported by someone who worked there, failing at the next one. The model was not wrong; it was fitted to a different set of contingencies.

2. Quality is fitness for use, not accuracy

The second foundational result concerns the object being governed. Wang and Strong [2] established through empirical work with data consumers that quality is multidimensional and defined by fitness for use — accuracy is one dimension among several, alongside timeliness, completeness, interpretability and accessibility.

The consequence for revenue systems is immediate. An account owner field can be accurate and useless if it is populated three days after routing needs it. An industry classification can be complete and useless if two teams read the values differently. Governance aimed only at accuracy addresses one dimension and reports success while the consumer's problem persists.

3. Why cleanup does not persist

Redman [3] set out how poor data quality propagates cost through an enterprise — errors are not contained at the point of entry but travel into decisions, operations and customer-facing processes downstream.

The operational implication is that a cleanup addresses the stock while the process continues producing the flow. Absent a change in decision rights over what enters the system, the corrected state decays at the rate the process generates defects. This is why the second cleanup is usually proposed within a year of the first, and why proposing it is treated as diligence rather than as evidence about the first.

4. Governing toward use, not toward the system

DeLone and McLean [4] modelled information systems success as a set of interrelated dimensions — information quality and system quality influencing use and user satisfaction, and through them organisational impact. The relevant structural point is that data quality is positioned as an input to use rather than as the terminal outcome.

Governance evaluated on its own outputs — standards published, records corrected, council meetings held — is measuring intermediate activity. The question a governance programme should be able to answer is whether the data supported a decision better than it did before.

5. Method: determining the configuration

1. Identify the consumers and their uses, before touching structure. For each significant data domain, list who consumes it and for what decision. Governance without an identified consumer has no fitness criterion and will default to accuracy.

2. Locate the contingency factors that apply. Firm size, decision-making centralisation, process standardisation, regulatory exposure and the diversity of business models all bear on the appropriate configuration. Write them down explicitly — this is the step the template skips.

3. Assign decision rights domain by domain, not uniformly. Account data and pipeline data frequently warrant different configurations in the same company, and forcing one model across both is a common failure.

4. Instrument each dimension of quality separately for the domains that matter, using the tests in section 2. A single quality score conceals which dimension is failing.

5. Govern the flow before the stock. Entry controls, ownership at creation and definitional change control determine the steady state; cleanup only sets the initial condition.

6. Re-examine when a contingency factor changes. A structural change — an acquisition, a segment entry, a move to self-serve — invalidates a configuration fitted to the previous state.

6. Limits of this argument

The governance contingency work [1] establishes that configuration varies with organisational factors; it does not supply a lookup table mapping a specific firm to a specific design, and this paper does not invent one. The quality dimensions [2] are established empirically with data consumers in general organisational settings rather than in revenue functions specifically. The propagation of quality cost [3] and the systems success model [4] are likewise general findings applied here by argument.

What is defended: governance is a decision-rights problem whose right configuration is contingent and knowable, quality is fitness for use rather than accuracy, and a programme that governs the stock without the flow will not hold. Determining the specific configuration for a given organisation is what section 5 is for.