Determining Needed Systems Engineering Capabilities in Businesses and Enterprises

A key part of Enabling Businesses and Enterprises to Perform Systems Engineering is deciding on the desired systems engineering capabilities within the business and/or enterprise. First, the Organizational Purpose must be understood, then the value that systems engineering can provide is determined. Understanding the value that SE can provide within the organization in support of Organizational Purpose is the starting point for deciding the desired SE capabilities. This topic summarizes the issues that drive the decisions about desired SE capabilities for the business or enterprise. This has to take into account the factors that cause organizations to be different, so the topic also discusses the organizational design decisions and issues that may arise; and also how SE may interact with other functional areas in the organization, and what needs to be done to ensure that SE delivers maximum value to the organization.

Once the SE capabilities of the business and enterprise are determined, these capabilities are divided among organizations, teams and individuals. Determination of team SE capability is discussed in the topic Determining Needed Systems Engineering Capabilities in Teams, and the individual SE competencies are discussed in the topic Roles and Competencies.

The capability to perform systems engineering includes factors such as having competent personnel, adequate time, sufficient resources and equipment, and appropriate policies and procedures. The SE capability of a business or enterprise is dependent on all these factors. Social dynamics at the team and organizational levels also influence the SE capability realized.

Relationship of this topic to Enterprise Systems Engineering

Enterprise Systems Engineering techniques can be used to establish needed SE capabilities. Architecture modeling and analysis enables better understanding of the dependencies between capabilities of nodes in the enterprise. At a high level of abstraction, the following are basic steps that could be used to decide on the desired SE capabilities within the business and enterprise.

1. Understand the context, including the factors shown in Table 1
2. Determine the required SE roles
3. Determine the competencies and capabilities needed for each of the SE roles
4. Assess the ability and availability of the needed SE organizations, teams, and individuals
5. Make adjustments to the required SE roles based on the actual ability and availability
6. Organize the SE function in a manner that facilitates communication, coordination, and performance.

See the topic Organizing Business and Enterprises to Perform Systems Engineering for additional information. More information on context and required SE roles is provided below.

Contextual Drivers

The following discussion, and the summary table below, illustrates some of the contextual factors and drivers that influence the SE capability needed by a business or enterprise.

Where the SE activities are performed in the value chain:

This discussion uses the concepts set out in the "Organizational contexts for SE" section in Enabling Businesses and Enterprises to Perform Systems Engineering.

The systems engineering approach adopted by the business or enterprise should depend on whether the organization is:

• The problem owner – focus will be on identifying and scoping the system problem, understanding the nature of the appropriate respondent system, defining its interdependencies and interoperability with other current and envisaged systems, and establishing the capacity and capability to acquire, integrate and operate the relevant system assets to deliver the intended benefit (it may be appropriate for such organizations to use enterprise systems engineering and capability systems engineering approaches)

• System operator – focus will be on establishing all the necessary components of capability (glossary?) defined by: the DoD as DOTMLPF – doctrine, organization, training, materiel, logistics, people, facilities; by UK MOD as TEPIDOIL – training, equipment, people, information, doctrine, organization, infrastructure, logistics; with similar equivalent breakdowns either explicit or implicit in other domains and organization) to deliver the required services to the problem owner, and on integrating new system assets into the system operation as they become available (see for example Kemp & Linton, 2008, “Service Engineering”, INCOSE IS 2008 Utrecht; the Service Systems Engineering section of the SEBOK; Elliott (Bruce) et al, “systems engineering on in service systems”, INCOSE UK Chapter 20??; -- )

• Prime contractor – focus will be on understanding customer needs and trading alternative solution approaches, then establishing a system team and supply chain to develop, deliver, support and in some cases operate the system solution. Depending on the level of complexity and scale, this may require enterprise SE and capability SE as well as “traditional” SE (INCOSE SE Handbook, NASA SE handbook, CMMI DEV – author’s comment, I am not sure that the INCOSE SE Handbook pays enough attention to trade studies and TRLs, which are emphasised in the NASA SE Hdbk)

• Subsystem/component developer – focus will be on understanding the critical customer and system integrator issues for the subsystem or component of interest to the developed, establishing the component or subsystem boundary definition, and integrating critical technologies possibly in an innovative way to create a competitive solution. Often the business model at this level of the supply chain will favour solutions that exploit re-usable elements and can be sold in identical or modified form to several customers. (INCOSE SE Handbook, CMMI DEV, Reinertsen “developing products in half the time”, Pugh 1991 “total design”)

• Specialist service provider – focus will be on specific process capabilities and competences which are sold on a time and materials or work package basis to any of the other kinds of business or enterprise. (ref e.g. CMMI for service, the specific process areas in SEBOK and INCOSE SE Handbook)

Where the business or enterprise operates in the lifecycle

The core systems engineering competencies and capabilities developed by the business or enterprise will depend on which system lifecycle phase(s) (glossary?) it operates in:

