Designing and Configuring Functional Location Hierarchies
Explains how to design a scalable functional location hierarchy using structure indicators, label patterns, and superior/subordinate relationships, plus the configuration decisions that shape long-term reporting and maintenance.
Explanation
Designing a functional location hierarchy is one of the highest-leverage decisions in an EAM implementation because it becomes the backbone for maintenance history, cost roll-up, and reliability analysis for years. The primary configuration object driving this design is the structure indicator, which defines the edit mask - the pattern of characters and hierarchy-level separators used to build the functional location's technical identifier. A typical edit mask might allocate a fixed number of characters to plant code, then area, then unit, then equipment position, separated by hyphens. The edit mask determines both the maximum hierarchy depth that can be cleanly represented and how intuitively users can read the identifier to infer location. When designing the hierarchy, consultants must balance two competing needs: granularity (enough levels to support meaningful maintenance and cost reporting) versus maintainability (not so many levels that data entry and structure changes become burdensome). A common approach is a plant-area-system-equipment-position model, but the right number of levels depends on the client's reporting requirements, for example whether reliability engineers need failure analysis down to individual valve positions or only to system level. Superior/subordinate relationships are established through the 'superior functional location' field, and this relationship is what the system uses to inherit fields (such as cost center, business area, or company code) and to roll up reporting. It is critical to distinguish this database-level parent relationship from the label's textual hierarchy - in most configurations the label reflects the hierarchy for readability, but the actual structural link is the superior field, and in edge cases these can diverge if not carefully maintained, causing confusing reports. Another key design decision is whether functional locations will also be used to represent non-physical organizational groupings (like a maintenance responsibility area) versus strictly physical locations. Mixing organizational and physical meanings into the same hierarchy is a common design smell that leads to reporting ambiguity later; a cleaner practice is to keep functional locations strictly physical/spatial and use other master data or classification to represent organizational responsibility. During configuration, consultants also decide category and default settings such as the maintenance plant and planning plant defaults at each level, and any reference structure they may reuse as a template for creating similar sets of locations (useful for plants with repeated identical production lines). Reference structures allow rapid creation of a full hierarchy for a new line by copying an existing template and adjusting identifying values, significantly reducing manual creation time in projects with dozens or hundreds of similar assets. Finally, changing an established structure indicator or hierarchy depth after go-live is disruptive: it typically requires either a technical migration of existing functional location labels or the creation of a parallel structure, both of which carry data continuity risk. This is why structure indicator and hierarchy depth decisions deserve explicit client sign-off during blueprint/design phase rather than being treated as a purely technical configuration task.
Real project scenario
A manufacturing client with twelve nearly identical packaging lines across two plants asked for functional locations to be created individually by plant engineers as needed, with no standard template. Within a year, the structure had inconsistent depth - some lines had five levels down to individual sensor positions, others had only two levels - making cross-plant benchmarking impossible. The consultant proposed a reference structure representing a standard packaging line template with four fixed levels, then used it to recreate and remap the inconsistent structures plant by plant during a scheduled downtime window, with careful reassignment of existing notification and order history to the corrected locations. This retrofit took several weeks but was substantially cheaper than continuing to operate a structure that could never support the reliability KPIs the client wanted.
Common mistakes
• Designing structure indicators with insufficient character length, forcing awkward abbreviations once the client scales to more plants or units. • Mixing organizational/responsibility groupings into the physical hierarchy, causing reporting ambiguity between 'where' and 'who is responsible.' • Allowing hierarchy depth to vary inconsistently across similar assets, which breaks apples-to-apples benchmarking. • Relying on the label text to represent hierarchy while neglecting to correctly set the superior functional location field. • Underestimating the migration effort required to change structure indicators after significant transactional history has accumulated.
Best practices
• Get explicit client sign-off on structure indicator and hierarchy depth during design phase, since changes later are costly. • Use reference structures/templates when creating multiple similar hierarchies to enforce consistency. • Keep the functional location hierarchy strictly physical/spatial; represent organizational responsibility elsewhere. • Periodically audit hierarchies for depth and naming consistency across plants, especially after decentralized creation by multiple engineers. • Document the mapping between edit mask segments and business meaning (e.g., which characters represent plant vs. area) so future consultants can maintain it correctly.
Interview angle
Interviewers assessing intermediate-level design skills often present a scenario with several similar production lines and ask how you would structure the functional location hierarchy, including how many levels you would use and why. Strong answers reference the trade-off between granularity and maintainability, the role of reference structures for scaling similar assets, and the risk of changing structure indicators later - showing you think about long-term reporting consequences, not just initial setup.