LEVERAGING DEVELOPED SOFTWARE:
ORGANIZATIONAL IMPLICATIONS
Hal H. Green and Ray Walker INSIDE
Assessing Preparedness for Leveraging, Leveraged Application Work Groups, Delivering Leveraged Applications, Planning the Applications Platform
INTRODUCTION
Leveraging is the reusability or portability of application software across multiple business sites. The extent to which an application can remain unchanged as it is installed and made operational at each location is referred to as leveragability.
Leveraging can reduce the cost of acquiring and maintaining application software. However, the ultimate measure of leveraging is the resulting business benefit – the cost of delivering a working capability from site to site across an enterprise.
Whether a manufacturer chooses an off-the-shelf or custom software solution, achieving leveraging requires the cooperation of multiple sites, beginning with the initial phases of the process. In downsized companies and companies with greater decentralization of decision making, this type of business-wide effort can become difficult. This is especially true when the application is not necessarily a supply-chain level application but one affecting more directly the manufacturing process.
ASSESSING PREPAREDNESS FOR LEVERAGING
Where a leveraging opportunity exists, limiting the scope of the target sites to a common business, product type/configuration, or other shared interest may mitigate some of the management challenges to leveraging. This strategy contains the leveraging activity to sites that are likely to benefit most. These sites are likely to be willing to compromise on functional requirements to realize the reduced costs of acquiring and supporting the leveraged application.
PAYOFF IDEA
Leveraging application software is a business objective that seeks to provide common solutions across numerous sites. A business-wide effort to leverage application software has organizational implications. Roles and responsibilities of the analysis team and the user community are described within a manufacturing context. The technical aspects of leveraging are discussed in article 1-05-30, “Leveraging Developed Software: An Economic Perspective."
Analysis Team Responsibilities
Leveragability of software is affected by the initial choice of platforms. Ideally, the application should result from a rigorous data and function-modeling phase that clearly depicts the natural systems of the sites. All too often hardware, operating systems, and data base platforms are the decisions that precede, shape, and limit the follow-on choices. As is the case for all good design practice, business requirements should drive technical architecture, not the other way around.
If a solid data and function model exists for each site, the choice of acquiring or developing software becomes clearer. When an off-the-shelf application exists serving most of the business needs, then the choice becomes a selection between vendors’ offerings relative to the specification. When no commercial offering exists on the market that satisfies the site’s information model, then new development or modification of some existing software are the obvious choices. In either case, the following questions
are germane to understanding the number of sites that can apply the application to be acquired or developed:
• Will changes in product or the manufacturing differences effect the applications?
• How do manufacturing business practices change from site to site?
• What types 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 the 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-a-vis the applications are 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 requirement 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:
• The user community. Users provide the business objectives and needs.
• 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 CASE tools or 4GL tools are employed, the data and functional specification are foundational to the applications. Fourth-generation client/server tools that allow de-coupling of client processes from the data base 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 business-wide or corporate-wide 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 program’s success.
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 this site’s learnings will be the basis for deployment at additional sites. After installation at several sites, the work group compiles all the installation learnings and benefits 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:
• 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 at the same time 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.
Beginning with the database, standards should be set around database configuration. If the data-base engine is relational, then the data model becomes the common basis of configuration. If the datadata-base 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 such that only database population need occur once the systems are delivered to the site. This means meta data is known and fixed. Likewise, 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 GUI 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 go up with leveraging.
Ideally, applications can be made operational quickly once hardware and system-level software is operational. A factory acceptance test should be performed where the complete system is staged,
CONCLUSION
There are organizational implications in any effort to effectively leverage software. 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 article, 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.
