There are a few different Procedure modules, each with different access to features. The specific modules available for sale vary and you may have a legacy module. (A legacy module means we no longer sell that specific combination of features – it doesn't mean that your software is outdated.)
For this and other reasons, see Manuals Overview for more details, these manuals may show features you don't have access to.
Initial concepts:
A procedure is a template to create work orders. It does a 'smart' create, not a 'dumb' straight copy.
The Procedure Modules are secondary to the MCe system, while in theory you could do most or all of your work on procedures when sitting at a desk with a solid internet connections, this is often not the most convenient. Our first procedures module was written for managers who spend a couple hours a day on the train going to and from work and want to build procedures while travelling. Like our first 'offline' modules (WO) we wrote to work with Maintenance Connection, the Procedure MCe modules are designed to allow you to work on building and maintaining Procedures in places like a commuter train, airplane or other places – even when you are working away from the internet for a week or more..
Most important feature of Procedures:
One of the best advanced features you can do from the Procedures modules is to make all your tasks hierarchical. We do this in a way that allows them to work 'flat' if you are working in another system like Accruent's MC, while giving technicians in MCe the task list in a hierarchical way. You have the option of letting advanced users click 'complete' (or failed or N/A) for all the 'child' rows instead of clicking every row. Hierarchical tasks make it reasonable to have 1000's of tasks in one procedure, we have one customer who reported having a complex procedure with over 3900 tasks, but because of the Hierarchical tasks the users can keep track easily of where they are at, be sent to the 'next' task automatically, and allow for advanced users to work at a higher level than less experienced users, or work at the higher level where they know what they are doing and drill down where they need to.
When do procedures create work orders?
- Automations (PM+), our automations, using PM (Preventative maintenance) PdM (Predictive maintenance) and other concepts can create Work Orders from procedures. In fact, that is the normal outcome of the automations.
- Service requestors, with Procedures tied to 'problems'
- From the Procedure itself you can create a one off Work order
- Projects create their Work Orders by specifying Procedures.
- The MCe API can create Work Orders specifying a procedure or something that itself specifies a procedure.
- Events and Actions can create Work Orders as one or the action using Procedures typically
- The DataHub can trigger things that create Work Orders, so not really 'direct' but you may think of it as something that creates work orders
- The DataHub can directly create a Work order specifying a procedure