Related Business Activities
Lead Authors: James Martin, Dick Fairley, Bud Lawson
The following business management activities can be supported by enterprise systems engineering (ESE) activities:
- mission and strategic planning,
- business processes and information Management,
- performance management,
- portfolio management,
- resource allocation and budgeting, and
- program and project management.
Introduction
The figure below shows how these business activities relate to each other as well as the relative scope of ESE and product systems engineering (PSE) (Martin 2010 and 2011). PSE is mainly involved at the project level and collaborates with project management activities, and gets somewhat involved in program management and the resource allocation and budgeting activities. On the other hand, ESE is heavily involved in the higher level activities from the program management level and up. Both ESE and PSE have key roles to play in the enterprise.
Shown in this manner, these business activities can be considered to be separate processes with a clear precedence in terms of which process drives other processes. TSE uses “requirements” to specify the essential features and functions of a system. An enterprise, on the other hand, typically uses goals and objectives to specify the fundamental characteristics of desired enterprise operational capabilities. The enterprise objectives and strategies are used in portfolio management to discriminate between options and to select the appropriate balanced portfolio of systems and other enterprise resources.
The first three activities listed above are covered in Enabling Businesses and Enterprises. The other business management activities are described in more detail below in regards to how they relate to ESE.
Business Management Cycles
PDCA stands for "plan-do-check-act" and is a commonly used iterative management process as seen in the figure below. It is also known as the Deming circle or the Shewhart cycle after its two key proponents (Deming 1986; Shewhart 1939). ESE should use the PDCA cycle as one of its fundamental tenets. For example, after ESE develops the enterprise transformation plan, execution of the planned improvements are monitored (i.e., “checked” in the PDCA cycle) to ensure they achieve the targeted performance levels. If not, then action needs to be taken (i.e., “act” in the PDCA cycle) to correct the situation and re-planning may be required. ESE can also use the PDCA cycle in its support of the 'business as usual' efforts, such as the annual budgeting and business development planning activities.
It is also worth mentioning the utility of using Boyd's OODA loop (observe, orient, decide, and act) to augment PDCA. This could be accomplished by first using the OODA loop (http://en.wikipedia.org/wiki/OODA_loop), which is continuous in situation awareness, and then followed by using the PDCA approach, which is discrete, having goals, resources, usually time limits, etc. (Lawson 2010).
Portfolio Management
Program and project managers direct their activities as they relate to the systems under their control. Enterprise management, on the other hand, is involved in directing the portfolio of items that are necessary to achieving the enterprise goals and objectives. This can be accomplished by using portfolio management:
Project Portfolio Management (PPM) is the centralized management of processes, methods, and technologies used by project managers and project management offices (PMOs) to analyze and collectively manage a group of current or proposed projects based on numerous key characteristics. The objectives of PPM are to determine the optimal resource mix for delivery and to schedule activities to best achieve an organization’s operational and financial goals―while honoring constraints imposed by customers, strategic objectives, or external real-world factors. (http://en.wikipedia.org/wiki/Project_portfolio_management)
The enterprise may not actually own these portfolio items. They could rent or lease these items, or they could have permission to use them through licensing or assignment. The enterprise may only need part of a system (e.g., one bank of switching circuits in a system) or may need an entire system of systems (SoS) (e.g., switching systems, distribution systems, billing systems, provisioning systems, etc.). Notice that the portfolio items are not just those items related to the systems that systems engineering (SE) deals with. These could also include platforms (like ships and oil drilling derricks), facilities (like warehouses and airports), land and rights of way (like railroad property easements and municipal covenants), and intellectual property (like patents and trademarks).
The investment community has been using portfolio management for a long time to manage a set of investments to maximize return for a given level of acceptable risk. These techniques have also been applied to a portfolio of “projects” within the enterprise (Kaplan 2009). However, it should be noted that an enterprise is not merely a portfolio of projects. The enterprise portfolio consists of whatever systems, organizations, facilities, intellectual property, and other resources that are needed to help the enterprise achieve its goals and objectives.
Portfolio management in the context of ESE is well addressed in the following article: http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/enterprise_planning_management/portfolio_management.html (MITRE 2010).
Resource Allocation and Budgeting
The resource allocation and budgeting (RA&B) activity is driven by the portfolio management definition of the optimal set of portfolio elements. Capability gaps are mapped to the elements of the portfolio, and resources are assigned to programs (or other organizational elements) based on the criticality of these gaps. Resources come in the form of people and facilities, policies and practices, money and energy, and platforms and infrastructure. Allocation of resources could also involve the distribution or assignment of corporate assets, like communication bandwidth, manufacturing floor space, computing power, intellectual property licenses, and so on. Resource allocation and budgeting is typically done on an annual basis, but more agile enterprises will make this a more continuous process. Some of the resource allocation decisions deal with base operational organizations that are not project related.
It is sometimes the case that RA&B is part of portfolio management (PfM). But as can be seen in Figure 1, it is sometimes useful and practical to separate these two activities. PfM usually recommends changes to the enterprise portfolio, but RA&B takes these PfM considerations into mind along with inputs from the business process and information management and the performance management activities. Furthermore, PfM is usually an annual or biannual activity whereas RA&B is often done more frequently. RA&B may need to execute ad hoc when perturbations happen, such as funding cuts, schedule slips, performance targets missed, strategic goals changed, and so on.
Program and Project Management
Within the enterprise, TSE is typically applied inside a project to engineer a single system (or perhaps a small number of related systems). If there is a SoS or a large, complex individual system to be engineered, then this might be handled at the program level, but is sometimes handled at the project level, depending on the size and complexity of the system-of-interest (See also Complexity).
There are commonly three basic types of projects in an enterprise. A development project takes a conceptual notion of a system and turns this into a realizable design. A production project takes the realizable design for a system and turns this into physical copies (or instantiations). An operations “project” directly operates each system or supports the operation by others. (Base operations are sometimes called "line organizations" and are not typically called projects per se, but should nonetheless be considered as key elements to be considered when adjusting the enterprise portfolio.) The operations project can also be involved in maintaining the system or supporting maintenance by others. A program can have all three types of projects active simultaneously for the same system, as in this example:
- Project A is developing System X version 3.
- Project B is operating and maintaining System X version 2.
- Project C is maintaining System X version 1 in a warehouse as a backup in case of emergencies.
Project management uses TSE as a tool to ensure a well-structured project and to help identify and mitigate cost, schedule, and technical risks involved with system development and implementation. The project level is where the TSE process is most often employed (Martin 1997; ISO/IEC/IEEE 2015; Wasson 2006; INCOSE 2010; Blanchard and Fabrycky 2010).
The Office of Government Commerce provides a useful distinction between programs and projects:
The ultimate goal of a Programme is to realise outcomes and benefits of strategic relevance. To achieve this, a programme is designed as a temporary flexible organisation structure created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organisation’s strategic objectives...
A programme is likely to have a life that spans several years. A Project is usually of shorter duration (a few months perhaps) and will be focussed on the creation of a set of deliverables within agreed cost, time and quality parameters. (OGC 2010)
Enterprise Governance
ESE is also concerned with the way in which organizations and embedded management and technical functions work together to achieve success at the enterprise level. Governance frameworks provide the essential additional structure and controls needed to both ‘steer a steady ship’ (during business as usual) and to ‘plot a course to a new place’ (during business transformation).
Such frameworks can be designed by recognizing that there are enduring management concerns that need to be addressed and by applying the principle of economy. For example, a particular concern for most organizations is linking the control of projects to business drivers and objectives. This leads to a requirement for a governance body to both approve the initiation of projects, and to regularly review their progress, continuing relevance, and if necessary, mutual coherence in the light of developments inside and outside the enterprise.
This might be achieved by delegating some or all of the roles; depending on circumstances, the enterprise might be driven towards top-down or a more collective, peer-to-peer approach—or even a combination of the two for different functions. Governance bodies and management roles can be engineered in this way against a common set of management concerns. Governance may also include the maintenance of common technical standards and their promulgation and use throughout relevant projects. See Bryant (2012) for more information on governance.
Multi-Level Enterprises
An enterprise does not always have full control over the ESE processes. In some cases, an enterprise may have no direct control over the resources necessary to make programs and projects successful. For example, the Internet Engineering Task Force (IETF) is responsible for the “smooth operation of the Internet,” yet it controls none of the requisite resources.
The Internet Engineering Task Force (IETF) is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. … The actual technical work of the IETF is done in its working groups, which are organized by topic into several areas (e.g., routing, transport, security, etc.). Much of the work is handled via mailing lists. The IETF holds meetings three times per year. (IETF 2010a)
The IETF has “influence” over these resources even though it does not have direct control: "The IETF is unusual in that it exists as a collection of happenings, but is not a corporation and has no board of directors, no members, and no dues" (IETF 2010b).
The ESE processes might be allocated between a “parent” enterprise and “children” enterprises, as shown in the figure below (Martin 2010). The parent enterprise, in this case, has no resources. These resources are owned by the subordinate child enterprises. Therefore, the parent enterprise does not implement the processes of resource allocation and budgeting, program management, and project management.
The parent enterprise may have an explicit contract with the subordinate enterprises, or, as in some cases, there is merely a “working relationship” without the benefit of legal obligations. The parent enterprise will expect performance feedback from the lower level to ensure that it can meet its own objectives. Where the feedback indicates a deviation from the plan, the objectives can be adjusted or the portfolio is modified to compensate.
Enterprises X, Y, and Z in the situation shown above will cooperate with each other to the extent that they honor the direction and guidance from the parent enterprise. These enterprises may not even be aware of each other, and, in this case, would be unwittingly cooperating with each other. The situation becomes more complex if each enterprise has its own set of strategic goals and objectives as shown in the figure below.
These separate, sub-enterprise objectives will sometimes conflict with the objectives of the parent enterprise. Furthermore, each subordinate enterprise has its own strategic objectives that might conflict with those of its siblings. The situation shown here is not uncommon, and illustrates an enterprise of enterprises, so to speak. This highlights the need for the application of SE at the enterprise level to handle the complex interactions and understand the overall behavior of the enterprise as a whole. TSE practices can be used, to a certain extent, but these need to be expanded to incorporate additional tools and techniques.
References
Works Cited
Bryant, P. 2012. "Modelling Governance within Business Architecture using Topic Mapping." Presented at 22nd Annual International Council on Systems Engineering (INCOSE) International Symposium, July 9-12, 2012, Rome, Italy.
Blanchard, B.S., and W.J. Fabrycky. 2011. Systems Engineering and Analysis, 5th ed. Englewood Cliffs, NJ, USA: Prentice-Hall.
Deming, W.E. 1986. Out of the Crisis. Cambridge, MA, USA: MIT Press, MIT Center for Advance Engineering Study.
IETF. 2010a. "Overview of the IETF," in Internet Engineering Task Force, Internet Society (ISOC) [database online]. Accessed September 6, 2011. Available: http://www.ietf.org/overview.html.
IETF. 2010b. "The Tao of IETF: A Novice’s Guide to the Internet Engineering Task Force (draft-hoffman-tao4677bix-10)," in Internet Engineering Task Force, Internet Society (ISOC) [database online]. Accessed September 6, 2011. Available: http://www.ietf.org/tao.html#intro.
INCOSE. 2012. Systems Engineering Handbook, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE). INCOSE-TP-2003-002-03.2.2.
ISO/IEC/IEEE 2015. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2015.
Kaplan, J. 2009. Strategic IT portfolio management: Governing enterprise transformation. Waltham, Massachusetts, USA: Pittiglio, Rabin, Todd & McGrath, Inc. (PRTM).
Lawson, H. 2010. A Journey Through the Systems Landscape. Kings College, UK: College Publications.
Martin, J.N. 2011. "Transforming the Enterprise Using a Systems Approach." Presented at 21st Anniversary International Council on Systems Engineering (INCOSE) International Symposium, June 20-23, 2011, Denver, CO, USA.
Martin, J.N. 2010. "An Enterprise Systems Engineering Framework." Presented at 20th Anniversary International Council on Systems Engineering (INCOSE) International Symposium, July 12-15, 2010, Chicago, IL, USA.
Martin, J.N. 1997. Systems Engineering Guidebook: A Process for Developing Systems and Products, 1st ed. Boca Raton, FL, USA: CRC Press.
MITRE. 2012. "Enterprise Engineering," in Systems Engineering Guide. Bedford, MA, USA: MITRE Corporation. Accessed July 8, 2012. Available: http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/.
OGC (Office of Government Commerce). 2010. Guidelines for Managing Programmes: Understanding programmes and programme management. London, UK: The Stationery Office.
Shewhart, W.A. 1939. Statistical Method from the Viewpoint of Quality Control. New York, NY, USA: Dover Publications.
Wasson, C.S. 2006. System Analysis, Design and Development. Hoboken, NJ, USA: John Wiley and Sons Ltd.
Primary References
Martin, J.N. 2011. "Transforming the Enterprise Using a Systems Approach." Presented at 21st Anniversary International Council on Systems Engineering (INCOSE) International Symposium, June 20-23, 2011, Denver, CO, USA.
Martin, J.N. 2010. "An Enterprise Systems Engineering Framework." Presented at 20th Anniversary International Council on Systems Engineering (INCOSE) International Symposium, July 12-15, 2010, Chicago, IL, USA.
Additional References
Arnold, S., and H. Lawson. 2004. "Viewing Systems from a Business Management Perspective." Systems Engineering. 7 (3): 229.
Beimans, F.P.M., M.M. Lankhorst, W.B. Teeuw, and R.G. van de Wetering. 2001. "Dealing with the Complexity of Business Systems Architecting." Systems Engineering. 4 (2): 118-133.
Drucker, P.F. 1994. "The Theory of Business." Harvard Business Review. 72 (5): 95-104.
Haeckel, S.H. 2003. "Leading on demand businesses–Executives as architects." IBM Systems Journal. 42 (3): 405-13.
Kaplan, R., and D. Norton. 1996. The balanced scorecard: Translating strategy into action. Cambridge, MA, USA: Harvard Business School Press.
Lissack, M.R. 2000. "Complexity Metaphors and the Management of a Knowledge Based Enterprise: An Exploration of Discovery." PhD Dissertation in Business Administration. Henley-on-Thames, UK: Henley Management College, University of Reading.
Rechtin, E. 1999. Systems Architecting of Organizations: Why Eagles Can't Swim. Boca Raton, FL, USA: CRC Press, Taylor and Francis Group.