Portfolio Management Challenges Addressed by Effective Practices

Table of Contents

• Executive Overview
• Background
• Current Situation
• Challenges and Opportunities
• A Portfolio Management Approach
• Proven Practices Available
• Conclusion

Executive Overview

Most end users today have a large collection of operations solutions that employ information technology (“operations IT”), each addressing a specific set of functional requirements.  These solutions can represent a significant investment in money and effort, just as is the case with physical assets, but where is Portfolio Management ?

Increasing and more sophisticated business needs and imperatives have led to solutions that automate many more functions than may have been common in the past.  Business changes such as mergers and divestitures bring together solutions from multiple sources, with associated management challenges.

To fully address the challenges and opportunities, it is best to view the complete list of solutions as a portfolio, managing them together, rather than making isolated decisions.

We’ve identified several practices that have been proven effective in addressing the challenges associated with portfolio management.  None are difficult to apply.  It is the combination of practices that is most effective.  While there is no “perfect” approach to managing a complex set of technologies, it is important to define and apply it in a repeatable fashion.  Solution suppliers use similar methods and practices to guide their development and marketing efforts.  Asset owners can derive similar benefits.  Those who fail to take steps to manage their technology are at danger of being managed by it.

Backgrounds

In simpler times, asset owners needing to automate all or part of their manufacturing process would acquire a control system (DCS or PLC) and perhaps a few software tools for support processes and replace these only when they no longer met their needs.  Much has changed since then.

The business need for more automated and efficient operations has led end users to acquire many more operations IT solutions.  Each of these is a combination of software and hardware products that have been configured to address a specific set of functional requirements.  These solutions can represent a significant investment in money and effort, just as is the case with physical assets.  In some cases there may be significant additional value in custom or proprietary intellectual property.   Business and technology drivers influence how these collections are managed.

Business Change

Business changes come in many forms.   Companies acquire or divest specific businesses or merge entire enterprises.  This often results in a change of accountability for the required information and control systems.  It is common for companies acquiring these systems to subject them to a different support strategy, including rationalizing duplicate systems.  They must make decisions about which systems should be advanced, retained, or retired.

Technology Change

The increased adoption of commercial-off-the-shelf (COTS) technology in operations information systems has increased pace of change in these systems.  This often strains the ability of the owning organization to respond.  Each area of the infrastructure is evolving rapidly, and entirely new areas are emerging.  Notable examples of this phenomenon are:

• Platforms – Server and client platforms (i.e., computers) may have a useful lifetime of only a few years, requiring a robust program of replacement.
• Networks – Although Ethernet-based networks are now ubiquitous, related technologies such as wireless networks are becoming much more common in operations.
• Security – The need to secure information and protect system integrity has become a major imperative over the past several years.  This leads to the addition of new technologies such as firewalls and network monitors into the operations environment.
• Industrial Internet of Things (IIoT) – Although the detailed implications are still developing, it seems safe to assume that the IIoT trend will also impact the management of IT solutions in manufacturing and operations.

Current Situation

Owner-operators today commonly own a large and complex collection of operations IT solutions.  This is often the result of a combination of forces, including:

• Availability of new solutions and capabilities
• Business needs to retain specific technology after it becomes mature or obsolete
• More diversity and some level of duplication resulting from mergers or acquisitions,
• Need to integrate products and technologies from a variety of sources and suppliers
• Increased interdependencies between business processes, and
• A shift away from proprietary or custom solutions to those based on commercial-off-the-shelf (COTS) technology

To manage these solution collections, more varied and complex decisions must also be made.  This is true for both the supplier who must select the best technology for their products and solutions, as well as the end user who must choose the best solutions for their environment.

Operations and engineering organizations within user companies that are accountable for these solutions have specific responsibilities that cannot easily be delegated to the internal or external IT provider.

Challenges and Opportunities

To respond to the above changes and drivers, asset owners must first conduct a thorough and complete analysis of what they have and how to best respond.  Many questions must be addressed to continue to get the maximum benefit from installed technology.  Examples include:

• What is the proper balance between customizing features to meet specific needs and creating more standardized systems that can be used in a broader range of applications?
• At what point can additional improvements in a solution no longer be justified?
• What are the implications of reducing or eliminating support for a particular solution?
• Are all necessary prerequisites in place to begin a broad implementation of a new solution?

Any organization that uses information systems must address these questions to be successful.  This requires a significant investment in terms of time and resources.  As solutions have become more complex, many companies have tried to reduce or eliminate this effort by shifting to commercial solutions from established vendors.

