We make a provocative claim about enterprise software. Across the thirty-odd modules of a full suite, roughly a dozen problem classes do almost all of the real work, and conventional suites rebuild each one per module, at the customer's expense. A claim with a count in it earns the obvious question. Name them.
Fair. A count you cannot enumerate is marketing, and we have written before about what separates evidence from marketing. So here is the list.
The dozen
- Entity resolution. Is this supplier, this counterparty and this hotline subject the same real-world thing, behind four spellings and three registrations?
- Ownership tracing. Who stands behind this company, layer by layer, and when does indirect control or shared exposure matter?
- Forecasting. What will this number be, and when will this event happen, with stated odds and a naive baseline to beat?
- Anomaly detection. Is this expense, override or sensor reading unusual, against its own history and against its peers?
- Classification and mapping. What kind of thing is this, and what in the company does it touch?
- Conformance checking. Does reality match the commitment? The document against the changed rule, the actuals against the plan, the transaction against the control.
- Exception triage. Of these thousand signals, which few deserve a person, at what severity, owned by whom?
- Scenario and counterfactual. What happens if we act, or do not, priced before the intervention is committed?
- Attribution. Why did the number move? The answer arrives ranked by measured driver, a calculation rather than a story.
- Allocation under scarcity. Where does the scarce unit of stock, cash or attention earn or protect the most?
- Planning and stability. What sequence is feasible, and when is a replan worth the churn it causes?
- Evidence and lineage. Can every answer show where it came from, and be regenerated identically on demand?
Notice the nouns inside each question. Every one borrows from several functions at once, on purpose, because the nouns are interchangeable. Swap supplier for customer, stock for cash, expense for sensor reading, and the question does not change. That is the definition of a problem class. A question shape, an input shape and a way of scoring the answer that survives the move from one function to the next.
Maturing fields make exactly this move
The consolidation has a distinguished history. In 2006, Berkeley's parallel computing group published what became known as the thirteen dwarfs, the observation that essentially all of scientific computing reduces to thirteen computational patterns. Build for the patterns rather than the applications, the argument ran, and a generation of hardware and libraries followed it. Operations research made the same move half a century earlier, when allocation, assignment and scheduling turned out to be the same problems wearing different industrial costumes, which is why one method conquered refineries, airlines and logistics at once.
Enterprise software has not made the move, and the market's own structure shows the cost. Entity resolution is sold today as master data management, KYC matching, sanctions screening and CRM dedupe, several of them with their own analyst categories. Anomaly detection is sold as fraud detection, transaction monitoring, quality control and expense audit. The industry maintains separate product categories for the same underlying capability with different nouns attached, and every customer funds the duplication.
Run the test on the list
A published list is an invitation to check it, which is the point. Take any capability of any module, ours or a competitor's, and ask which of the dozen it reduces to. Supplier risk warnings reduce to forecasting plus exception triage. Regulatory change management reduces to classification and mapping plus conformance checking. Sanctions exposure reduces to entity resolution plus ownership tracing. If you find a real capability that does not reduce, the list grows, and we would rather grow it in public than defend a number.
The count is honest at the family level. Inside each class sit specialisms, the intermittent series that needs different treatment from the steady one, the cold start that borrows from an analogue. Those are depths within a class, not new classes, in the same way cardiology and paediatrics are depths within medicine.
The important argument is not whether the number is twelve. It is that the number is small.
Enterprise software inherited the organisation chart as its architecture. Finance bought finance software, compliance bought compliance software, supply chain bought supply chain software, and the result is a market that repeatedly solves the same underlying problems under different names. A maturing industry eventually notices that it is rebuilding the same machinery. Computing noticed in 2006. Operations research noticed in the 1950s. Enterprise software is beginning to.
So the question is no longer whether these problem classes exist. The question is whether organisations want to keep paying to solve them thirty times. Prophesee was built on the belief that they should be solved once, improved continuously, and shared everywhere they apply. Ask a suite vendor to name their dozen, and watch whether the answer is a list or a subject change.
Build around functions and every improvement stays local. Build around problems and every improvement compounds. See the classes running on your own functions.