Difference between revisions of "Enabling Businesses and Enterprises"

Revision as of 14:25, 3 June 2011

This chapter demonstrates how businesses and enterprises set themeselves up to do Systems Engineering (SE) , hand how they manage and align SE actiivities to thier purpose and goals. It shows senior Systems engineering and Technical leaders were to find the information and evidence to do thier jobs better.

Topics

The topics contained within this knowledge area include:

It must be emphaised that the section focuses on how to organise to do Systems Engineering - there is an assumption that the value of performing Systems Engineering is recognised . Businesses and enterprises vary enormously in purpose, scope, size, culture and history (see introduction to part 4 - add link), and so the way the organisation sets up to perofrm Systems Engineering needs to be tailored according to the specific situation.

This section discusses the implementation of SE organization level, 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 organization, and must fit into both cultures and process environments. [In (ISO, 2008) and (INCOSE 2010a) the word “organization” is defined as “person or a group of people and facilities with an arrangement of responsibilities, authorities and relationships”, which is consistent with the usage in this chapter. In practice, these references tend to use the word “organization” specifically to refer to the business or enterprise level.]

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 organsiaiton 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. Organizations manage people and process. The “what” and “why” of these issues is discussed in this section within the overall organization framework. This sets the context for the Systems engineering in teams and by individuals discussed in other sleements of part 4.

Fundamentals of Organizations

check how much of this covered in intro to part 4 Any organization has purpose, context and scope. This is defined by its sponsors and investors, and modified by which of its activities turn out to be most valued by its “customers”.

There are three basic types of business model. Commercial products – the same system/service sold to many customers. The requirements come from marketing based on understanding the market, relevant regulation and legislation, and good ideas from within the organization (Pugh 1991), (Reinertsen and Smith 1997). (Sillitto (1999) contends that commercial product development is a form of systems engineering, with adapted techniques for requirements elicitation and validation. Tailor-made system/service solutions are typically specified by the customer. The supplier responds with proposed solutions. This “contract driven” style of systems engineering is common in defence, space, transport, energy and civil infrastructure. In a product platform or product line approach (Simpson et al, 2006), a high value product or service is customised for each customer or market segment using common elements. This is more complex both technically and organizationally than the other models. Careful management is needed to make sure the benefits of the approach and the flexibility it offers are realized in practice. Two particular risks are that project teams: may deviate from the product policy under pressure to meet specific customer requirements or perceptions; or, conversely, may attempt to apply a common solution across too wide a market segment. There are a number of examples of good practice in product line e.g. automotive, FPGA families, Airbus A318-21, Nokia, Erikson, HP. References include, for Software: a series of SEI publications summarized in e.g. (Pastek et al, 2009); and for Systems, e.g. (Sillitto et al, 2001).

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. Put in figure 54 from original chapter 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 sub-section go into further detail of how an organisation strucutres to do SYstems engineering, integrating with its other functions, decided and priroitises its Systems Engineering capapbilities, developed and improves its capabilities (organizational learning) and the impact of culture. <add specific links to the topics>.

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