Organisation and Behaviours Systems Engineering within the wider enterprise

Size: px
Start display at page:

Download "Organisation and Behaviours Systems Engineering within the wider enterprise"

Transcription

1 Organisation and Behaviours Systems Engineering within the wider enterprise Richard Beasley 30 November 2011 and an introduction to BKCASE

2 Contents 1. Introduction and purpose 2. General introduction to BKCASE 3. Organisation and Behaviour Part IV of BKCASE 4. Example of application to organisation Rolls-Royce 5. Discussion part Attendees are also invited to comment / review BKCASE online (if they haven t already!)

3 Purpose of session We wanted to discuss organising to do Systems Engineering and I was asked to do a summary of activity in RR. However, seemed a good opportunity to introduce review of body of knowledge specifically BKCASE project which gives overview of issues Will give overview of organization section of BKCASE Discuss implementation of SE Opportunity for comments / Feedback on (part) of BKCASE

4 Introduction to BKCASE copyright 2011 by Stevens Institute of Technology. All rights reserved. Images used by permission remain the property of their respective copyright holders. You may use the contents of this wiki and all articles included in it on the conditions that (a) you acknowledge that your use is with permission of Stevens Institute of Technology, and (b) you indemnify and hold harmless Stevens Institute of Technology, the editors, and the authors, from any and all liability or damages to yourself or your hardware, software, systems, or third parties, including attorneys' fees, court costs, and other related costs and expenses, arising out of your use of this wiki and all articles included in it, irrespective of the cause of said liability. Stevens Institute of Technology makes this wiki and all articles included in it available on an "as is" basis and makes no warranty, expressed or implied, as to their accuracy, capability, efficiency, merchantability, or functioning. In no event will Stevens Institute of Technology, the editors, or the authors be liable for any general, consequential, indirect, incidental, exemplary, or special damages, even if they have been advised of the possibility of such damages. Retrieved from "

5 Organisation / production of BKCASE The Body of Knowledge and Curriculum to Advance Systems Engineering Project (BKCASE) was started in fall 2009 to create a community-based Guide to the Systems Engineering Body of Knowledge (SEBoK) and a Graduate Reference Curriculum for Systems Engineering (GRCSE). Led by the Stevens Institute of Technology and the Naval Postgraduate School, BKCASE is conducted in coordination with many relevant professional societies, and is funded both by the U.S. Department of Defense (DoD) and the generous volunteer efforts of more than 60 authors from dozens of companies, universities, and professional societies across 9 countries. Planned releases Version 0.25 a prototype that would create the first architecture and early content of the SEBoK for limited review and validation; Version 0.5 a version suitable for early adopters; (current) Version 1.0 the final version to be produced by the BKCASE project. (due Sept 2012)

6 Purpose of BKCASE Defines and organizes systems engineering knowledge. Guide to finding and understanding generally accessible literature about SE. Describes boundaries, terminology, content, and structure of systems engineering to support six broad purposes: Inform Practice boundaries, terminology, and structure of discipline and point to useful information needed to practice SE. Inform Research limitations and gaps in current SE knowledge to guide research agenda. Inform performers in interacting disciplines (e.g. system implementation) of the nature and value of SE. Inform Curriculum Inform organizations defining undergraduate and graduate programs in SE. Inform Certifiers Inform organizations certifying individuals as qualified to practice systems engineering. Inform Staffing managers deciding which competencies that practicing systems engineers should possess

7 Structure of SEBoK Set up in 7 Parts Part 1: Introduction Part 2: Systems Part 3: SE and Management Part 4: Applications of SE Part 5: Enabling SE Part 6: Related Disciplines Part 7: Examples

8 Enabling section of SEBOK covers organisation and behaviours Structure Systems Engineering Organizational Strategy Enabling Businesses and Enterprises to Perform Systems Engineering Enabling Teams to Perform Systems Engineering Enabling Individuals to Perform Systems Engineering Author team Lead by Art Pyster (Stevens Institute) with help from Alice Squires Primary authors include Hillary Sillitto (Thales, UK) Heidi Davidz, UTC Pratt and Whitney, USA), and Richard Beasley (Rolls- Royce, UK)

9 Knowledge Area and Topics on Enabling SE Part 5: Enabling Systems Engineering Knowledge Area: Systems Engineering Organizational Strategy Topic: Organizational Purpose Topic: Value Proposition for Systems Engineering Topic: Systems Engineering Governance Knowledge Area: Enabling Businesses and Enterprises to Perform Systems Engineering Topic: Deciding on Desired Systems Engineering Capabilities within Businesses and Enterprises Topic: Organizing Business and Enterprises to Perform Systems Engineering Topic: Assessing Systems Engineering Performance of Business and Enterprises Topic: Developing Systems Engineering Capabilities within Businesses and Enterprises Topic: Culture Knowledge Area: Enabling Teams to Perform Systems Engineering Topic: Determining Needed Systems Engineering Capabilities in Teams Topic: Organizing Teams to Perform Systems Engineering Topic: Assessing Systems Engineering Performance of Teams Topic: Developing Systems Engineering Capabilities within Teams Topic: Team Dynamics Knowledge Area: Enabling Individuals to Perform Systems Engineering Topic: Roles and Competencies Topic: Assessing Individuals Topic: Developing Individuals Topic: Ethical Behavior

