SysML Modeling for a Business Process – Product Realization

1. SysML Modeling for a Business Process – Product Realization Georgia Artery Mark De Spain

2. Outline • Background • Problem Statement • Approach • Behavioral Diagrams • Structure Diagrams • Benefits • Conclusions and Next Steps

3. Background • Large, complex business utilizing legacy product realization process • Multiple sites/organizations trying to utilize one process • Many handoffs • Changing roles and responsibilities • Various interpretations of process • NNSA initiative to revitalize technical business practices • Sandia named as Systems Integration support

4. Problem Statement • Problem: • Existing Product Realization Process results in delays, cost overruns due to lack of clear roles and responsibilities, poor execution of program plans, and discipline around deliverables. • Goal: • Define a standardized and formal business operating process that maximizes the integration between stakeholders, engineering, and production personnel throughout the product realization process. • Create phase-gate process based upon Systems Engineering principles

5. Approach • Process Improvement event to identified inefficiencies in the process tasks and developed a “future state” process • Included limited design agency and production agency support • NWC adopted improved process as initial starting point • Demonstrated concept and usefulness • Developed functional model (IDEF0) of the process • Realized the structural piece was missing • First step to stakeholder buy-in of modeling • Created SysML model based on functional modeling

6. Project Driver for Requirement

7. Use Case of Top Level Process

8. Stakeholders Identification Multiple stakeholders and Users of the System

9. Block Relationships of Process Representation of the key elements of the Model

10. Process Artifacts

11. Use Case for Phase A Use case is taken to the next level which will be expanded into activity diagram

12. Source Requirements

13. Executable Model Use Case Activity Diagram drives the state changes in the artifact

14. Benefits • Utilized Systems Engineering approach – used a “process” to develop a “process • The more precision you have in a process, the better you can institutionalize the process effectively • Functional architecture clarified the relationships between tasks and enabled good cohesion • Understand the relationships of the inputs and outputs to the phase /gates • Create clarity in tasks and document deliverables (artifacts) needed at each phase • Prevent unnecessary, non-value added tasks • Clear understanding of roles and responsibilities • Balanced the tasks (leveling) and assure they rollup to the right level • Visual representation of the relationships between tasks and gate outputs in subsequent phases • Established connectivity to artifacts and activities – making sure the behaviors are tied to the structure of the process • Flow and intent of process is more explicit and understandable when represented graphically

15. Conclusions / Next Steps Conclusions • It is critical that you follow format and structure that will enable the model to be executable • Understanding the fundamental model structure was critical for complex process • Assuring completeness was key in developing the next level of the model • Understand the value of static versus dynamic model Next Steps • Model is still being tested and will continue to build on the key artifacts and elements in other phases • Pilot executable on specific elements of the process for upcoming development program