However, even if the purchased solution has not been enhanced or modified, technology advances such as improved hardware and software (operating systems and networks) result in changes to the system.  Responding to these changes can gradually increase the cost of owning and operating what is otherwise a stable system.  Commercial products are also frequently replaced with “new and improved” versions, bringing additional functions and changes to the computing infrastructure required to support them.  The lesson here is that changes will happen, whether planned or not.

With purchased solutions, it is also common to add or modify certain features to meet specific business needs.  This brings the challenge of striking a balance between providing systems that are tailored to specific business needs, and minimizing long-term cost using standard solutions.  For example, one could purchase and install a commercial production planning system, and then proceed to enhance or add functions using add-on software modules.  While this would lead to a solution more closely aligned to the needs for the specific business, each change or enhancement represents another hurdle to overcome when eventually migrating the system to a more recent version or new and improved product.

Few solutions exist in a vacuum.  The full benefit of a large technology project may only be realized after the new system has been integrated with the older existing systems.  But how does one determine the extent of integration required, and whether connections to specific systems are worth the investment? One possible approach to this problem can be described as “situational integration,” which is to say that we integrate our solutions where necessary, using a combination of custom and commercial tools, rather than designing an entirely integrated system from the ground up.  An analysis of business needs and the long-term investment required is needed to best determine what integration opportunities to pursue.

Additional questions to be answered relate to solution implementation and long-term support, such as:

• Will there only be a single implementation, or will it be cloned many times?
• Will support be provided from a single, central organization, or from some sort of distributed network?
• What technical skills are required to provide adequate support? Are they available, or is additional training required?
• Will any specialized training be required?

Planning for these activities must start early.  In fact, they provide some of the major criteria for solution selection.  There is benefit in spending the necessary amount of time and effort in the early stages of implementation projects, preparing supportable configurations and tailoring for easy deployment, focusing on the ultimate value at the end of this process.

Purchased solutions do not automatically address these issues or make them go away.  You still need some sort of “solution management” to ensure they are properly addressed.

A Portfolio Management Approach

To fully address the challenges and opportunities, it is best to view the complete list of solutions as a portfolio, managing them together, rather than making isolated decisions.

When they hear the term “portfolio management,” most people think of it in financial terms.   But, if we first think of them as the valuable assets that they are, the term applies equally well to managing a large collection of technology solutions.  The assets are not independent, and decisions made about one may have implications on the viability and value of others.

This simple shift of perspective is the first step in adopting a portfolio management approach.  Once this is complete, several simple but very effective practices can be applied to aid in decision making.  While none of these practices are particularly complex, combining them provides the basis for a powerful and consistent portfolio management system.

Proven Practices Available

There are several areas of portfolio management where a clear and consistent response is required.  These include:

• Role Definition – Portfolio management includes a range of tasks and responsibilities.  It is very important that these be assigned to clearly defined roles.
• Solution Lifecycle – Simple models are available that describe the phases of the solution lifecycle, from conception and specification through implementation, operation, and support.  Aligning activities and responsibilities to each of these phases helps determine accountability and associated performance metrics.
• Portfolio Identification – The primary prerequisite for effective management of a technology and solution portfolio is a detailed knowledge of its contents.  An inventory of installed systems is a starting point, but only the beginning.  The portfolio owner must also be able to describe each element in terms of version or revision levels, dependencies, and several other parameters.
• Architecture – Suppliers and asset owners have been using the term “architecture” in technology discussions for years.  Unfortunately, not everyone has the same definition, leading to confusion.  It is essential to have a clear structure for describing an architecture, including definitions of each of its major components.
• Technology Lifecycle – Portfolios and their contents are constantly evolving in responding to changing technology and requirements.   Components mature, and may eventually be replaced.  For this reason, the portfolio and its contents must be viewed as moving through phases of a lifecycle.
• Cost Estimation – Asset owners can use a simple economic model to characterize their investments in technology and make informed decisions about solution selection and application.

The following sections describe practices that have been proven to be effective in addressing the challenges in these areas.  None of the individual practices are difficult to apply.  It is the combination of practices that is most effective in portfolio management.

It is important to understand that the most important objective is consistency.   It is far less important to have the “perfect” approach to portfolio management than to define one and apply it in a repeatable fashion.  Solution suppliers use similar methods and practices to guide their development and marketing efforts.  Asset owners can derive similar benefits.

Role Definition

Perhaps the most fundamental practice is to identify and describe the essential roles required for portfolio management.  These roles are both organizational and individual.   Each role must be defined in terms of specific responsibility and accountability, as well as metrics for performance measurement.

