§ Will changes in product or the manufacturing differences affect the applications?
§ How do manufacturing business practices change from site to site?
§ What type of process control or I/O systems exist at each site?
§ What hardware, system software, and networking protocols exist at each site?
§ Do the user communities differ at each site with respect to their information needs?
§ What user communities should be interviewed to assess requirements?
§ What type of training or follow-on consulting must be provided to make the application effective at each site?
§ Who will be responsible for first-line support at each site once the application is commissioned?
Answers to these and a host of other questions should be captured as part of the deliverables that result from the analysis process. Once the architecture vis-á-vis the applications is known, the quality and location of sites to be included in the analysis can be selected.
Exhibit 1 presents an overview of the process of requirements analysis or documenting the common specification across the target business. In Exhibit 1, leveraged resources represent the analysis team responsible for designing and delivering the application across multiple sites. Site resources consist of two groups:
Exhibit 1. Roles and Responsibilities Model for Leveraged Software Development and Support
1. The user community: Users provide the business objectives and needs.
2. The IS community: IS maps the effect of systems on manufacturing operations.
The analysis team captures information needs across multiple sites. In a manufacturing context, information needs may be similar to these examples:
§ Amount of product waste on yield on each line by shift
§ Statistics of key process/quality parameters
§ Recipe or formulary for each product
§ Trend of selected process values over time
A successful modeling effort results in a shared specification that enjoys system independence in that it describes what the business does, not simply “how” it does it.
The use of a shared data and functional model is an effective means of creating a living specification that reflects the information needs of the business.
Data and functional models resulting from analysis can also be used to complete development. Whether the design team elects to purchase off-the-shelf application components or to develop custom software, the model-based specification is useful.
Whether full life cycle computer-aided software engineering tools or 4GL tools are employed, the data and functional specification are foundational to the applications.
Fourth-generation client/server tools that allow decoupling of client processes from the database server can be effectively used to capture user screen requirements during prototyping.
ORGANIZING FOR LEVERAGING
Leveraging is a business objective, originating from a purposeful decision to provide common solutions across numerous manufacturing sites. Leveraging begins, therefore, with the affected organizations sharing this business objective.
Businesses that enjoy a culture where ideas germinate at the lower levels of the organization can offer some of the greatest challenges to leveraging. These businesses often build strong IS capabilities at the plant and manufacturing sites to support and build new manufacturing software applications. For such organizations, their strength is also their weakness when it comes to leveraging applications software. Overcoming the cultural and organizational barriers at a site to a businesswide or corporatewide convergence effort or solution can become a serious hurdle to the planner and analyst. One means of mitigating this problem is the use of a leveraged application work group that represents the various sites.
Leveraged Application Work Groups
The leveraged application work group is responsible for capturing the business benefits that accrue across multiple manufacturing sites during the definition, development, and deployment of an application. The work group is composed of representatives from each business or site that derives benefit from the application,
as well as a project engineer or analyst and a sponsor from the corporate staff function that is held accountable for the success of the program.
The work group is formed soon after an individual business unit or site requests development of a new manufacturing application. Additional sites and business units are solicited for membership in the work group by distributing a brief description of the application and anticipated benefits from deployment across multiple sites. A project engineer or analyst is assigned to draft a detailed specification that is then reviewed and upgraded by the work group. Upon reconciliation of all the requested modifications to the specification, the document is reviewed with the application supplier. The supplier provides a proposal for developing the application (functional design concepts, cost, and schedule).
Funding from each site and business unit for the development of the application is a key component in the success of leveraging software. Funding from multiple sources reduces the cost for each individual site.
Upon delivery of the application analysis and detailed design documents from the supplier, the application work group reviews the design and decides what modifications or scope changes are required. The work group is responsible for making certain that the final design will bring the maximum benefit across the different sites.
The application work group decides which site is appropriate for piloting the application. Selection of the first site is important because the lessons learned at this site will be the basis for deployment at additional sites. After installation at several sites, the work group compiles all the installation lessons and benefit information. A best practices/implementation guide is compiled for rollout at multiple sites.
A communications bulletin is distributed to all the business units and sites for potential reuse of the application. This communication alerts sites considering development of a similar or redundant application.
DELIVERING LEVERAGED APPLICATIONS
If as a result of the analysis and design it is determined that an off-the-shelf package exists to provide the desired solution, the construction phase assumes the characteristics of a rollout. Key considerations revolve not around code development but around applying the packaged software in the target sites. Key concerns are as follows:
§ Integration with existing systems (if necessary)
§ Database population plans
§ Interfaces with I/O devices
§ Any necessary modifications of the off-the-shelf software
§ User training
§ Ongoing support
The use of pilot or prototype systems is encouraged as a means of continuing to align user expectations for leveraging the application. Working pilots in plants are an excellent means of identifying potential benefits of the application if a solid base case is first established for comparison. Pilots serve as a platform for technical and performance evaluations while providing a test bed for the user community before full implementation or rollout.
Planning the Applications Platform
The analyst and designers must plan for leveraging from the initial phases of the project. Common database platforms, common user interfaces, and even common I/O drivers are not sufficient to realize the full benefits from leveraging. Exhibit 2
presents an overview of an applications platform and illustrates delivery of leveraged applications.
Exhibit 2. Rollout Concept
Beginning with the database, standards should be set around database configuration. If the database engine is relational, then the data model becomes the common basis of configuration. If the database is part of a real-time process control system, then standards could include tag naming conventions, data types, screens, process icons, trends, and SPC
charts.
Layered over the database engine are the applications that will operate on data in the database. The applications should be sufficiently complete that only database population need occur once the systems are delivered to the site. This means metadata is known and fixed. Similarly, user screens are complete and ready to work out of the box. Process control systems that use configurable graphical user interfaces are a convenience and a luxury if uniquely configured for each site.
Common graphical user interface screens with generic capabilities from site to site offer greater economy to create and less cost to support. Where graphical screens are being leveraged across multiple sites, there is usually sufficient economy created by the leveraging approach to produce higher-quality graphics. The quality of the delivered applications should rise with leveraging.
Ideally, applications can be made operational quickly once hardware and system-level software are operational. A factory acceptance test should be performed where the complete system is staged, integrated, and checked out before rollout.
CONCLUSION
There are organizational implications in any effort to leverage software effectively.
Leveraged software development and support requires the cooperation of multiple sites beginning with the initial phases of the process.
It is also appropriate to point out that the business model for leveraging software, reviewed in this chapter, implies fewer contributors to the effort. The need to have a different system integrator provide development or application programming per site is diminished, if not eliminated. The leveraged application work group is likely to find that the applications can be made operational with a small dedicated team systematically moving from site to site.
Chapter 37: Managing Legacy Assets
Christopher Slee
Malcolm Slovin
OVERVIEW
To discuss the legacy issue is to raise fundamental questions about how the Information Systems (IS) organization optimizes the use of information technology (IT) in the business. Instead of viewing legacy applications in purely technological terms, managers must look at the processes that generated these applications in such a way to make them problematic. This shift in perspective requires that legacy issues be understood within a larger business context.