This article is about OEE and how to avoid mastodon projects or to stumble on the finish line because you are developing your features in the wrong order. Here are some tips from our own experiences and lessons learned about how to implement great system support for the aftermarket.
In our previous articles about the life of innovative machine manufacturers and their aftermarket (links to the entire series can be found at the bottom), we described which business systems are needed to handle the aftermarket efficiently. We also described how your connected machines will do a large part of the work in the systems for you. We have also ensured that the machines’ data can now be retrieved from the control systems. There it can be saved and in a smart and easy way and is accessible in a cloud service with a large range of tools and functions. So what can go wrong now that all the infrastructure is in place and only user functions and interfaces remain to be developed?
As a matter of fact, it is in this phase that almost three-quarters of all IIoT projects fail. The most common reason is that at this stage many stakeholders come in. For everyone to be satisfied, the projects are allowed to swell. The solution is there at such a late stage that it is no longer relevant.
Implement major development projects with a fair dose of democracy
There are two extremes of governing a project. One is a total dictatorship where only a very small group has insight into the project. The opposite is absolute democracy. In the first extreme, there is an imminent risk that staff will feel overwhelmed and forced on yet another new system they didn’t want or see the benefit of.
In an absolute democracy, there is a great risk that the project gets stuck dealing with small detail issues as color choices of command buttons or that different stakeholders are allowed to design their own sub-solutions that do not create a good whole when they are to be joined together. 
The balancing act is not so difficult if you use democracy for the big and general decisions around the solution. A steering committee for the project should include representatives from all major departments who will use the solution. Partly to monitor so that their interests are included in the plans, partly as a communication link back to their own department about how the project is going and what decisions have been made.
Keep the first version simple with clear and measurable goals for improving OEE
If the basic features are not in place and stable, it will be difficult to trust the rest. In a long-term digitalization project, it is a good start if the first version has only a few but well-selected functions. They can even be designed on a fairly basic level, as long as the design and ease of use are perceived as promising.
Set expectations by dividing the project into clear stages. Create equally clear, reasonable goals for each stage, where the benefits should be obvious and relevant to everyone. Perhaps the connected machine’s new integration with PLM / PIM and CRM should have different goals for each department, such as:
- Service: The proportion of incorrectly sent spare parts should be reduced from 20% to 10%.
- Support: The number of questions about manuals and instructions should be reduced by 30%.
- Sales: Data-driven sales should provide 20% more direct sales than traditional call sheets.
- Pilot customer: The proportion of downtime days due to waiting for spare parts should decrease with 50%.
Involve a customer in the project of getting great system support for the aftermarket
The staff responsible for production, maintenance, and quality at your customer’s end will probably be just as interested in being able to measure improvements and reduce the time for manual reporting as your own colleagues. In our experience, this type of project does not significantly disrupt the customer’s production, so it is usually not difficult to find pilot customers.
Prioritize the feature development in a simple but methodical way
A new feature must provide value. OEE and thus making more money and saving time are values that are high priorities in most businesses. It can be a little harder to measure how tedious a task is or the discomfort of not being able to trust the numbers in a report.
A simple method that has helped several of our customers make more rational and established choices is to build a selection matrix and vote using freely chosen value categories. Here is a fictitious example of how it can be used:
One of three proposed features will be selected by the steering committee for the next stage:
- Video support with built-in drawing tools, which facilitate communication with the customer
- Interface for smart watches to the system’s most important alarm functions
- OEE module that visualizes three key values from customers’ production
All stakeholders can vote for the feature where they see the greatest effect for a certain category, such as which function would save the most time. If you don’t see a clear effect for a category, don’t cast a vote. When voting is complete, the number of votes is added together. Different categories can also have different weightings and voting points. If this is done with a printed matrix and “chips” of paper that are betted in front of the rest of the group, the participants usually think about it an extra time before casting their vote. Serious results in a playful format.
Feel free to reuse features and design, but tailor the information
In a cloud solution where users access their tools through a web portal, it is common to build dashboards and work views using various modular blocks. Sometimes called widgets. A dashboard should provide a quick overview of the status of the most important values for a specific professional. There, the widgets are usually charts, trends, and ranking lists. In a work view, you place other types of widgets such as chats, archives, service book, analysis tools for comparisons, etc.
With the cloud platform’s built-in features for managing users, it will be possible to control rights to various widgets in detail. You can also restrict the right to information in a widget such as a salesperson only listing their customers’ machines in a list. When we say that it is important for each role to have tools that are optimized for the tasks, this does not mean that they must have completely unique widgets. Instead, try reusing the same widgets for many different roles. Just make sure they only show data that is relevant to the role.
For best OEE don’t be careless with testing, get help from professionals
For most who purchase support resources for a digitalization project, there is rarely any discussion about the estimate for the number of hours for a system architect and developer. It is much more common for the project manager, interaction designer and/or tester to come under scrutiny. If we stick to the testing, final testing before delivery approval might be a very difficult and tedious task.
Most are not used for methodical or automated testing. “Clicking” arbitrarily will never be good enough. If errors and bugs are discovered later, it will take up a lot of time and energy. This applies both in projects with a fixed price and with an hourly rate. Bring in experienced help who tests methodically and who neutrally assesses what are acceptable shortcomings and what are not.
Taking the next step
Do you want more tips or help with OEE and how your company should go about testing more methodically? Contact us!
The series of articles about innovative machine manufacturers and their place in the aftermarket so far:
- The costs to avoid in your aftermarket
- Why the system support is deficient when it comes to the aftermarket
- How to make money in your aftermarket with connected machines
- How your aftermarket benefits from a data-driven service book
- Increase sales in your aftermarket with industrial iot services
- Oee and how to develop your features in the right order (this one)
- (Subscribe)
