Enabling Businesses and Enterprises

This chapter demonstrates how businesses and enterprises set themselves up to do Systems Engineering (SE), and how they manage and align SE activities to their purpose and goals. It shows senior Systems engineering and Technical leaders where to find the information and evidence to do their jobs better.

Businesses and enterprises usually adopt or enhance their systems engineering capability for one of four reasons:

to do current business better (typically some combination of faster, better, cheaper)
to respond to a disruption in the market place requiring them to change the way they do business - a competitive threat or new demands from customers
to reposition the business or enterprise in its value chain or open up a new market
to develop a new generation product or service.

How this section fits into rest of BKCASE

An organization is itself a kind of system, so much of the discussion describing systems elsewhere applies to the organsation doing the Systems Engineeering.

The business level of SE and the organization of the project define the purpose, context and scope for systems engineering management within projects, described in Part 3, Systems Engineering and Management.

This business or enterprise level of SE sets the context for the Systems Engineering performed by teams and by individuals, discussed in other elements of Part 5, Enabling Teams to Perform Systems Engineering and Enabling Individuals to Perform Systems Engineering.

Topics

The topics contained within this knowledge area include:

Logical flow between topics

The flow between the topics is shown in the following diagram, which is essentially a "plan - do - check - act" cycle.

Plan

Systems Engineering Governance sets the Systems Engineering Organizational Strategy. In so doing it is constrained by the purpose, context, scope, responsibilities and accountabilities of the business or enterprise. These may be developed by the Enterprise Systems Engineering activities, and/or flowed down from the level above, and/or negotiated with peers.
The business or enterprise assesses what SE capabilities it needs to fulfil its Organizational Purpose; (see Determining Needed Systems Engineering Capabilities in Businesses and Enterprises)
the business or enterprise organises to perform systems engineering (see Organizing Businesses and Enterprises to Perform Systems Engineering)

Do

SE is performed;

(see Part 3, Systems Engineering and Management)

Check

Performance is assessed. (See Assessing Systems Engineering Performance of Business and Enterprises )
Any gap between needed and achieved performance is identified.

Act

If there is a gap between actual and needed capabilities, measures are taken to develop or improve the capabilities, using the available levers to:

develop, redeploy or get new facilities, services, and individuals;
improve culture;
adjust organization;
adjust and align measures, goals and incentives
adjust the definition of the required capabilities;
and if necessary renegotiate scope, context, purpose, responsibility and accountability.

(See Developing Systems Engineering Capabilities within Businesses and Enterprises)

Businesses and enterprises vary enormously in purpose, scope, size, culture and history, so the way the organisation sets up to perform Systems Engineering needs to be tailored according to the specific situation, and will depend greatly on the level of understanding of the added value of systems engineering, and the organization's maturity and homogeneity.

This section discusses the implementation of SE in businesses and in enterprises , and is also relevant to extended enterprises and to projects that involve multiple “organizations”. This latter case is a particularly difficult challenge because the teams within the project have duties both to the project and to their parent business, and must fit into both cultures and process environments.

Organizational contexts for SE

There are five basic types of organizations that use SE or provide SE services:

• businesses with multiple projects;

• project spanning multiple businesses;

• SE team or project within either of the above;

• “Single project businesses”;

• the SE service supplier, that provides a specific SE capability or service (tools, training, lifecycle process) to multiple clients, either as an external consultancy or as an internal SE function.

The kind of business determines the scope and diversity of SE across the organization.

As systems become more interconnected, organizations become more interdependent, so they need to manage much higher levels of complexity. Organizational complexity is now a major risk factor in system development and operation (Sillitto, 2010a), (Jackson, 2010).

This is shown in abstract form in the “organizational coupling diagram” (below) to illustrate the fundamental form of an extended enterprise. This also shows how organizational structure tends to match system structure.

The “problem owners” are the people, communities or organizations involved in and affected by the “problem situation”. The problem they face, and the ultimate value of the system of interest, might be to defend a country, improve transport links in a community, or deal with an environmental challenge. The “respondent system” might be a new fighter, a new or improved transport infrastructure, or new low-emission electricity generation systems. So the “organizations responsible for the respondent systems” would be the air force, transport operator or regulator, or electricity Supply Company. The prime role of these organizations will be to operate the systems of interest to deliver value to the problem owners. They also need to manage the entire system lifecycle.

