Determining Needed Systems Engineering Capabilities in Businesses and Enterprises
preliminary insertion of material from bkcase 0.25 chapter 7
Need to fdo citations, re-edit, add cross links and review the relevant comments form 0.25
Introducution
Understanding the value that is assigned to SystmeS engineering within the organisaiton is the starting point for deciding the desired SE cpaapbilities. This is described in the section on structuring to do SE (add link)
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 SystmeS engineering (Oppenheim et al, 2010) is "Pursue perfection". The means of improvement at organsiaiton levle is discussed in detail in 4.4.3, but the starting point has to be deciding the Systems Engineering capabilities the organisation wants
A standard way of describing the capabilities needed taken from Toyota (Morgan and Liker 2006)) is by considering People, Processes and Tool. To This division is used to strucutre this topic, with the addition of some specific issues about the enabling organisation.
People
The role people fill are defined by the organisation (see section 4.4.1) and the way people are used in team is described in 4.2, and the individual developments are described in 4.1. The key point to recognise here is that the roles, and the Systems engineering competencies required in those roles need to be defined at the organsiaition level
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. 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 2005) 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 infrastucutre
Most SE organizations make significant investment in SE tools and models, developing their own for, 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 defined elsewhere, 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.
Efficient use of systems engineering tools benefits from co-ordination across the organization of tool development, selection, usage, and licence management, and of attention to tool interoperability – within the organization, with customers, and with suppliers. 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.
It is good practice to have an “infostructure management process” to define, provide and maintain the facilities, tools, and communications and information technology assets needed to support SE across the business. Infostructure 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
Critical issues include: efficient use of infostructure across the enterprise; timeline to set up the environment, facilities, baseline information and information architecture (file structures, language, taxonomy, ontology) for a new project; timely availability of assets and information when required to avoid queuing in projects; operating, upgrading and replacing the enterprise infostructure while maintaining business continuity and avoiding or minimizing disruption to projects; and closing down a project – recycling or disposing of the infostructure as appropriate, preserving and ensuring continued access to system information throughout the in-service and disposal phases of the system lifecycle.
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.
Citations for this topic
INCOSE 2010 a. “INCOSE Systems Engineering Handbook”, Version 3.2
ISO, 2008, ISO/IEC 15288:2008, “Systems and software engineering - System life cycle processes”
Oppenheim et al. 2010, INCOSE Lean SE WG. “Lean enablers for Systems Engineering”, accessible at http://cse.lmu.edu/about/graduateeducation/systemsengineering/INCOSE.htm
Morgan, J. and Liker, J. 2006. “The Toyota Product Development System: Integrating People, Process and Technology”, Productivity Press
INCOSE 2005 “Systems Engineering Leading Indicators Guide”, INCOSE-TP-2005-001-02