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. So understanding the value that Systems Engineering 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 Systems Engineering 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 Systems Engineering delivers maximum value to the organization.

Once the systems engineering 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 folowing are basic steps 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 table below provides a comprehensive list of contextual factors and drivers to be considered when deciding on the desired SE capability for a business and enterprise.

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	At which Hitchins level (Hitchins 1995; Hitchins 2005) is the organization operating: Level 1: Subsystem and technical artefacts 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 (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 "productised service" Bespoke 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; and 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 Systems Engineering 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).

It is important to have clarity on how the organization is doing its Systems Engineering. 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 will 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 to embed systems engineering and make sure it is applied [(INCOSE 2010a), (ISO 2008) and cross ref part 1?].

One of the lean enablers for systems engineering (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 systems engineering capabilities the organization wants.

A business or enterprise is a kind of system – and systems engineering is one of the functions the "system" may need to perform. The specific requirements for the systems engineering 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. So there has to be a tailored solution to an organization's SE requirements given the unique set of purpose / scope / context / capability / culture etc. of each organization. Also, organizations change over time (learning, improving or losing capability etc.) and so the balancing of SE with everything else keeps changing.

It is also important to balance the need for a systematic and standardized approach to SE processes (as defined in the INCOSE SE handbook for example) with the capability for systemic thinking in order to understand problem situations and apply appropriate Systems Thinking to "dissolve" organizational barriers and blockers, and to make most of “technical capabilities” the organization has that it wants to exploit (see Beasley 2011 for example).

References

Citations

• Beasley, R. 2011. The Three T's of Systems Engineering. Paper presented at the 2011 INCOSE International Symposium,June 2011, in Denver, CO, USA.
• Blanchard, B. and Fabrycky, W. 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 “Managing Systems Engineering for Competitive Advantage”, June 28-29 1995, at the Kensington Close Hotel in 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. http://www.raeng.org.uk/education/vps/pdf/RAE_Systems_Report.pdf
• Hitchins, D. 2005. Systems Engineering 5 Layer Model. Accessed at http://www.hitchins.net/5layer.html, last updated 2005.
• INCOSE.2010. INCOSE Systems Engineering Handbook. Version 3.2. San Diego, CA, USA: INCOSE.
• INCOSE.2010 SE Competencies Framework. INCOSE Technical Product 2010-0205, Issue 3. Somerset,UK: INCOSE.
• ISO/IEC 15288:2008.Systems and software engineering - System life cycle processes. Version 2. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC).
• 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. INCOSE Lean SE WG. Hoboken, NJ, USA: Wiley Periodicals, Inc.(2010) http://cse.lmu.edu/Assets/Lean+Enablers.pdf (Accessed September 2, 2011)
• 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 1996 INCOSE 6th Annual Symposium, Boston, MA, USA. Available at: http://www.incose.org/educationcareers/PDF/12-roles.pdf (Accessed September 2, 2011).
• 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 INCOSE International Symposium,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 Roedler, G. 2007. Systems Engineering Leading Indicators Guide.Version 1.0. INCOSE-TP-2005-001-02. San Diego, CA, USA: INCOSE. http://www.afit.edu/cse/docs/pubs/SELeadingIndicators2007-0618.pdf (Accessed September 2, 2011).

---

Article Discussion

[Go to discussion page]

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

Signatures

--Asquires 23:00, 29 August 2011 (UTC)

--Smenck2 19:26, 2 September 2011 (UTC)