Organizing Business and Enterprises to Perform Systems Engineering

From SEBoK
Jump to navigation Jump to search

Each organization is unique. The type and scope of the overall organization determines the particular way Systems Engineering is deployed and carried out to suit the purpose of the organization. A standard way of describing the capabilities needed is based on the Toyota (Morgan and Liker 2006) approach of considering people, processes and tools. This division is used to structure this topic, with the addition of some specific issues about SE and the enabling organization.

Components of business and enterprise SE capability

Governance of Systems engineering

Systems Engineering Governance establishes the SE Culture and approach, and defines how and by whom SE decisions are made, monitored, and measured in order to deliver business value.

Definition of roles

Systems engineering organizations need to establish a career structure for people management to cover three key issues for business success: how people are recruited, trained, allocated, supervised, promoted, and rewarded; how to optimize use of expertise, across projects and business units; and how to develop SE skills.

Sheard (1996) lists twelve system engineering roles. Sheard (2000)draws an important distinction between roles involved in the “discovery phase”, characterized by a high level of uncertainty, the “program phase”, which is more deterministic and defined, and the overall systems engineering “approach”. Kasser et al. (2009) identify five types of systems engineer distinguished by the need to work at increasing levels of abstraction, ambiguity, scope and innovation. Sillitto (2011a) discusses a number of systems engineering roles and the characteristics required of them, in the context of the wider engineering and business professional landscape.

Systems engineering exists within an enterprise “ecosystem”. There are two key points to consider:

  • Nurture and value the systems engineer. Doing systems engineering well is very hard. There must be a reward mechanism for these experts, which may go against the normal reward mechanism (e.g. rewarding fire-fighters or heroes).
  • The organization must “pull” value from the systems engineering, rather than the systems engineers “push”.

People

The roles people fill are defined by the organization (see Definition of Role subtopic above); the way people are used in teams is described in Enabling Teams to Perform Systems Engineering; and the development of individuals' SE competence is described in Enabling Individuals to Perform Systems Engineering. The key point to recognize here is that the roles, and the systems engineering competencies required in those roles, need to be defined at the organizational level.

Knowledge and information

There are two kinds of knowledge, explicit and tacit. Explicit knowledge can be written down or incorporated in computer codes, and can be treated as an asset. Much knowledge however is “tacit knowledge” that only exists within the heads of people, and in the context of relationships that people form with each other. So the ability of an organization to create value is critically dependent on the people it chooses to employ, what they know, how they work together, and how well they are organised and motivated to contribute to the organization’s purpose.

(Fasser & Brettner 2002) discuss knowledge management extensively, and emphasize the value of numerous mechanisms for informal knowledge transfer. They assert that “we may think that knowledge transfer is just an information technology issue, but in actuality, it is also a psychological, cultural, and managerial issue – in short a human issue”; and “only information in action can create knowledge”.

A “learning organization” aims to absorb, diffuse, generate, and exploit knowledge (Sprenger and Have 1996). Organizations need to manage formal information and facilitate the growth and exploitation of tacit knowledge. They should learn from experience and create a form of “corporate memory” – including process, problem domain and solution space knowledge, and information about existing products and services. (Fassner and Brettner 2002, 122-124) suggest that “shared mental models” are a key aspect of corporate knowledge and culture.

Organizations need to manage SE know-how, integration of SE with other organizational processes and activities, and knowledge of their business domain. Typical strategies include internal networks of SE leaders, experts, practitioners, reviewers, trainers, assessors; links from knowledge to organizational training and people development; and IT “Infostructure” to facilitate distributed working and cross-site collaboration. The INCOSE Intelligent Enterprise Working Group did a lot of work on knowledge management in an SE context, producing a “Concept of Operations for a Systems Engineering Educational Community” (Ring et al 2004)