• Concept phase – SE in the concept phase requires the capability to identify a “problem situation”, define context and potential conops for a solution system, assess feasibility and affordability of a range of solution options in broad terms, analyse needs, determine appropriate options to consider further, and refine the definition to allow development of system requirements for the solution.

• Development phase – SE in the development phase requires the capability (including staff competence, organisational capability and enabling infrastructure, etc) to

o engage with concept studies to ensure the business or enterprise addresses opportunities it is competent to respond to o influence concept studies to ensure that specifications will be feasible and understood by the development organisation o establish how much trade space remains at the end of the concept study to calibrate the scope for innovation and optimisation in the development program o secure appropriate development work on appropriate terms o perform the system development activities defined elsewhere in the SEBOK, including architecture design, detailed definition of the system elements and their interfaces, and integration, verification, qualification and validation o produce definition data to allow the solution to be implemented, set to work, supported, operated and safely disposed of.

• Manufacturing phase – requires the capability to

o Configure the manufacturing and logistics systems for the system assets o manufacture, test, certify, control the configuration of, and deliver system assets, o to provide spares and repairs, manage obsolescence, - - as part of a logistic support service.

• In-service phase – requires the capability to

o maintain business continuity during the transition into operation of the new system, o bring the system into service, o integrate its capabilities into “business as usual”, o manage and sustain all components of capability including people, process and logistic support o maintain knowledge of the configuration (glossary?) of the deployed system(s) o monitor system performance and effectiveness during operation, o reconfigure the system to recover from performance drop-off and respond to emerging needs.

This requires the business or enterprise to be able to perform systems engineering at an operational tempo. See for example (Kemp & Linton, 2008) and (Bruce Elliott et al, ref to be confirmed, “In-Service Systems Engineering”)

• Retiral phase –requires the capability for ensuring the safe retirement of systems and keeping them in a state ready for re-activation (“mothballed”), or dismantling and recycling or safely disposing of the assets and their constituent parts.

The table below summarises the discussion above.

Table 1. Environmental factors in organizing to perform SE in a business or enterprise (Table Developed for BKCASE)

Environmental Factor	Examples
Where the SE activities are performed in the value chain: See the discussion on "Organizational contexts for SE" in Enabling Businesses and Enterprises to Perform Systems Engineering.	Whether the organization is: The problem owner, System operator, Prime contractor, Subsystem/component developer Or specialist service provider
Where the business or enterprise operates in the lifecycle	Concept Development Manufacturing In-service Retired
Nature of responsibility to end users	Explicit: clear requirements, prescriptive legislation Implicit: fitness for purpose, product liability
Nature of responsibility to customers	Outcome: deliver the intended benefits the system is expected to provide Output: deliver or operate the system or part of it against agreed acceptance criteria Activity: perform specified processes Resource: provide specified resource.
Scale of systems	Hitchins level (Hitchins 1995; Hitchins 2005) at which the organization operates: Level 1: Subsystem and technical artifacts Level 2: Project systems Level 3: Business systems Level 4: Industry systems Level 5: Societal systems
Complexity of systems integration task - Stupples levels, (Elliot et al. 2007; Sillitto 2011)	Within a discipline (e.g., software, electronics) Multiple disciplines (e.g., software, hardware, optics, mechanical) Socio technical systems integration Environmental integration
Criticality of system and certification requirements	Safety, Security Ethics, Environment, etc.
Nature of contract	Fixed price or cost plus Mandated work share arrangements
Nature and predictability of problem domain	Well defined and slowly changing steady state Poorly defined and rapidly changing, operators subject to unpredictable and evolving threats (e.g. defense)
Fundamental risks and design drivers in solution domain	Stable, low rate of technology evolution, systems use mature technology Rapid technology evolution, pressure to bring new technologies rapidly to market/ into operational use Lead time expectations versus level of integrity/certification
Competitive situation and business goals	Do existing business better Recover from a competitive shock or a shift in clients' expectations Develop a new generation product or service Enter a new market Reposition the business or enterprise in the value chain
Type of system or service	Product or productized service Custom solution (product or service) Tailored solution based on standard product and/or service elements

Required SE Roles

Enterprise Systems Engineering techniques can be used to establish needed SE capabilities from first principles. This implies the need for an enterprise systems engineering team, either permanent or ad hoc, that has both the necessary enterprise SE skills and the necessary influence with senior decision makers in the organization.

After understanding the context for the business and/or enterprise, the next step is to determine the required SE capabilities. The SEI Capability Maturity Models for Acquisition, Development and Services (SEI 2010) provide a framework for selecting systems engineering capabilities relevant to different types of business and enterprise.

The SE roles and competencies the organization needs to develop depend on the capabilities it needs to do its business, and on the type of organizational model selected for the business or enterprise. Existing SE competency models can be used to assist in determining the needed capabilities. An example is the INCOSE SE Competencies Framework (INCOSE 2010b). See the Roles and Competencies topic for more information on competency models.

As shown in Figure 1 below, management action on workforce development will be required if there are systemic mismatches between the competencies required to perform systems engineering roles and the actual competencies of individuals. Organizational culture may have a positive or negative effect on team performance and overall value added by the business or enterprise.