The first step is to determine which organizations must have responsibilities in this area.  This subject has been debated and discussed under the heading of “IT/OT Convergence.” The most fundamental question that must be addressed is which organization owns the portfolio.  This is not to be confused with the organization that provides support.  The owning organization establishes requirements and makes investment decisions.

Once the owning organization has been identified, several key individual roles must be filled.

• An Asset Owner may be identified for a specific solution, a set of related solutions, or for the entire portfolio.  The key here is to have someone who is clearly accountable for making decisions about investments in the asset.  This includes improvements and possible replacement.
• The Architect or Designer has the responsibility for turning an investment decision into a solid design that meets stated requirements.  This may include identifying the implications for related solutions.
• The Developer or Integrator is responsible for the detailed implementation of the design.  This can include any combination of assembly or development.
• The Support Provider is responsible for regular support or maintenance of the solution.  This includes testing and applying regular updates, or replacing failed elements.

All but the first of these roles can be filled by contract personnel, if required.

Solution Lifeline

With the essential roles defined, another simple model can be useful in understanding the assignment of responsibilities.  Figure 1 describes a solution lifeline that defines the stages that any given solution progresses through, from product development to its eventual decommissioning or replacement.

At each stage, a specific role has primary accountability.  The product supplier is accountable for developing the products and technologies used in solutions, but the accountable party in most of the other phases is the asset owner.  Using a similar model helps all parties to understand not only their accountability, but also how they must interact with other key roles.

Portfolio Identification

With the roles and responsibilities established, the next task is to identify and characterize the contents of the portfolio.  This includes all hardware and software elements, the interdependencies, and the components of the underlying infrastructure.

Some asset owners will already have a current and accurate inventory of solutions, but in some cases, considerable effort may be required to assemble the information.  Regardless of how it is assembled, a simple list of portfolio elements is not sufficient.  Each element (i.e., solution, hardware, etc.) must also be described using a set of attributes that can assist in making decisions.  Table 1 describes several common examples.

Architecture

The term architecture has long been used in the context of technology planning, acquisition, and operation.  Unfortunately, this use is often vague, leading to potential ambiguity and confusion.  While several interpretations are possible, one successful practice is to consider an architecture to consist of the several distinct elements.

Reference Models

In a typical situation, the asset owner will base their specific architecture on an established reference model.  These models are often also key elements of common industry standards such as ISA-95/ISA 62264.  Perhaps one of the most widely known reference models are those originally developed as part of the Purdue Enterprise Reference Architecture (PERA).

The Collaborative Manufacturing Model (CMM) from ARC is a more recent example, and has the advantage of recognizing three separate axes, each corresponding to a specific set of connected business processes.  These axes provide a convenient framework for positioning specific systems or solutions and establishing relationships between them.

Reference models provide a good starting point, but the maximum value comes from applying the general concepts in these models to the specific situation.

Principles

The first step is to define the underlying principles that provide the conceptual foundation for the architecture and reflect how technology is used in the company.  They define the basis for decision-making related to the portfolio.  Examples include “Purchased solutions are preferred over those that are custom built,” or “Investment decisions are based on an assessment of costs across the entire lifecycle.”

It is difficult to over-emphasize the importance of well-defined principles in shaping the rest of the architecture.  While it is possible to phrase each principle as a simple statement, it is often useful to subject each to a more detailed analysis to ensure that all implications are clear.  Such an analysis should address several attributes.  Table 2 describes several examples.

Architecture Types

Although it is common to refer to “the architecture,” it is difficult or impossible to describe all aspects and implications using a single model or diagram.  To adequately address the needs and perspectives of a diverse set of stakeholders, an effective practice is to define the architecture from several different perspectives.

The business architecture describes the needs, expectations, and requirements in the context of business processes and associated organizations within the enterprise.  The goal is to position solutions within these processes, thus establishing ownership and primary accountability.

The purpose of the system architecture is to translate business processes into a set of solutions and systems that provide the necessary functionality.  Logical models describe systems in terms of the functions performed and major data flows required.

Technical architecture models describe the detailed components and infrastructure required to host and support the required solutions.  Examples include clients, servers, networks and communications protocols.  These may also be referred to as physical models.

The final layer or view of the architecture describes specific products or solutions that have been selected.  It may be as simple as a detailed list of solutions, identifying supplier, version number, and associated attributes.

Each of the above levels of the architecture have a specific purpose and intended audience, but are inter-related.  Functional requirements must first be defined at the business level and then used to drive more detailed requirements at each of the more detailed layers.  At the same time, implications arising from each layer are passed to the higher layers to adjust the response to requirements as necessary.

