The RELEX approach to control is highly exception-based. Our philosophy is that most of the work and focus should be directed at the products or events that have the most impact on your KPIs. Our solution also encourages end users, or main users, to create their own new exception classes and to fine tune the exception criteria. But sometimes our customers get a little over-enthusiastic and, in their determination to dig out everything that could be managed even a bit better, map out too many exceptions. This quickly leads to information overload and to those exceptions not being resolved.
Base Your Day-to-day Workflow on Exceptions
For day-to-day exception-based working I have found that working efficiency and the best KPI-measured results are achieved if you combine these two things:
- Ensure that all exceptions are (easily) actionable. This means that an exception is not just an alert telling you that something is/might be wrong with your stock planning for a particular product. The means for a quick and effective resolution should be right there on the screen alongside the exception. For example, if the screen shows users those products at risk of stock-out before the next scheduled order is due in, then add an express order function within the same window. Or if the screen displays products with high stock levels where safety stocks are potentially too large, then make sure that same window both contains all the information needed to determine the proper level and the means to correct those safety stocks.
- Make sure the volume of exceptions is at a level whereby your staff can actually resolve them all. So if you set exceptions at a level where they can all be resolved on the day, every day, it leads to better performance. If there are so many exceptions that some or all are not acted upon but just mapped, then any improvement is limited or non-existent. I find it best to prioritize exceptions based on their role in product assortment and their impact in terms of business-driven KPIs. Moreover, having prioritized, I’d recommend only showing as many as can be resolved in a day. Once your processes have improved, and as the number of high priority exceptions decreases, you can actually broaden the filters to include more exceptions. But remember to start with the ones that have the most impact on the business.
Automate Manual Labour
I’d argue that these two principles are important in all supply chain planning systems. When working with RELEX a third principle is:
- Use the business-rules engine to prevent or automate the most common exceptions. RELEX systems have an archive of all users’ past actions. Therefore it’s easy to identify and analyze the kind of products (or which specific products) generate most exception processes. If the same products are being handled within the exception process, again and again, it’s a good idea to build a automated business rule to manage those products differently in the first place. If that’s not possible then you can build an automatic response to any given exception. In practice, with the business-rules engine, the main user can set up all the same responses from the user interface that a normal user can. Having built the rule the system takes care of the issue, and the management capacity is freed-up to deal with other exceptions with a lower business priority.
Cut down the number of flagged exceptions so you’re left with the most business-critical ones that you can actually handle. Then your KPI-indexed results improve, and you and your staff can go home having emptied your in-trays. If you have more exceptions than you can handle then people will start to set priorities themselves and these won’t always align as well as you’d like with your overall goals.