Information has to be both shared and protected in complex organizations. Sharing is key to effective collaboration; it is constrained by the need to protect Intellectual Property, and commercially and nationally sensitive material. Different cultures and personal styles make best use of information presented in different ways and in different orders (i.e. in levels of abstraction, big picture first or detail, principles first or practical examples). (Sillitto 2011b) describes the knowledge management challenges for large multi-national organizations.

Projects need to manage project information, and establish configuration control over formal contractual information and information that defines the product/service being developed, supplied or operated. A key role of systems engineers is to “language the project” (Ring et al 2004). Good data management and tool support will allow people to “document once, use many times”, and ensure consistency of information over time and between different teams.

System information needs to be maintained throughout the life of the system and made available to relevant stakeholders – including those designing new systems that have to interface to the system of interest - to allow system management, maintenance, reconfiguration, upgrade and disposal, and forensics after accidents and near-misses. (Elliot et al 2008) suggest that information management is the dominant problem in systems engineering for in service systems, and that the cost and difficulty of establishing “current state” and legacy constraints before starting to implement a change is often underestimated.

Managing Organizations in a High-Risk Environment

Many industrial domains are subject to catastrophic events. Special managerial skills are required to manage these organizations and minimize these events. Organizations that possess these skills are called High Reliability Organizations (HROs), a term coined by Weick and Sutcliffe (Weick and Sutcliffe, 2001, p. 3). HROs are “organizations that operate under trying conditions and have fewer than their fair share of accidents.” Example HROs include “power grid dispatching centers, air traffic control systems, nuclear aircraft carriers, nuclear power generation plants, hospital emergency departments, and hostage negotiation teams.” Weick and Sutcliffe (Weick and Sutcliffe, 2001, p. 10) identify five hallmarks of HROs:

Preoccupation with failure

HROs do not ignore errors, large or small. They encourage reporting of errors. They learn from near misses. They avoid complacency. They avoid the temptation to reduce margins of safety.

Reluctance to simplify interpretations

HROs simplify less and see more. They position themselves to see as much as possible. They “encourage skepticism towards received wisdom.” They pay attention to the nuances that diverse people detect.

Sensitivity to operations

HROs pay attention to possible latent conditions, defined by James Reason (Reason, 1997) to be deficiencies in the system that have not yet resulted in an accident but are waiting to happen. They have well developed situational awareness and make continuous adjustments to keep errors from accumulating and enlarging.

Commitment to resilience

HROs keep errors small and improvise “workarounds that keep the system functioning.” They have a deep understanding of the technology and constantly create worst case situations to make corrections.

Deference to expertise

HROs “push decision making down.” Decisions are made “on the front line.” They avoid rigid hierarchies and go directly to the person with the expertise.

Process

Most systems engineering organizations maintain a set of organizational standard processes, integrated in their quality and business management system, adapted to their business, and with tailoring guidelines to help projects apply the standard processes to their unique circumstances. This is supported by a process group who develop and maintain the process assets, and support their deployment into business units and projects. Guidance on organizational process management is provided by CMMI (SEI 2010) which has two process areas on organizational process: OPD (Organizational Process Development), which is concerned with organizational definition and tailoring of the SE lifecycle processes discussed in detail elsewhere in this document; and OPF (Organizational Process Focus) which is concerned with establishing a process culture in an organization.

Systems engineering performance should be assessed and measured at organizational level (see Assessing Systems Engineering Performance of Business and Enterprises). SE performance should be evaluated as to how well it is supporting the business (doing the right things) as well as how well the SE process is delivering to its own targets and measures (doing things right). It may be necessary to sub-optimize the systems engineering aspects in order to optimize the performance of the whole enterprise. SE measurement to date has focused more on measuring SE than on measuring the benefits SE delivers to the business.

