Factorial Documentation

Appearance

[TOC]

Procedures ​

Similar terms: "work instructions", "work order definitions", "processes", "recipes"

What is a Procedure? ​

Procedures are the repeatable processes at the heart of our software; they are the collection of recipes for building/maintaining/testing/... everything within your company. The real world moves fast—constraints are dynamic and opportunities for improvement and efficiency. Specify every part of your process with our feature-rich procedures.

Creating a Procedure ​

Procedures are a key element of our software and can be found on the left sidebar of our page. From the procedures page, you can simply click the New procedure button to get started.

Specify Your Output ​

Factorial procedures have a single output defined by an action (build/test/maintain) and a part number. We enforce that a single procedure cannot produce multiple parts and that a part can only have a single (multi-versioned) procedure. This simplicity produces a few desired side effects. 1) we can reliably call the rollup of per-step material requirements on a build-type procedure the mBOM for that part and 2) per-step material requirements obviously map to the single parent part without any ambiguity.

To write a procedure that produces multiple parts in the same exuction (coproducts), use a procedure with embedded procedures, each producing the desired part, to produce a similar result.

For companies using a PLM (Product Lifecycle Management), a procedure in Factorial might begin from a Part and an EBOM (engineering bill of materials). With that data in Factorial, you have a bit of a headstart. The part is already instantiated, and the EBOM becomes the full ingredient list you can pluck from while building out your per-step material requirements in your procedure. Otherwise, if the produced part is not created yet, you may have to visit the |Part definitions page|(linktodocumentationhere) to create that part first and then come back to the procedure page.

Our model does mean that producing multiple parts with very similar procedures and material requirements means cloning procedures. Two separate procedures can go out of sync with each other as new evolutions/versions of each procedure are produced. Sometimes that's ok—or even desired, but for cases where those processes need to remain locked in step with each other, we believe that the common/duplicated, composable parts of each step should become their own shared embedded procedure.

We believe this philosophy will produce greater simplicity and composability within your factory, but we do recognize in the most extreme case (which we call variants) that this may not be desired. We are exploring idea of step definition blocks that may be conditional to the variant selected on the work order. NOTE: Variants is a feature not currently priotized on the current roadmap.

Define Precise Steps ​

After selecting an output, it is time to begin defining the steps of your procedure. Depending on your situation, you might prefer huge steps or small atomic steps.

When deciding how atomic a step should be, we recommend following that:

  • Each step should be fine-grained enough to have one clear owner during execution.
  • A step should not combine work that could be performed independently or in parallel.

Definition Blocks ​

At the core of a step's definition are our different definition blocks:

  • Documents a classic WYSIWYG (what you see is what you get) editor. It's not as full featured as a Word Document, but it provides plenty of options for the core lists, styles, and links (and it also shows you other users' cursors in the same document if you work together)
  • Data Fields and Tables define fields that a technician should fill out while implementing the step like temperature readings, torque values, etc. These fields are global and reusable across other procedures and projects, so that you only need to configure names, units of measures, and validations once. Data fields should be used when only one value is needed. Data tables are built upon the same exact model, but can support multiple rows of field data.
  • Material requirements define what parts you need to complete each step (eg: 10 fasteners). By producing these specifications on a per-step basis, in the execution of long arduous builds, you can decide to make kit(s) at the step-level. Bringing materials to the work order location just-in-time. Technicians will have to fulfill those material requirement designations to complete the step.

Live updates many of our pages, our step definition pages are live—as denoted by the green "Live" signal at the top of your screen. As you make edits on this page, other users can see what you are doing to help facilitate collaboration.

Detail Timelines and Opportunities for Parallelization ​

Review and Approve ​

Every organization has different reviewing needs. Configure your review process in your |organization's workspace settings|(link_to_correct_page).

With admin permissions, configure reviewer requirements for your organization at (link_to_correct_page). As

Embed Within Other procedures ​

Uprev and Rollout with Full Control ​

[PROMO-like content]

  • Review and approve every organization has different reviewing needs. Configure your review process in your |organization's workspace settings|(link_to_correct_page).
  • Uprev with controlled rollouts When a new version of procedure is released, decide confidently—with the full context of the related actions on your factory floor—how the new procedure should interplay with ongoing, work in progress (WIP) and already scheduled work orders soon to be worked.
  • Embed within other procedures Do you have a common process for fastener installation, torque verification, ... ? Put that process into its own version controlled procedure and embed it wherever you'd like.
  • Specify your output In factorial, procedures produce/test/clean/maintain a single product. Specify the action and the item and get access to that part's latest eBOM or mBOM for consumption by steps
  • Detail timelines and opportunies for parallelization The factory floor is an amalgamation of lots of work happening all at once by people, tools, and machines. It is not single-threaded, and neither should your work instructions. Mark step dependencies—"blocked by" and "blocking" relationships—while planning, and get work done faster on the execution side with parallelization and prioritizing critical path.
  • Define precise steps. At the step-level specify:
    • Material requirements (for builds, these roll up into an mBOM for the produced part)
    • Data input, signoffs required by the technician
    • Equipments/tools necessary to complete the step
    • Organization-configured role(s) that are required by the eventual action-er of the step
    • Estimated durations
    • Dependencies (blocked by/blocking for that step)
  • Analyze with maximum context Easily find answers to questions like:
    • How many work orders were cut from this procedure in the last month?
    • How many procedures is this procedure embedded in?
    • In execution, how often was this procedure redlines and why?