8.2.6 Exploring Alternatives

In attempting to achieve these laudable goals for a model, the first question to ask is simply this: Does the model have understandable outputs? As straightforward as this question may appear, output formats are quite important to the user. For instance, we have found the incorporation of a user "glossary" as an input option to be very important. Such a glossary allows the user to identify the model with his or her agency, with agency and city specific names for geographical atoms, vehicles, response areas or districts, routes, and so on. Seeing "Times Square" on the output is much more meaningful to a New York City user than "geographical atom 12." Also, simple word choices such as "average" rather than "mean" can be important. A detailed model may be improved by producing different levels of aggregation for outputs, from highly aggregate (city-wide) to highly disaggregate (neighborhood-oriented) outputs.

To assist in modifying operating policies and other input data, a natural language interface linking the user to the model is often appropriate. Such an interface is a computer program that "talks with" the user in his or her language, while being capable of altering all input data in the model. It is a model/user "go-between." It assists in adding units, redeploying units, rescheduling, reprioritizing, redistributing demand, and so on, none of which need cause headaches associated with data-card changes. Rather, the user can express his or her desire for an alternative policy in language with which he or she is most comfortable and the interface program does the tedious work of changing data cards. This on-line procedure can even be used in submitting batch-processing production runs.

Once data changes can be readily made, we must concern ourselves with the user's systematic exploration of alternative policies. Such user-directed exploration would not be required if he or she could use an optimization algorithm to compute "the unique answer." It is our view that few urban services can directly implement the results of an optimization model. This is due to the complexity and multifacetedness of most urban services, where objectives and constraints can rarely be uncontestedly expressed in mathematical form. Rather, it is felt that a user with an intimate knowledge of his or her own city, can be an excellent judge of the qualitative factors that are relevant. Using the computer to calculate the important performance measures of proposed alternative operating policies, model usage becomes an erative process. First, the user proposes a particular operating policy (e.g., deployment of resources) and has the computer model calculate the resulting values of performance measures. The user then incorporates this evidence, including possible workload imbalances among workers and/or inequities in citizen accessibility to service, with the remainder of his or her knowledge of the area under consideration, and decides whether to accept the proposed operating policy or to devise an altered one. In the latter case, the entire process is repeated one, two, or several times until a satisfactory operating policy is obtained. In this way, good use is made of the user's talents and he computer's computational power.