Technology Lifecycle

Information technology and related systems have a natural lifecycle.  Solution providers have some degree of control over certain aspects of this cycle because they control the release schedule for their solutions.

For asset owners, the choice may be when and how to adopt specific commercial solutions, or whether to develop custom solutions.  They must understand and manage the technology lifecycle, and plan the large-scale deployment of applications in a consistent and predictable manner.

In one simple version of the lifecycle, the X axis is time, while a typical value for the Y axis would be the number of systems or products in use.  Other values (for example, number of users, total investment, business value) could be used for the Y axis, but the basic shape of the curve would not change, since the purpose of the axis is to indicate a measure of “how much” a product or system is used.  The specific metric chosen should be one that is easily measured.

The details of this model are less important than acquiring or developing one, and taking the time to get everyone to understand the concepts depicted by it.  Simply having everyone working with the same set of concepts and terminology can provide tremendous benefit.

Phases

Figure 2 is a typical view of the technology lifecycle.  It describes four phases: emerging, standard, mature, and obsolete.  Alternate names might be introduce, promote, maintain, and retire.  Once again, the exact phase names used are not nearly as important as the concepts behind them.

The phases represent a continuum, with transition zones from one stage to another.  The duration and nature of this transition will vary from technology to technology.  As a technology moves from one stage to another, it will gradually adopt the characteristics of the new stage.  The most difficult decisions must be made while a solution is in these transition zones.  For example, exactly when should further installations of one solution end, and another begin?  Typically, the transition between one phase and the next is associated with a specific event.  These events can be thought of as inflection points in the curve.

Table 3 shows several typical attributes for each phase of the lifecycle.

It is also possible to describe each of the phases of the lifecycle from several different perspectives, such as development, implementation and support.  For example, a specific solution or portfolio element may be considered mature for implementation, but standard for support.

Cost Estimation

To make the best decisions in the selection and acquisition process, it is critical to have a firm understanding of the total cost of proposed solutions over their entire lifecycle.  Failing to consider all categories of cost of ownership can result in sub-optimal decisions and unnecessary expense.

A simple model has been applied for many years to manage investments in various types of portfolios.  It may not be the definitive or even the “best” approach, but simply one that has been applied successfully.

The first step involves grouping of costs (and benefits) into six essential categories, as shown in the following figure.

The top three categories correspond to initial or one-time activities, generally associated with acquiring and implementing the solution.  The second group represents activities or elements that occur over the entire lifecycle of the solution.  These are generally assessed on an annual basis.

• Acquisition includes elements and activities related to acquiring or purchasing technology, products, and services required to assemble the final solution.  These are all considered and included in the economic comparison of alternatives.  This includes all hardware and software system purchases for all solutions.  Activities in this category include bid preparation, proposal review, scope definition, site survey, and acquisition strategy definition.
• Design and assembly includes all the costs associated with creating the solution, including technology selection, infrastructure specification and justification, interface definition, and application design.
• Configuration and installation activities include debugging & checkout, training, commissioning, and the actual system startup.
• Design enhancement is typically done in response to new or changing requirements and depending on the extent and complexity may be structured as separate projects.
• Operation includes activities involved in the day-to-day operation of the solution.  They are often focused on some sort of execution monitoring for identifying problems.
• Maintenance includes activities geared toward keeping the solution operating efficiently.  This includes periodic upgrades (i.e., no new functionality), as well as tuning and small incremental expansion.

Conclusion

Applied consistently, a combination of the above practices can be very effective as part of a comprehensive portfolio management program.  None require specialized tools or expertise, but the results can be significant.  Based on ARC research and analysis, we recommend the following actions for asset owners:

• Characterize portfolio – Regardless of the more detailed practices used, the essential first step is to create a detailed description of all elements of the technology and solutions portfolio.
• Identify opportunities – Assessing the portfolio in the light of business needs and imperatives can lead to the identification of potential opportunities for improvement.
• Calibrate response – In most cases, the number of opportunities will exceed available resources.  It is essential to calibrate the response by prioritizing the opportunities and sequencing them in the form of an improvement plan.
• Decision Basis – Challenge yourself to articulate not only the results or implications of technology related decisions, but also the basis upon which they are made.  This avoids the perception that such decisions have been made arbitrarily.
• Engage supplier(s) – Portfolio planning is most effective when the process includes contributions from major suppliers.  In many cases, knowledge of their development plans will help in establishing timing and priorities.
• Management System – It is essential to apply each of the selected practices in the context of a carefully defined management system.

 

If you would like to buy this report or obtain information about how to become a client, please   Contact Us