CMMI also provides a means to measure performance of systems engineering projects. The Organizational Process Performance (OPP) process area provides guidance on managing process performance at an organizational level. Consistent process measurement across the business allows the development and calibration of parametric estimating models that improve the predictability of systems engineering projects. Leading indicators should be monitored at the organizational level to help direct support to projects or teams heading for trouble. For example, the INCOSE Leading Indicators (INCOSE 2010) provide a set that is useful at project level. Lean Sigma provides a tool for assessing benefit delivery throughout an enterprise value stream. Lean Enablers for Systems Engineering are now being developed (Oppenheim et al. 2010). An emerging good practice is to use Lean Value Stream Mapping to aid the optimisation of project plans and process application.

Tools, models and "infostructure"

Most SE organizations invest in SE tools and models, developing their own, and/or integrating off-the-shelf tools into their optimized processes. Tools are an essential part of the support for systems engineering. Conversely, risks with tools include the possibility that they may “lock in” inefficient and counterintuitive processes, fail to manage exceptions properly, and force people to service the tool instead of the tool serving the people. Tools require great attention to culture and training, to developing a consistent “style” of use so that people can understand each others’ work, and to configuration management of the information so that people are working on common and correct information.

Tools and facilities to support the SE processes may include customer domain tools, e.g. Synthetic Environment; product domain tools, e.g. whole system models, specific models for critical functions; and domain-independent SE tools - requirements, architecture modelling, TPM tracking, SE metrics, configuration management etc.

It is common practice in large SE organizations to have a tool support infrastructure which ensures that tools support the organizational standard processes and are fully integrated with training, and that projects and teams can use the tools to do their job and are not distracted by tool management issues that are more efficiently handled centrally.

"Infostructure" (information infrastructure) to support the system lifecycle will include:

  • Information assets such as process libraries, document templates, preferred parts lists, component re-use libraries, as-specified and as-tested information about legacy systems, capitalized metrics for organizational performance on previous similar projects, all with appropriate configuration control
  • Modeling and simulation tools, data sets and run-time environments
  • Shared working environments – workspaces for co-located teams, areas for people to interact with each other to develop ideas and explore concepts, work areas suitable for analysis tasks, meeting rooms, access control provision, etc.
  • IT facilities - computer file structures, software licenses, IT equipment, computer and wall displays to support collaborative working, printers, all with appropriate security provision and back-up facilities, procedures for efficient use, and acceptable performance and usability
  • Security provision to protect own, customer, supplier and third party IPR and enforce necessary protective working practices while allowing efficient access to information for those with a need to know

Systems engineering is a knowledge activity and systems engineers need appropriate facilities for accessing, sharing and capturing knowledge and for interacting effectively with the whole set of stakeholders. Often a systems engineer will need to “move into their world” to deal effectively with stakeholders. So visiting customer sites, using simulation facilities, etc, are important ways to engage with and understand operational and customer communities. Even such simple things as putting photographs of the operational systems and environment up on the walls can help to establish a common understanding that that leads to effective communication. (Warfield, 2006) describes collaborative workspaces, and environments and processes for developing a shared understanding of a problem situation.

Enabling infrastructure

The ISO/IEC 15288 (ISO 2008) Infrastructure Management Process provides the enabling infrastructure and services to support organization and project objectives throughout the life cycle. Infrastructure to support the system lifecycle will include:

  • Integration and test environment – bench and lab facilities, facilities for development testing as well as acceptance testing at various levels of integration, calibration and configuration management of test environment
  • Trials and validation environment – access to test ranges, test tracks, calibrated targets, support and storage for trials-equipment, harbor, airfield and road facilities, safe storage for fuel, ordnance, etc.
  • Training and support infrastructure – training simulators, embedded training, tools and test equipment for operational support and maintenance, etc.

Fitting it all together

The concept map (below) shows the relationships between the various aspects of organization, resource, responsibility and governance.

Businesses, Teams and Individuals in SE

References

