Many organizations (businesses as well as governments) engage in scenario planning to address the increasing uncertainties they must face. Uncertainty forces organizations to recognize several plausible futures and develop strategies and policies that appear best in light of the uncertainties defined [10]. For example, what if the rate of adoption of a new technology drops or an industry faces numerous debt defaults? How will strategies and policies need to be changed to enable businesses to move quickly to confront such events?
During scenario planning, factors that might affect the outcome of such future events must be identified and categorized by their degree of uncertainty and likely impact on outcomes. For example, in light of the 9/11 attacks, government planning for homeland security must take into account threat assessment, counter-terror activities, threat reduction, and disaster recovery. These types of events might be categorized as wild cards, that is, they are the most uncertain but would have an enormous impact if they occurred. Scenario planning cannot predict the future, but it can help organizations become more aware of possible outcomes by encouraging planners to envision, learn from, and prepare for potential futures [4].
Longer-term scenario planning requires collaboration by teams of stakeholders, which may include economists, sociologists, financial analysts, and domain experts. Royal Dutch/Shell created one of the first scenario-planning protocols in the 1970s, now known as the Shell method, which has served as a model for scenario planning for many U.S. firms. The Shell method involves workshops at company locations around the world and “learning journeys” in which executives visit sites across the globe to gain insight into how their scenarios might play out in an attempt “to benchmark [their] visions against assumptions” [5].
Some of the difficulties in successful scenario planning revolve around the fact that planning teams operate in a remote, asynchronous environment in which disparate teams make decisions governed by rules and policies not widely shared across the enterprise. In addition, for longer-term planning in which planning teams travel to geographically dispersed locations over an extended period, much of the momentum accrued dissipates as the planning process drags on. Thus it becomes increasingly difficult to test the robustness of strategies under each scenario as conditions shift over time. Even more important, remote planning teams may not possess the shared weltanschauung, or world view, required to guide a planning process that affects the entire enterprise and its stakeholders.
To address some of these difficulties, we propose a Web portal architecture (see the “Web Portals” sidebar) that enables enterprise planning teams to create scenarios and experiment with a decision support system (DSS) model of key planning processes, jointly, in a virtual community environment. The potential benefits of such an approach to enterprisewide policy and decision making are promising. First, experimentation with a DSS model enables knowledge creation. Likely future scenarios serve as a springboard for assessing the effects of a variety of policy implementations on critical success factors for the firm. Second, a Web portal enables teams that often operate in a stovepiped fashion to collaborate in an integrated electronic environment and share the results of scenario planning experiments. Third, if designed properly, a Web portal can assist teams collaborating on the planning process to develop and share a world view of the organization and maintain a repository or history of the planning process. Fourth, distributed experimentation with a DSS model of the planning environment exposes risks and permits outcomes to surface in light of uncertainties.
DSSs are currently used for planning in non-distributed environments, such as spatial planning using geographical information systems [8] and local law enforcement planning using a myriad of information technologies [2]. The U.S. military uses DSS for a variety of purposes, including strategic planning [1] and delivering military lessons learned [11]. All of these applications could benefit from an architecture that supports distributed planning through virtual scenario building and evaluation.
An Architecture for Distributed Scenario Building
A unique architecture is required to support distributed scenario building and evaluation. First, the architecture needs to allow disparate groups to operate as a virtual community with shared goals. Issues related to the development and nurturing of virtual teams are many and have been reported throughout the information systems literature. For example, Sarker and Sahay [9] provide a detailed study of the development of virtual teams, and Jarvenpaa and Leidner [6] discuss issues associated with communication and trust in virtual teams. Second, the architecture must provide the functionality for remote teams to develop potential scenarios, experiment jointly with a DSS model that captures key planning processes, and manipulate factors affecting future outcomes. Third, it must provide mechanisms for remote teams to view and discuss the results of their experiments. Fourth, rules and policies enforced by disparate teams must be accessible to everyone involved in the planning process for scrutiny and evaluation. Fifth, to encourage the development of a learning community, the architecture should contain a lessons learned repository that is available to all stakeholders involved.
Figure 1 depicts our proposed Web portal architecture, which employs a variety of integrated components interacting over a wide-area distributed network, satisfying the needs outlined above. Peer-to-peer networking can be employed to keep each node current with relevant data and reduce network traffic.
In the proposed architecture, the main “community center” for the portal environment is the collaboration engine, which provides a common real-time enterprise view of the scenario planning process, enabling and encouraging engagement by each planning team. The collaboration engine manages user profiles, authentication, forums, chat rooms, and community information. Thus, users may meet in secure, virtual rooms that contain the unique characteristics of the community as well as community objects. The community objects include documents, multimedia materials, scenarios, and DSS models. In addition, the virtual rooms provide the connection infrastructure required (for example, protocol conversion for high-bandwidth international connectivity).
The scenario builder tool creates a script that controls the organization of resources and sequencing of events needed for a given scenario that is run using the appropriate DSS models. For example, data from geographically distributed sources may need to be integrated with local data to create a composite data source for the executed DSS models.
A rule repository and accompanying rule manager store and manage rules and assumptions driving the DSS model. For example, if a simulation DSS model is employed, typically each planning team will have unique simulation parameters to manipulate. The rule repository and rule manager translate these parameters into a common form that is understandable by all participants. The rule manager serves as an editor for rules and data held in the repository. Ontological techniques could be used to develop a common DSS parameter language.
A DSS engine consists of a DSS application that allows users to set key model parameters (defining a specific scenario), specify experiment conditions (such as model assumptions and time frame), and run each scenario-driven model. It accesses data from operational databases, invokes appropriate DSS routines, and emulates the dynamics of the planning process, such as the movement of objects in the model’s environment. The associated model manager handles DSS model integration.
A “lessons learned” repository uses standard database techniques implemented in the database tier level of the architecture. Lessons learned consist of an indexed collection of text, charts, and graphics representing a record of the events and outcomes of previous or ongoing virtual planning scenarios.
Navigation through the data is handled by the presentation manager and implemented as a collection of Web pages with hyperlinks. The server-based presentation manager also handles the relatively complex display characteristics of the application and provides data push functionality. Through data push, the portal can update user data without requiring a user request; this can be combined with peer-to-peer networking to guarantee that participants have relevant data at the same time. The architecture is n-tier and distributed, allowing additional tiers to be integrated into the architecture as the need arises.
Portal Interface
The portal architecture provides an infrastructure that keeps all participants aware of the components of each defined scenario and the results of each DSS model executed. For the portal to imitate an actual community of decision makers, it needs an interface that encourages discussion, chats, and personalized views of the scenario building process. Figure 2 depicts a hypothetical portal interface consisting of a collection of views for which each view is detachable.
The division of the portal into views is required given the complex nature of the interactions, the need to have a multitude of open windows (with accompanying screen clutter), and the desire to segment the application into functions that parallel the underlying planning process. The views are summarized as follows:
- Home contains the authentication and general information screen.
- Data View includes sub-views of the rules and lessons learned repositories. It provides access to all current and legacy data used in planning and supports the creation of interactive maps, tables, and charts.
- Model/Scenario View includes the scenario management tool used to plan, create, and execute complex scenarios. It allows users to select the appropriate DSS models, run the models, and store and display model results.
- News gives users access to a variety of internal and external news sources as well as chat traffic.
- Composite View integrates the data, model, and news views.
- Collaboration View incorporates the features of the composite view with additional collaboration functionality. It provides users with real-time, secure, room-based chat functionality, a group view of specific scenarios created (including rules invoked) along with model results associated with each planning scenario, a common whiteboard, shared applications, interactive maps and charts, and audio and video connectivity.
To illustrate the functionality of the proposed architecture, we describe a prototype scenario planning DSS simulation model that was developed, tested, and validated for the U.S. Navy at standalone sites [12]. The prototype was developed as a proof of concept of the ability of the DSS to provide the functionality necessary for distributed scenario planning. The proposed Web portal architecture evolved as a product of the insights gained in developing the scenario planning model itself and has not yet been implemented.
Organizations cannot create or predict the future. To survive and thrive, however, they must be able to plan for the future. Scenario planning is one method that attempts to define the driving forces and uncertainties facing an organization and promote an understanding of how plausible futures may impact the policies and processes to be implemented today.
A Prototype Manpower Planning Scenario Model
Many of the same challenges facing business organizations plague the U.S. Navy. Functional units operate in a stovepiped fashion in which data, information, and knowledge are not distributed and shared across the enterprise. To address this problem, the Navy has created a plan for a “networked Navy.” The prototype we describe is one application among many in a multidimensional research endeavor to discover applications that will foster collaboration in distributed environments.
Our prototype DSS models the Navy’s manpower, personnel, and training (MPT) process and allows manpower planning teams to jointly develop planning scenarios that reflect potential future events, assign their probability of occurrence, experiment with rules and factors that affect fleet readiness, and assess the impact of uncertainties and current policies on future performance. The factors identified for the MPT planning process, as well as planning scenarios in general, are outlined in the accompanying table.
This simulation model mimics the movement of Navy personnel over time, assigning people to jobs (billets), moving personnel from place to place and ship to shore, and processing new recruits, promotions, rate changes, attritions, and so on. As billets become available or personnel become eligible for advancement, an optimization model is invoked to match people to billets. Assignments are driven by the specific scenario defined and the associated factors and rules that planning teams specify as input values for each simulation run. The impact of a scenario on fleet readiness can be observed over any number of years. This impact may be in the form of costs (such as training costs and permanent change of station costs), quality of life issues for personnel (including the number and type of permanent change of station moves experienced), quality of matches of personnel to billets (how well a person’s skill and training fit the billet), the ability to recruit the required number of the right people, on-time arrival of personnel to billets, the ability to have the right mix of ranks and seniority at different locations, and the ability to provide the necessary training when it is needed.
The proposed architecture (see Figure 1) evolved as a model for distributing the power of the MPT simulation model. For example, when a planning team selects the simulation and optimization DSS models, the data associated with master personnel records and master billet files stored in the database tier of the architecture will be passed to the DSS engine. Remote planning teams will develop scenarios using the scenario building tool through the Web portal and run the model for a specified length of time, say eight years. A sample scenario might specify future changes in force structure based on probabilities associated with likely commissioned and de-commissioned activities. The planning teams further articulate driving forces associated with each scenario by designating rules to invoke or relax (for example, a minimum of three years of obligated service is required for transfer to Hawaii), setting priorities for assigning personnel to billets (for example, maximize the number of “no cost” moves or maximize the Navy Enlisted Classification utilization—a measure of how well a person’s skill level matches the skill requirements of a billet), setting training class sizes and starting dates, and estimating attrition and advancement rates.
Through the portal interface, authenticated users develop scenarios, view and evaluate the rules various planning teams employ, share results of a simulation planning run, and discuss the risks of each plan associated with a particular scenario either through chats, bulletin boards, or live real-time videoconferencing. As insights emerge, they are stored in the lessons learned repository.
Our prototype simulation DSS model demonstrated its ability to emulate the MPT process of the Navy for the rate classification sonar technicians. It was able to produce valuable explicit knowledge such as costs related to training, permanent change of station moves, and community skills and seniority mixes. It was also able to produce important tacit knowledge about the effect of rules and policies on fleet readiness. It demonstrated the power of the scenario planning modeling environment, even though teams that experimented with the prototype at this stage in its development designed scenarios and shared insights and results using conventional means such as email and telephone. Our proposed Web portal architecture captures the functionality and component integration required to distribute the power of this DSS model to MPT planning teams throughout the Navy.
Conclusion
Organizations cannot create or predict the future. To survive and thrive, however, they must be able to plan for the future. Scenario planning is one method that attempts to define the driving forces and uncertainties facing an organization and promote an understanding of how plausible futures may impact the policies and processes to be implemented today.
To address shortcomings of traditional scenario planning protocols, we proposed a Web portal architecture that permits geographically dispersed planning teams to experiment with planning scenarios using DSS models. The architecture embodies a virtual community that encourages knowledge sharing. We illustrated its functionality with a sample prototype manpower planning application developed for the U.S. Navy. However, we see the potential for many other domain areas to benefit from the proposed architecture. For example, distributed planning teams in the banking industry may benefit from the proposed architecture by being able to pose future corporate power and government control scenarios, which would drive a DSS model that captures demographic data and macroeconomic trends. They could use this model to plan for technological changes that might reshape the structure of financial institutions.
The energy industry can benefit from the architecture by experimenting with DSS energy models virtually to observe the effects of scenarios such as the adoption of renewable energy sources or possible new fuel technologies on industry policies. Regardless of the domain, the proposed architecture has the potential of distributing the power of DDSs to geographically dispersed planning teams so they can jointly assess the impact of potential futures on decisions made today.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment