ERCO track configurator: from planning concept to bill of materials.

Planning track systems is not limited to selecting a basic layout. In addition to linear runs or geometric arrangements, power feeds, connectors, end elements and further accessories must also be considered. In practice, much of this knowledge resided with the sales team, resulting in a high level of manual effort in consultation and quotation preparation.

The objective of the project was to develop a web-based tool that structures this process and makes it accessible to users. Customers should be able to prepare a configuration independently, providing a prequalified and verifiable basis for further processing by the sales team. This approach aims to simplify the selection process, transfer knowledge from manual sales workflows into a digital system, and reduce effort on both the customer and company side.

The track configurator guides users step by step through the creation of an individual solution. The starting point is a spatial requirement, such as a specific ceiling situation or a desired layout, which is translated into concrete parameters within the tool.

Based on this, the application captures the relevant requirements, processes the selected options and derives the necessary components. The result is a complete output of all required items, including the corresponding article numbers.

A key aspect is that the configurator does not only select components, but also makes relationships visible. Length specifications can be taken into account precisely, allowing even minor deviations in planning to be captured. If a configuration requires a profile to be cut manually, this is clearly indicated in the tool. At the same time, a visual representation supports the entire process. Changes to dimensions or selection options are reflected directly in the visualisation, ensuring that the configuration remains transparent. The result can then be exported as a PDF and serves as a basis for review, coordination and ordering.

The technical architecture of the track configurator is strongly data-driven. The configuration logic is primarily defined through a central JSON structure in which individual steps, response options and dependencies are specified. This allows the configurator flow to be controlled in a structured way without requiring direct changes to the interface for every adjustment.

User decisions are processed as a structured response path and continued in the backend. This results in a system that links individual configuration steps not only in terms of content, but also logically. The determination of final articles is handled via a dedicated data layer, built independently from existing product data sources. In addition, both frontend and backend rely on shared type definitions to ensure consistency in processing and improve maintainability.

A key advantage of this approach is its flexibility. New steps or selection options can be added within the underlying data structure without fundamentally modifying the frontend. This keeps the system extensible and allows it to be further developed in a controlled manner, even as the product portfolio evolves.

The main challenge was mapping the numerous domain-specific dependencies between individual components. Different combinations of selected options can require additional accessories or specific supplementary parts. These relationships could not be fully modelled in advance and only became apparent during testing and coordination.

In a system like this, the real complexity lies not in the interface, but in the underlying rule set. Many edge cases only emerged when concrete configurations were tested and checked for completeness. As a result, the logic had to be refined and extended iteratively throughout the project.

The project initially started with a proof of concept, primarily to validate technical feasibility quickly. This approach was not fully replaced later on, but instead evolved and was carried forward into the production solution.

Changes to the product portfolio can largely be made in the busbar configurator via a central configuration. As long as the changes remain within the existing structure, the effort involved is generally manageable.

If new dependencies need to be taken into account or the configuration logic needs to be expanded, the effort required for coordination and implementation increases accordingly—but this also opens up additional scope for further developing the configurator.