Citations

  • Elliott et al, 2008 - In-Service Systems Engineering report, INCOSE UK Chapter in-service systems working group (HGS to confirm details of citation)
  • Fasser, Yefim and D. Brettner. 2002. Management for Quality in High-Technology Enterprises. Wiley
  • System Engineering Leading Indicators Guide, Version 2.0, January 29, 2010, Editors: Garry Roedler, Lockheed Martin Corporation, Donna H. Rhodes, Massachusetts Institute of Technology, Howard Schimmoller, Lockheed Martin Corporation, Cheryl Jones, US Army. Published jointly by LAI, SEARI, INCOSE, PSM
  • ISO/IEC. 2008. ISO / IEC 15288:2008.
  • Kasser, J., D. Hitchins, and T. Huynh. 2009. Re-engineering Systems Engineering." Proceedings of the 3rd Annual Asia-Pacific Conference on Systems Engineering (APCOSE), Singapore, 2009.
  • Morgan, J. and J. Liker. 2006. The Toyota Product Development System: Integrating People, Process and Technology. Productivity Press.
  • Oppenheim et al. 2010. INCOSE Lean SE WG. Lean Enablers for Systems Engineering. Available at, <http://cse.lmu.edu/about/graduateeducation/systemsengineering/INCOSE.htm>.
  • PMI. 2008. Project Management Body of Knowledge. 4th edition. ANSI/PMI 99-001-2008.
  • Reason, J. 1997. Managing the Risks of Organisational Accidents. Aldershot, UK, Ashgate Publishing Limited.
  • Ring, J. & Wymore, A. W. 2004. INCOSE-TP-2003-015-01: Concept of operations (conops) of a systems engineering education community (SEEC). INCOSE INCOSE Intelligent Engineering Working Group, E&R TC Report. See: http://www.incose.org/ProductsPubs/PDF/ConopsOfAnSEEdCommunity_2004-0315.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. INCOSE 6th Annual Symposium, Boston. Available at, http://www.incose.org/educationcareers/PDF/12-roles.pdf
  • Sheard, S. 2000. The 12 Systems Engineering Roles Revisited.” Proceedings of the INCOSE Mid-Atlantic Regional Conference, April 2000, pp 5.2-1-5.2-9.
  • Sillitto, H. 2011a. Unravelling Systems Engineers from Systems Engineering - Frameworks for Understanding the Extent, Variety and Ambiguity of Systems Engineering and Systems Engineers." INCOSE International Symposium, Denver, June 2011.
  • Sillitto, H. 2011b. Sharing Systems Engineering Knowledge through INCOSE: INCOSE as an Ultra-Large-Scale System? INCOSE Insight, Page 20 Vol 14 Issue 1, April 2011
  • Sprenger, C. and Have, S. Ten. 1996. 4 Competencies of a Learning Organisation. ‘Kennismanagement als moter van delerende organisatie’, Holland Management Review, Sept–Oct, pp. 73–89.
  • Warfield, J, 2006; “An introduction to systems science”, World Scientific, 2006
  • Weick, K. E. and K. M. Sutcliffe. 2001. Managing the Unexpected: Assuring High Performance in an Age of Complexity. San Francisco, Jossey-Bass.

Primary References

None.

Additional References

  • Blanchard, B. and W. Fabrycky. 2005. Systems Engineering and Analysis. 4th edition. Prentice-Hall International.
  • CM Guide. 2009. Construction Management Guide. Project Organization Types. Available at, <http://cmguide.org/archives/319>.
  • Defense Acquisition University (DAU). 2001. Systems Engineering Fundamentals. Available at, <http://www.dau.mil/pubscats/PubsCats/SEFGuide%2001-01.pdf>.
  • Handy, C.B. 1985. Understanding Organizations, Penguin Business, London.

Article Discussion

[Go to discussion page]

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

Signatures

Qing Wang

Retrieved from "https://sandbox.sebokwiki.org/index.php?title=Organizing_Business_and_Enterprises_to_Perform_Systems_Engineering&oldid=15982"