SSPF has been in operation since August 1996. This initial version focused on collecting data, making it available to users, and logging data into a relational database. The most successful part of this initial release was in providing the data necessary to improve throughput. As the system collected and logged data, it became practical to provide continuous and regular feedback to Saturn’s leadership, including the throughput task force.
The primary measurement the task force used to identify areas requiring specific improvement programs (activation areas) and to measure progress was stand-alone capacity.
SSPF provided this information in the form of
- a daily report to management that showed the previous day’s performance,
- a weekly report that concerned short-term as well as long-term performance, and
- a weekly report that showed long term trends for each activation area.
Saturn started the SSPF project in September 1995 with an engineering study. Following the study, Vanderbilt developed a prototype, which it demonstrated in December 1995. We next developed the production version (SSPF Version 1.0) and put it into operation in August 1996. As Saturn personnel used the system, lessons learned led to new and altered concepts which required many upgrades and additional functionality, requiring an overhaul of the modeling paradigm. On the basis of this new paradigm, we developed SSPF Version 2.0, which has been operational since June 1997. We learned many lessons during this time.
- Modeling the plant is a large part of the effort. This is not surprising, since we generate the application itself from the models.
- Eliminating excess data and providing only key indicators is crucial. The validity of this principle became apparent to us when we first selected the data SSPF would collect and display.
- Verifying and testing the application was easier. Before production release, the SSPF beta release was online while we built the models. Whenever we added to or changed the models in any way, we regenerated the application and tested it, which allowed us to verify the application and the models. The turn-around time was only the time required to change the models and to regenerate the configuration tables. This short turn-around time clearly showed how flexible and maintainable an application becomes through the use of models.
- Handling changes in user requirements was efficient. During development, changes only required modification to one configurable component followed by a regeneration of the application. The change would then appear for all the plant’s processes and buffers. Without MIC, trying to keep an application upgrade consistent for the large number of processes and buffers would have been difficult and costly.
- Responding to changing business needs became quicker. Once Saturn team members realized how responsive SSPF was to business needs, they started to frequently change the focus of their analyses, sometimes changing the models as often as once a week. Since changing the models is equivalent—in other techniques—to changing the software system, we were effectively changing the system every week without adverse impact to SSPF’s performance or robustness.