The detailed topics in this Knowledge Area go into further detail of how a business or enterprise determines and prioritises the Systems Engineering capabilities it needs (Determining Needed Systems Engineering Capabilities in Businesses and Enterprises), organizes to do Systems Engineering and integrates SE with its other functions (Organizing Business and Enterprises to Perform Systems Engineering), assesses Systems Engineerng performance (Assessing Systems Engineering Performance of Business and Enterprises), develops and improves its capabilities through organizational learning (Developing Systems Engineering Capabilities within Businesses and Enterprises) and the impact of Culture.

Culture

Goals, measures and alignment in an organisation

The alignment (or otherwise) of goals and measures across the enterprise strongly affects the effectiveness of systems engineering effort and the benefit delivered by SE to the enterprise. For example

(Blockley and Godfrey 2000) describe techniques used successfully to deliver a major infrastructure contract on time and within budget, in an industry normally plagued by adversarial behavior.

Lean thinking (Womack and Jones 1998, Oppenheim et al 2010) provides a powerful technique for aligning purpose to customer value – provided the enterprise boundary is chosen correctly and considers the whole value stream.

(Fasser & Brettner 2002, pp 18-19) see an organization as a system, and advocate three principles for organizational design: “increasing value for the ultimate customer”, “strict discipline”, and “simplicity”.

EIA 632 (EIA 1999) advocates managing all the aspects required for through-lifecycle success of each element of the system as an integrated “building block”. Similarly, (Blockley, 2010) suggests that taking a holistic view of “a system as a process” allows a more coherent and more successful approach to organization and system design, considering each element both as part of a bigger system of interest and as a “whole system” (a “holon”) in its own right.

(Elliott et al, 2007) advocate 6 guiding principles for “making systems that work”: “debate, define, revise and pursue the purpose”; “think holistic”; "follow a systematic procedure”; "be creative”; "take account of the people”; and “manage the project and the relationships”.

For organizations new to SE, the INCOSE UK Chapter has published a range of one-page guides on the subject, including enabling systems engineering and How Systems Engineering Can Save Your Business Money.

Citations in this section

INCOSE 2010 a. “INCOSE Systems Engineering Handbook”, Version 3.2

ISO, 2008, ISO/IEC 15288:2008, “Systems and software engineering - System life cycle processes”

Pugh, S. 1991. “Total Design: Integrated Methods for Successful Product Engineering”. Addison-Wesley

Reinertsen, D and Smith, P 1997, “Developing products in half the time, New Rules, New Tools”. Wiley

Sillitto, Hillary. 1999. “Simple Simon met a system”. Paper presented at 9th Annual INCOSE International Symposium

Sillitto, Hillary. 2010 a. “Design principles for Ultra-Large-Scale(ULS) Systems”. Paper presented at the 20th Annual INCOSE international Symposium, 2010

Sillitto, Mazzella, Fromenteau, 2001, “The development of Product Lines in THALES: methods, examples, lessons learnt”, Paper presented at the INCOSE UK Spring Conference 2001

Pastek, Donohoe, Mcgregor, “Formulation of a Production Strategy for a Software Product Line”, August 2009, http://www.sei.cmu.edu/reports/09tn025.pdf

Jackson, Scott. 2010. “Architecting Resilient Systems: Accident Avoidance and Survival and Recovery from Disruptions”. Wiley

Simpson, Siddique and Jiao, “Product platform and product family design – methods and applications”, Springer Science + Business Media Inc, 2006

References

Please make sure all references are listed alphabetically and are formatted according to the Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.

Citations

List all references cited in the article. Note: SEBoK 0.5 uses Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.

INCOSE UK Chapter, Z-2 Guide, "Enabling systems engineering"

INCOSE UK Chapter, Z-3 Guide, "How Systems Engineering can save your business money",

Primary References

All primary references should be listed in alphabetical order. Remember to identify primary references by creating an internal link using the ‘’’reference title only’’’ (title). Please do not include version numbers in the links.