Nested Steps and Nested Standard Steps (Beta)
Take your procedures to the next level.
Last updated
Take your procedures to the next level.
Last updated
Managing complex assembly processes often involves creating intricate dependencies between various sets of instructions, which can be challenging and time-consuming. Traditionally, users have struggled with the complexity of manually updating these procedures and managing dependencies, leading to increased risk of errors and inefficiencies. The old limitations in nesting both steps and standard steps have restricted the flexibility needed for detailed workflows, and the stop gap solution of manually redlining and merging changes has been cumbersome and prone to mistakes.
ION solves this pain with enabling complex assembly through nested standard steps and nested steps. By embedding standard steps within other steps, users can create comprehensive dependency graphs, ensuring a structured and interconnected workflow. The solution has the ability to capture the most finite process such as torquing a bolt to the most complicated integration process by combining many nested steps with one another. The ability to nest procedures infinitely provides the flexibility to accommodate complex workflows. Automatic updates and improvements to standard steps are reflected across all dependent runs, significantly reducing the need for manual redlining and merging processes. This feature also encourages the use of MBom for subassemblies, facilitating the installation of entire subassemblies without creating circular dependencies. Overall, this feature enhances workflow efficiency, ensures consistent application of improvements, and provides the flexibility needed for managing complex builds effectively.
Note: This feature is only available to those at the advanced or enterprise tiers. Please contact your CSM for more information.
A set of revision-aware work instructions that can be added to other procedures and standard steps. Each time a standard step is used, it automatically pulls in the latest released version of the work instructions, ensuring consistency across procedures and runs.
Procedure
A structured group of steps that serves as the basis for runs. Procedures are not revision-aware, meaning that once they are set in a run, they do not update automatically if revised. Procedures can be associated with specific parts and have part-step associations. They also allow for deeply nested steps, creating a detailed, customizable workflow.
Depth
This term describes the level of nesting within a procedure:
Depth 0: The root level of a procedure.
Depth 1: Direct children of the root level steps.
Depth 2: Children of steps in Depth 1, and so on.
You can determine the depth by reviewing the breadcrumb trail at the top of the procedure's step queue.
A defined execution order between two or more steps at the same depth level within a procedure. Dependencies ensure that steps within the same level are completed in the correct sequence.
Using Standard Steps:
Standard steps should be used when a set of instructions is likely to be used multiple times across a variety of processes OR when it is critical that updates to a process are captured before execution. When selecting to use standard steps, you are making a conscious decision that any revision to that step will reflect the latest instructions in all places it’s used—whether in other procedures, standard steps, or runs.
Single Parent Step Usage:
Use a single main parent step to group similar steps with shared intent. This approach improves workflow organization and dependency management. For example, to standardize torque instructions, nest all related steps under a single step named “Perform Standard Torque Operation.” This consolidates related actions, enhancing clarity and control over grouped steps.
Dependency Graph Creation and Procedure Nesting:
To build a structured dependency graph, nest standard steps within each other. This allows for infinitely nested steps to manage complex workflows with interconnected steps. Create and edit dependencies for a standard step only at its root level to maintain consistency everywhere it is used.
Example: If a standard step like "Seal Hatch" includes another standard step, "Torque Bolts", then edit dependencies for "Torque Bolts" within its own root procedure. This ensures any dependency changes are reflected consistently wherever "Torque Bolts" is used.
Version Control and Releases:
Create and release standard steps to include them in procedures. Make changes to standard steps after initial runs to reflect improvements automatically across all to be started dependent runs, reducing the need for complex redlining and merging processes. Place runs on hold temporarily until all necessary instructions are versioned correctly to avoid starting incomplete procedures.
Example: If a run starts before the road test procedure is finalized, the run will automatically pull the latest version of the procedure (v2), streamlining improvements across all dependent runs without requiring manual updates.
Usage of MBom for Subassemblies:
When setting up a Manufacturing Bill of Materials (mBOM), ensure that a specific instance of a procedure is connected only to one parent assembly to avoid circular loops in the dependency graph. Utilize the hierarchy and build your sub assemblies in their own procedures, not one massive "do everything" procedure. A procedure tied to a lower-level subassembly cannot also be tied to the parent assembly, maintaining clear and non-redundant relationships.
Avoidance of "m states":
In the context of MBom setup, ensure that all inventory is real inventory rather than "m states." "m states" are manufacturing states, representing the state of the product rather than something physical that has been installed, uninstalled, or can exist in inventory. Avoiding "m states" prevents issues with parallelization and the complications that arise when uninstalling a process that already occurred, maintaining the integrity and accuracy of the inventory and processes. In addition, it gets your eBOM that much closer to matching your mBOM.
Judgment Call on Procedure Depth
While there are no limits on the number of nested layers you can create, it is essential to make a judgment call with your technicians to avoid confusion. As procedures become more deeply nested, assess the complexity and clarity to ensure it remains manageable for the team. Consider setting internal guidelines to maintain an effective workflow.
Please note: Nested steps are currently not compatible with batching. Due to the complexity involved with batches, nested steps and nested standard steps will not support batching upon initial release.
If batching with nested procedures is a crucial aspect of your workflows, we encourage you to reach out to us via Intercom. Your feedback is valuable, and we'd like to discuss your use case in detail to explore possible solutions.
At this time, if you attempt to create a batch with nested steps or include a run from an existing batch into a deeply nested procedure, you will encounter warnings that prohibit these actions.
High Level Integration and Final Check Procedure Setup With Nested Standard Step
