Information Management: Strategy, Systems, and Technologies

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

Auerbach Publications 1
Copyright  1994 by RIA Group
Leveraging Developed Software

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:

Auerbach Publications 2
Copyright  1994 by RIA Group
Leveraging Developed Software

• 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.

Auerbach Publications 3
Copyright  1994 by RIA Group
Leveraging Developed Software

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.

Auerbach Publications 4
Copyright  1994 by RIA Group
Leveraging Developed Software

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 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 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,
integrated, and checked out before rollout.

Auerbach Publications 5
Copyright  1994 by RIA Group
Leveraging Developed Software

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.

Auerbach Publications 6
Copyright  1994 by RIA Group