10 Business, Teams and Individuals in SE

11 Organisation purpose

12 Types of enterprises

13 Organising to do SE

14 Deciding SE capabilities in an org

15 Need for clarity and dangers In any organization there is a danger of silos. One of the purposes of SE is to reduce this risk consider the interface or glue role Clarity on how the organization does SE is important. Typically, implementing SE may be part of an organization improvement, The way an organization chooses to do systems engineering should be part of the vision of the organization and must be understood and accepted by all. Many of the major obstacles in systems engineering deployment are cultural Systems engineering can make a very powerful contribution to the organization s quality goals so embed SE principles into organisation processes and methods "pursue perfection with starting point has to be deciding the SE capabilities the organization wants. A business or enterprise is a system and SE is one of the functions that system may need to perform. Balancing the need for a systematic and standardized approach to SE processes, such as defined in models and handbooks, with the flexibility inherent in systemic thinking is critical.

16 Literature topics for change / implementation for SE in Businesses and Enterprises Topics divided into Doing everyday things better Dealing with unplanned disruption Driving disruptive innovation Exploiting unexpected opportunities Implementing and embedding planned change Understanding peoples motivation and behaviour Understand culture Helping individuals cope with change

17 Culture some safety examples Apollo was a successful program because it was a culture of common interest. Then over the next 20 years there was loss of common interest. Challenger normalization of deviance. rather than taking risks seriously, NASA simply ignored them by calling them normal. Columbia board concluded that NASA had become a culture in which bureaucratic procedures took precedence over technical excellence. Texas City 2005 BP refinery accident. BP has not provided effective process safety leadership and has not adequately established process safety as a core value The Triangle Fire, NYC people died mostly women. The New York State Commission castigated the property owners for their lack of understanding of the human factors in the case. Implications for SE As systems engineering works across national, ethnic, and organizational boundaries, systems engineers need to be aware of cultural issues. Sensitivity to cultural issues will make a difference to the success of systems engineering endeavours

18 Competency

19 An illustration introducing SE into an organisation

20 Overall purpose / vision for SE in RR Rolls-Royce sees / wants the value Systems Engineering provides to assist Pre-work not re-work - Systems Engineering is a core skill for all engineering Systems Engineering is a glue integrating specialists in different attributes / areas etc. Therefore, despite introducing roles specifically in the Systems Engineering skill, the overlying purpose is to: Make Systems Engineering the way Rolls-Royce does Engineering

21 People make SE part of all roles 1. Put a Systems Engineering competency in ALL engineering roles all to have appropriate level of Systems Engineering 2. Particularly encourage the development of System Level / Integration experts (people who design at System level) 3. Leadership to set expectation / encourage of use of Systems Approach Supported by SE specialist roles to Drive the capture and compliant cascade of requirements, and embed a systems approach to creating solutions within Rolls-Royce Three generic SE roles are defined, as: 1. Project Systems Engineer Leading the use as a part of project team enabling design 2. Specialist Systems Engineer Corporate or sector specialist in specific aspects of SE skill cross project 3. Eng PM / WPO Utilising Systems Thinking to drive planning Challenge If we have Systems Engineers do they do the Systems Thinking for the designers?

22 Process separate doing and managing Process is not the same as lifecycle Embed Systems Approach deep into process Identified Need System Level Understand / Develop System requirements Manage Product Definition Information, Risks / Opportunities, Recommendations. Create System Concepts Rank System Concepts Manage Processes Time & Budget Doing Processes Decompose System Technical Direction & Approval Establish & Integrate System attributes Verify System against requirements Sub- Systems Understand / Develop Sub-System requirements Decompose System into simplified elements Create Sub-System Concepts Rank Sub-System Concepts Decompose Sub-System Make recursive and fractal remember layers of system Requirements must be foundation of all process Establish & Integrate Subsystem attributes Link to planning and allow for the necessary iteration Recompose elements to confirm System attributes Verify Sub- System against requirements

23 Tools Purpose of tool is the output the understanding to all SE tools in particular have to accessible to all In my view tools for context and functionality are most important Tailor choose and use of tools to situation A fool with a tool is a more dangerous fool

24 Leadership Especially when making transition from implicit to explicit Systems engineering Decision Makers need to demand for wellexecuted Systems Engineering Planning needs to allow proper focus is essential Significant effort needed to get understanding of what Systems Engineering really is.

25 Summary Organizations are different Therefore way of implementing Systems Engineering will vary with the organization There are some common themes, which have been captured in section in BKCASE SEBoK Organizational Strategy Enabling Businesses and Enterprises to Perform Systems Engineering Enabling Teams Enabling Individuals Attendees invited to comment of SEBoK as a whole

26 Discussion General reaction Specific feedback Does the BKCASE material look (potentially) helpful Any feedback on the topics for discussion on enabling Systems Engineering

27 Invitation to comment on BKCASE v0.5 The BKCASE Systems Engineering Body of Knowledge is now on line at Want feedback through the discussion tabs on each article, and through a general form found in the left margin of each page under the tab, Note to Reviewers. On December 15 th, this feedback will close. We hope that you will participate in the review process, and that together we can put the final polish on the SEBoK as we drive to the final release in September 2012.