Business Activities Related to Product Systems Engineering
This topic discusses the interfaces between product systems engineering and other 'back office' and management activities of the enterprise.
Marketing, Product Life Cycle Management & Quality Management
PSE includes critical and robust interfaces with related business activities such as marketing, product lifecycle management (PLCM), and quality. Traditionally, PLCM has been a critical stage in the IPDP and continues to be an important tool for Lifecycle management after product deployment. PLCM provides an important component of the PSE end-to-end view with the other component being the “breadth” component which captures everything that is relevant to the system at each life cycle stage. More currently, focus has started to shift to the idea of managing not just the life of the product but to expand the view and to manage product-lines (families) or product platforms themselves. This provides an increase in sustainability, flexibility, reduced development times, and important reductions in costs as new or enhanced products are not launched from zero every time.
PSE also includes interfaces with the marketing function; in particular, PSE works closely with the business and market development organizations to elicit products needs and intended operations in target markets to define product roll-out and possible phases of product introduction. Analysis of the market is critical during the entire product life-cycle from conception through retirement with the understanding that each life-cycle phase requires very different marketing approaches. During concept development marketing has to help determine the potential market, the addressable market segments, and define products, product/innovations requirements for those markets. During the product introduction stage, marketing has to create demand and prompt early customers to try the product. During the growth and maturity phases, marketing has to drive public awareness, develop the brand, and differentiate the product and its features and feature releases to compete with new market entrants. During saturation, marketing must help manage diminishing volumes and revenues as focus shifts from top line (increased market share) to bottom line (increased production and distribution efficiencies) considerations.
The links between PSE and Quality are just as critical. The relationships between Product SE and Quality also reflect the broad view which includes the product and opportunity but also the company’s internal goals, processes, and capabilities. Quality schemes which focus on the tangible product have been extensively used historically. More recent approaches that acknowledge and match Product SE’s holistic view have come into use. Issued during 1988, ISO 9000 is a family of standards which focuses on processes and the organization instead of the product itself. In addition, it calls out specific requirements for the design of products and services. ISO 9001 has served as a “platform” for many other schemes which are tailored to specific domains. A cooperative effort of the International Aerospace Quality Group , AS9100 contains all of the base requirements of ISO 9100 and expands further requirements which are critical and specific to the aviation, space, and defense industries. Similarly QS-16949 is a technical standard based on ISO 9001 but expanded to meet specific requirements in the worldwide automotive industry. Product SE should play an important role in the design and implementation of any quality management system.
Capability Maturity Model Integration (CMMI) is a process improvement approach whose goal is to help organizations improve their performance. CMMI can be used to guide process improvement across a project, a division, or an entire organization. Although initially used in software engineering and organizational development, CMMI use is spreading to other domains since it provides organizations with the essential elements for effective process improvement. According to the Carnegie Mellon Software Engineering Institute (SEI, 2008), CMMI helps "integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes."
Project Management & Business Development
The end-to-end view mandated by PSE requires strong relationships with project management and to business development activities. The ‘concurrent’ thinking encouraged by PSE necessarily requires multiple projects to move forward in parallel but with a high level of coordination. In this sense, PSE and Project Management (see Systems Engineering and Project Management) are two heavily intertwined disciplines which have been shown to generate synergy and added value for the stakeholders.
The Systems Engineering Management Plan (SEMP) is the key document covering the activities, milestones, organization, and resources requirements necessary to ensure the system of interest accomplishes its intended goals and mission. A key objective of the SEMP, which is usually developed during the conceptual design phase, is to provide the structure, policies, and procedures to foster the optimum management of projects and activities needed for system development and implementation. (Fabrycky 2011)
An effective and agile PSE function can make important contributions to business development for an enterprise or company. The primary goal of business development activities is to identify new types of business/product/services which are believed to address existing or potential needs and gaps (new markets), to attract new customers to existing offerings, and to break into existing markets. Product Systems Engineering’s end-to-end view of the life cycle can support market development by intelligence gathering, feedback on market acceptance or rejection, strategic analysis, and proposition development and campaign development. Finally, Product Systems Engineering should encourage the consideration of several factors within the new product development which may enhance market development. For example, in well-established companies business development can often include setting up strategic alliances with other, third-party companies. In these instances the companies may leverage each others' expertise and/or intellectual property to improve the probability for identifying, researching, and bringing to market new businesses and new products. See http://en.wikipedia.org/wiki/Business_development.
Supply Chain Management & Distribution Channel Management
Product SE provides the following information to the supply chain management function in the enterprise:
• Product specifications (including intended uses of the product)
• Product acceptance criteria (for accepting delivery of the product from the supplier)
• Product testing and qualification plans and procedures, including which ones are responsibility of the supplier and which ones are responsibility of the acquirer
• Interface specifications associated with each product
• Supplier certification criteria (including a list of pre-certified suppliers)
• Feedback on quality of products delivered by suppliers
Supply chain management will, as necessary, manage the identification and certification of qualified suppliers with the concurrence of, and coordination with, systems engineering and product engineers.
Product SE provides the following information to the distribution channel management function in the enterprise:
• Product specifications (including intended uses of the product)
• Product user manuals (including installation and maintenance documentation)
• Product packaging (for safe delivery of product and for display in retail channels)
• Product qualification data (to prove that product meets its design requirements)
• Product certification data (to prove product is certified for safe and secure operation)
• User support instructions
• Operator certification criteria
Distribution channel management will, as necessary, manage the identification and certification of qualified distributors with the concurrence of, and coordination with, systems engineering and product engineers.
Capability Management & Operations Management
Capability (glossary) is defined in various ways, but always consistent with the notion of “the ability to do something useful”. Products and services are acquired by end users to enable and improve their operational capability – to let them do something useful - whether in a military context – e.g. weapon systems improve the capability to conduct effective military operations - or social – e.g. a car may improve the ability to satisfy the transport needs of a family. Users acquire products (e.g. military equipment, cars, “productised” service offerings from airlines and taxi companies, etc) to contribute to satisfying their capability needs.
Capability management involves identifying and quantifying capabilities (existing, new or modified) that will be needed to meet enterprise goals, and selecting a coherent set of product and services across all components of capability (glossary - tbc) that will be integrated to provide the needed capabilities. So normally, requirements for “product systems” are derived from capability management. Capability management is likely to include trade-off processes to make best use of existing product or low-risk evolutions of them, and conversely identifying when a capability need can only be satisfactorily met by a new-generation product, or even a new type of product altogether. In some cases new offered products or disruptive technologies (e.g. jet engine, nuclear weapons, internet) create opportunities for new or improved capabilities, in which case capability management focuses on ensuring that all needed components of capability are put in place to exploit the opportunity provided by the new product or technology.(Refer to Capability Engineering article)
Operations management is about using an integrated set of product systems to deliver value to the enterprise and its stakeholders. Operations management involves bringing new product systems into operation, normally while maintaining business continuity, so transition plans and relevant metrics are critical; then working up to full operational efficiency across all components of capability, coping with incidents, contingency plans to deal with major disruptions, adjusting the system to cope with new ways of working and to deliver new services to meet new enterprise requirements and accommodate new product systems entering service, and eventually planning transitions out of service or major in-service upgrades. Product systems engineering supports operations management by defining all dependencies for successful operation on other systems and services, and by providing ongoing engineering support for spares and repairs, obsolescence management and system upgrades. Systems Engineering in the in-service phase has been analysed by (Elliott, B, et al ) and is best viewed as the same basic SE process conducted at a much higher tempo (Kemp & Linton, 2008) and requiring detailed understanding of constraints imposed by the current environment and usage. Configuration management and configuration status accounting during operation is very important for high value and high integrity systems, to ensure that any changes are designed to fit the “as-is” system, which may be significantly different from the “as-originally intended” specification and design.
Product Engineering, Assembly, Integration & Test
Product Engineering typically results in an Engineering Model that is used as the “blueprint” for Assembling, Integrating and Testing a product system. These AIT activities may be performed on prototype versions as well as final production versions to be delivered to end users. There is significant experience in domain specific industries in performing AIT for complex products. Unfortunately, very little is written in the general literature. Wasson (2006) and de Jong (2008) cover some of these aspects.
For software products the collection of code modules are integrated via some form of integration program (typically called “make”). The integrated modules are then subjected to tests to exercise the various potential paths through the software. Since software can be easily changed it is common to use some for of regression testing based upon test suites in order to verify software correctness. Another common means of testing is by fault injection as described by Voas and McGraw (1998)
Manufacturing, Test & Certification
Systems engineers usually work with manufacturing indirectly through the electrical and mechanical design teams. There are times in the development cycle when a direct interface and working relationship between system engineering and manufacturing is appropriate and can improve the probability of program and system success. Early in the program the system concept must be examined to determine if it is manufacturable. The requirements and the concept design should be reviewed with the manufacturing engineers to obtain an assessment of the risks associated with the production of the system. If substantial risks are identified then actions that improve the manufacturing capabilities of the organization, modify the design and perhaps change the requirements may be needed to reduce the identified risks to acceptable levels. Manufacturing prototypes or Proof of Manufacture (POM) units may be necessary to reduce the risk and to demonstrate readiness to proceed with the design and the system development. Similarly the systems engineers must establish early in the product development that the system will be testable. The requirements should be mapped to verification methods of inspection, analysis, demonstration and test before they are released to the design team. All requirements mapped to test must be examined to determine the test methods and the risk associated with accomplishing the necessary tests as part of the product qualification, acceptance and release process. Where risks are identified the systems engineers must work with the test engineers to develop test capabilities necessary.
Product Delivery & Product Support
Most products live much longer in the usage phase than in the development phase. The costs associated with product support are usually greater than the cost of developing the product. These two facts make it very important for the product systems engineer to consider the product delivery and support as part of the earliest activities during development. The design dictates the maintenance and support that will be required. The systems requirements are the first means of influencing the design to achieve the desired product support. If maintenance, reliability and support requirements have not been defined by the customer then the systems engineer must define these to achieve the support methods and costs that the customer, users and the organization responsible for support will find financially acceptable.
References
Works Cited
Kossiakoff, A. and Sweet, N. 2003. Production, Systems Engineering Principles and Practice - Chapter 11. John Wiley & Sons.
de Jong, I. 2008. Integration and Test Strategies for Complex Manufacturing Machines: Integration and Testing Combined in a Single Planning and Optimization Framework. Verlag. Saarbrücken, Germany VDM.
Wasson, C. S. 2006. System Analysis, Design, and Development. John Wiley & Sons. Hoboken, NJ, USA.
Voas, J.M. and McGraw, G. 1998. Software Fault Injection. John Wiley & Sons. Hoboken, NJ, USA.
Primary References
Primary references.
Additional References
Additional References.
Comments from 0.5 Wiki
This article is new to the SEBoK for version 0.75. As such, there are no associated 0.5 comments.
SEBoK Discussion
Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.
If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.
blog comments powered by Disqus