Difference between revisions of "Enabling Businesses and Enterprises"

From SEBoK
Jump to navigation Jump to search
Line 31: Line 31:
 
*[[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.  
 
*[[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 assesses what SE capabilities it needs to fulfil its [[Organizational Purpose]]; (see [[Determining Needed Systems Engineering Capabilities in Businesses and Enterprises]])
 
  
 
===Do===  
 
===Do===  

Revision as of 17:01, 1 August 2011

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.

Concept Map for Businesses and Enterprises Topics

Plan

Do

Check

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.

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.

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”.

References

Citations

  • Blockley, David, and Godfrey, Patrick, 2000, “Doing It Differently – Systems For Rethinking Construction”, Thomas Telford Ltd
  • INCOSE 2010 a. “INCOSE Systems Engineering Handbook”, Version 3.2
  • INCOSE UK Chapter, Z-2 Guide, "Enabling systems engineering"
  • INCOSE UK Chapter, Z-3 Guide, "How Systems Engineering can save your business money",
  • ISO, 2008, ISO/IEC 15288:2008, “Systems and software engineering - System life cycle processes
  • Jackson, Scott. 2010. “Architecting Resilient Systems: Accident Avoidance and Survival and Recovery from Disruptions”. Wiley
  • Pastek, Donohoe, Mcgregor, “Formulation of a Production Strategy for a Software Product Line”, August 2009, http://www.sei.cmu.edu/reports/09tn025.pdf
  • 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
  • Simpson, Siddique and Jiao, “Product platform and product family design – methods and applications”, Springer Science + Business Media Inc, 2006

Primary References

None.

Additional References

None.


Article Discussion

[Go to discussion page]

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