Figure 1. Culture, Competence, Team Performance and Individual Competence (Figure Developed for BKCASE)

Need for Clarity of SE Approach, and Dangers in Implementing SE

In any organization where activities and skills are shared, there is always a danger of silos or duplication. One of the purposes of SE is to reduce this risk – consider the interface or glue role (Sheard 1996), or the idea that “SE is good engineering with special areas of emphasis, … including interfaces between disciplines” (Blanchard and Fabrycky 2005).

Clarity on how the organization does SE is important. Typically, implementing SE may be part of an organization improvement, so Kotter’s principles on creating a vision, communicating the vision and empowering the others to act on the vision are most relevant (Kotter 1995). The way an organization chooses to do systems engineering should be part of the vision of the organization – and must be understood and accepted by all.

Many of the major obstacles in systems engineering deployment are cultural (see Culture).

Systems engineering can make a very powerful contribution to the organization’s quality goals. Embedding SE principles, processes and methods in the organization’s quality management system means that senior management and the quality system will help embed SE in the organizational business process and make sure it is applied (INCOSE 2011; ISO 2008).

One of the lean enablers for SE (Oppenheim et al. 2010) is "pursue perfection". The means of improvement at business or enterprise level is discussed in detail elsewhere, but the starting point has to be deciding the SE capabilities the organization wants.

A business or enterprise is a system – and SE is one of the functions that system may need to perform. The specific requirements for the SE function can be derived from understanding what the overall system (the organization) needs to do, and from the relationship between SE and other functions within the organization at different levels. Ideally, there would be a tailored solution to an organization's SE requirements based on the unique set of purpose, scope, context, capability, and culture of each organization. Also, organizations change over time (learning, improving or losing capability) and so the balancing of SE with everything else keeps changing.

Balancing the need for a systematic and standardized approach to SE processes, such as defined in models and handbooks, with the flexibility inherent in systemic thinking is critical. Systems thinking helps the organization understand problem situations, remove organizational barriers and blockers, and make the most of the organizations technical capabilities (see (Beasley 2011), for example).

References

Citations

Beasley, R. 2011. "The Three T's of Systems Engineering." Paper presented at the 21st Annual International Council on Systems Engineering (INCOSE) International Symposium. June 2011. Denver, CO, USA.

Blanchard, B. and W. Fabrycky. 2005. Systems Engineering and Analysis, 4th edition. Upper Saddle River, NJ, USA: Prentice Hall.

Hitchins, D. 1995. "World Class Systems Engineering in The UK. Paper presented at the 1995 Euroforum Conference on Managing Systems Engineering for Competitive Advantage, 28-29 June 1995. London, UK.

Elliott, C. et al. 2007. Creating Systems That Work – Principles of Engineering Systems for The 21st century. London, UK: Royal Academy of Engineering. Accessed on September 14, 2011. Available at http://www.raeng.org.uk/education/vps/pdf/RAE_Systems_Report.pdf.

Hitchins, D. 2005. Systems Engineering 5 Layer Model. Accessed on September 14, 2011. Available at http://www.hitchins.net/5layer.html.

INCOSE. 2010. SE Competencies Framework, Issue 3. Somerset, UK: International Council on Systems Engineering (INCOSE), INCOSE Technical Product 2010-0205.

INCOSE. 2011. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.

ISO/IEC 2008. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2008.

Kotter, J. 1995. Leading Change: Why Transformation Efforts Fail. Boston, MA, USA: Harvard Business Review (March–April 1995).

Oppenheim et al. 2010. Lean Enablers for Systems Engineering. Hoboken, NJ, USA: Wiley Periodicals. Accessed September 2, 2011. Available at http://cse.lmu.edu/Assets/Lean+Enablers.pdf.

SEI. 2010. Capability Maturity Model Integrated (CMMI) for Development, version 1.3. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie Mellon University (CMU).

Sheard, S. 1996. "12 Systems Engineering Roles." Paper presented at the 6th Annual International Council on Systems Engineering (INCOSE) International Symposium. Boston, MA, USA. Accessed September 14, 2011. Available at: http://www.incose.org/educationcareers/PDF/12-roles.pdf.

Sillitto, H. 2011. "Unravelling Systems Engineers from Systems Engineering - Frameworks for Understanding the Extent, Variety and Ambiguity of Systems Engineering and Systems Engineers." Paper presented at the 21st Annual International Council on Systems Engineering (INCOSE) International Symposium. 20-23 June 2011. Denver, CO, USA.

Primary References

No primary references have been identified for version 0.5. Please provide any recommendations on primary references in your review.

Additional References

Rhodes, D. and G. Roedler (eds.). 2007. Systems Engineering Leading Indicators Guide, version 1.0. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2005-001-02. Accessed September 14, 2011. Available at http://www.afit.edu/cse/docs/pubs/SELeadingIndicators2007-0618.pdf.

---

<- Previous Article | Parent Article | Next Article ->