Simultaneous Equation Models

To predict outcomes of actions, you need models that encapsulate processes

We work with a profusion of models for information-systems architecture and design that allow us to describe the physical world in abstract, conceptual, and logical form. We have a good understanding of the type of conceptual model that will best fit different types of data and applications. But at the risk of oversimplifying, I say that process and business-rule models, rather than data or software models, play the leading role in decision support.

These models, which I call decision-support models (DSMs), encapsulate methods of deriving meaning from the information. A DSM gives you an analytic framework for optimizing system and process performance, for evaluation of "what if?" scenarios, and for goal-seeking studies that concoct a recipe for your desired outcome. You need to do more than represent data and code in your analytic framework: It is on the transformation of inputs into outputs that decision support centers.

Approaches to modeling system dynamics - processes, rules, state transformations, and so on - run the gamut from flow diagrams and sets of declarative rules to complex systems of equations. Although they've been around as long as data and software models, they are generally less understood because, simply put, there are more of them. There are more of them because DSMs are tied with varying degrees of intimacy to particular subject areas - quantum physics, corporate finance, or college admissions, for example - or to specific processes that may occur in multiple, disparate subject-matter domains, or even more narrowly, to processes within specific domains.

Descriptive scope and accuracy, as well as explanatory power, make a DSM interesting, but two things make a model useful: It can be solved, and its solutions are meaningful. Flow diagrams and sets of rules in themselves are not solvable; you can't use a heuristic, high-level description of a system's transformation of inputs into outputs to determine the inputs and processing adjustments that will, subject to constraints, produce your desired outputs. To create a solvable, useful DSM, the conventional approach is to express it as a system of equations.

Basic models simply describe known outcomes; more sophisticated models show the transformation steps that turned inputs into outputs. (See sidebar "Model Progress.") Of course, a model doesn't have to be explanatory to provide good forecasts - I know that if I head northeast from Philadelphia I'll eventually get to New York City, whether I travel by train, bicycle, or skateboard. And a model that provides good forecasts isn't necessarily the best model for the job; there's more than one way to skin a cat. In practice, however, only a model based on transparent, realistic steps will be solvable.

With solvability, you can measure not only how accurately a model depicts a system, you can also evaluate the likely results of changes to inputs, processes, or both. This is a fancy way of saying that you can use a solvable model to optimize the modeled system. You optimize a model via a function that measures the difference between the model's results and real-world observations. You can then apply an optimized model to predict the outcome in alternative scenarios. The numerous possible applications for such solvable models in enterprises include:

• Optimization of procurement, supply chain, manufacturing, and distribution
• Resource scheduling
• Network and transportation routing
• Asset allocation and portfolio management.