Downtime Reasons

what is the downtime reasons page? the downtime reasons page in mantsu's downtimes manager is where all reason codes are created and maintained it is the starting point for any downtime configuration before operators can classify a stop, an engineer must first build the reason tree that defines which causes are available a well structured reason tree is one of the most impactful configuration decisions in the downtimes manager it directly determines the quality of downtime data and, by extension, the reliability of oee reporting and root cause analysis reason trees a reason tree is a standalone hierarchy of stop causes a site can have multiple reason trees; for example one per department, one per product family, or a single shared tree across the entire plant each tree is independent and can be assigned to one or more equipment units through the reason code assignment page trees are not shared across equipment by default this means two machines can use the same tree, or each can have a tailored subset, depending on what makes sense for the operation this is determined in the reason code assignment docid\ cxkcbo7oavx52tvqzpwkt tree structure each reason tree supports multiple levels of depth the top level holds broad categories; each subsequent level narrows toward a specific root cause operators selecting a reason code during a stop will navigate down through these levels to reach the most precise classification available keeping the tree balanced matters a tree that is too shallow forces operators into vague categories that offer little insight a tree that is too deep adds friction during registration and leads to inconsistent choices as a rule of thumb, two levels are sufficient for most use cases, with a third level reserved for equipment or failure types that genuinely require that level of detail example level 1 technical failure category level 2 component specification (ex pump, conveyor, oven, ) level 3 type of breakdown (ex electrical, plc failed, mechanical part, ) creating and maintaining reason codes reason codes can be created, edited, and reorganized each code has a name and sits at a defined position in the tree parent codes act as grouping nodes; leaf nodes (codes with no children) are the ones operators actually select when registering a stop when updating an existing tree, changes take effect immediately for any new downtime registrations historical records retain the reason code that was selected at the time of registration removing or renaming a reason code that has already been used in downtime registrations will affect the consistency of historical reports it is recommended to retire unused codes rather than delete them best practices mirror your internal language reason codes should use the terminology operators and maintenance teams already know introducing new terminology in the tree increases the chance of misclassification keep the top level to broad categories level 1 codes such as "mechanical failure", "electrical failure", "planned maintenance" and "process issue" provide a clean starting structure that works across most manufacturing environments plan for short stops reserve at least one reason code as a catch all for automated short stop classification this prevents a large volume of micro stops from appearing as uncategorized in reports the short stop threshold and its linked reason code are configured on the reason code assignment page review periodically as production processes evolve, reason trees should be reviewed to ensure they still reflect reality a quarterly review with input from operators and maintenance teams helps keep the data meaningful