Two units within the SKF group, SKF Reliability Systems of the Service Division and SKF Industrial Division Manufacturing, combined their talents to test the benefits of using decision-support software within the manufacturing process.The need to optimise the efficiency of equipment has a significant impact on profits, affecting productivity and quality. Like other industrial companies, the manufacturing side of SKF experiences the same pressures to increase productivity without increasing costs.
So when a pilot project to achieve this goal was proposed last year to the SKF Hanover plant in the US, it was quickly initiated.
The project was based on the implementation of an industrial decision-support software under the name of @ptitude, developed by SKF Reliability Systems. It was implemented on a part of a spherical roller bearing manufacturing process.
The @ptitude system consists of software coupled to a knowledge database. The software takes disparate pieces of data collected by various monitoring systems and marries them, using fault symptom logic, to produce automated notification with specific actions for correction of the fault.
The system has many functions but is designed to achieve a single objective: To make an existing and effective decision process more efficient.
Essentially, the @ptitude system does this by:

• Using reliability-centred maintenance-based rules that detect faults and define actions.
• Providing quick and easy electronic document-management features.
• Providing visual representation of asset health. (An “asset” is defined here as a process, machine or component that has attributes unique to a functional requirement.)
• Notifying any number of people using various media.
• Acting as a knowledge repository.

This information is available through a common user interface to all personnel responsible for the production process and assets. The software operates on local workstations, allowing the process and asset condition to be viewed simultaneously by everyone. In addition, all personnel can view information through links to electronic documents, wherever they are on the network.
The normal decision process in a plant involves people making routine decisions at all layers of the decision process. People have the knowledge to make decisions on the raw data, identify symptoms, link the symptoms into faults, define actions and then execute the actions. This is the restoration loop. People typically spend 90 % to 95 % of their time in this loop – approximately 50 % to 60 % of their time getting orientated to the data and then the symptoms, and approximately 30 % of their time identifying faults and turning them into actions. The action of restoring the asset has direct value to the process; the orientation of data into symptoms and then faults only has value as a necessary part of developing actions. If 60 % of a person’s time could be directed towards the improvement loop, the process would benefit directly.
The @ptitude system allows the knowledge of individuals to be captured. Once captured, this knowledge supports routine decision for sustaining the process so that the individual’s expertise can be applied to improving process performance.

Implementation lessons
Specific lessons emerged in five main areas. These were:

1. Know your asset and process data and relationships.
Initially, knowing these relationships did not appear to be a significant issue; after all, the people involved in the pilot project were operating and maintaining the process. Once the information was collected, however, there were differences found in the knowledge surrounding the process and the assets in the process. The lack of a full functional model or up-to-date process and instrumentation diagrams was identified as the reason for this. In future, these will be more fully developed. Also, all the principals in the implementation team will agree on the documented information to use before the knowledge database is populated.

2. Know the capabilities of your process infrastructure.
Monitoring technology capability was well understood. However, what was discovered repeatedly, for all the technologies and tools that made up the support infrastructure of the system, was a gap between the current levels of development and the required levels.
In the case of the computerised maintenance management system, there was a need to identify assets in more detail and to augment coding for work-order tracking. In this case, the gap was so large that the pilot project team elected to deal with this later as a separate project.

3. Knowledge management.
It is important to understand what knowledge and data need to be shared and to identify the knowledge owners. The responsibility to structure the information needs to be assigned, and the requirements for presentation of information need to be clearly communicated.
The process was being run effectively, but the individual effort required to maintain it was very high. As knowledge was sought and captured, pockets of information were made visible across the organisation. The exercise of capturing this knowledge produced additional opportunities by raising the awareness of subtle inefficiencies in the process operation.

4. Expectations and understanding.
The actual goal of the pilot was communicated and understood, but follow-up meetings as a group and individually were required to turn these individual expectations into a communal expectation and raise the understanding of each person’s role as part of the whole process operation. Once this was achieved a communal focus was gained and the project moved ahead more quickly.

5. Keep your eye on the ball.
The nature of a pilot project means that the scope and resources are deliberately constrained so that the maximum can be learned in the shortest amount of time with minimal resources. The focus is on the pilot, and there is a tendency to lose sight of the broader, long-term objectives.
The implementation goal was to increase total value added in the pilot execution while further developing the implementation process and technology for the @ptitude system. This focused effort tended to shade the requirement to produce a system that could be easily sustained as part of the normal process operation.
Keeping your eye on the ball means not only achieving the goal, but also putting in place a process to maintain the goal and develop it further.

Pilot benefits to date
Previously, 25% of the vibration department’s time was spent in analysis of alarm exceptions and producing fault reports from the vibration monitoring system. The introduction of the @ptitude system reduced this to 5 %. The net benefit is a 20 % increase in available time to work on improvement projects. These projects are:

• Motor-quality assurance programme.
• Spindle-quality assurance programme.
• Programme to reduce the amount of scrap and rework.
• Root-cause failure-analysis programme.
• Precision maintenance programme focused on a higher level of maintenance effectiveness.

Each activity is directed towards improvement of the process and has had a direct impact on process performance. It is important to recognise that the @ptitude system has not replaced the analyst, but allows his skills to be used to greater effect inside the improvement loop.
With completion of the pilot project, a financial benefit can be drawn from the 20 % of time saved by the vibration analyst. This equates to approximately 30,000 euros. This is knowledge capital that is being re-invested in improvement activities that yield a higher return.
The benefit of investing time to improve process loop activities is shown by the positive movement of strategic performance indicators, such as the overall equipment effectiveness (OEE) and total value added (TVA). The benefit of specific improvement projects or practices can be measured using tactical performance indicators, such as mean time between repair for motors and spindles.

Intangible gains
The @ptitude system pilot project was a catalyst in bringing maintenance and operations closer to understanding each other’s objectives. Two shared objectives exist – to sustain current performance levels and to continually improve performance. @ptitude provides a framework that allows maintenance and operations to view the same information and act with synergy directed at efficiently sustaining the process, and at continuous improvement.
The @ptitude system implementation requires a certain level of infrastructure and internal organisation in order to function correctly. During implementation of the @ptitude pilot project, attention was paid to how the process operated and the assets were maintained, as well as how their health was monitored. Initiatives driven by the implementation of the @ptitude system included:

1. Online channel performance monitoring.
A small-scale performance-monitoring system was implemented to continuously monitor the cycle times and process flow through the bottleneck machine. Previously this was done manually on a periodic basis. The results indicated that after a machine was set up, there would be a period of small stops while the machine was “dialled in” to achieve optimum rate and quality. Machine operators knew this but accepted it as part of normal operation. Raising awareness through the @ptitude system software allowed SKF Hanover to address some of the issues related to dialling in machines.

2. Operator inspections.
To support the full capabilities of @ptitude, a small-scale inspection “programme” was temporarily introduced in the spherical roller bearing manufacturing cell used in the pilot. This programme used a handheld industrial portable data acquisition device called MARLIN™. The MARLIN system operates as an electronic clipboard that can be used to record parameters such as pressure and temperature. The symptom-fault logic trees in the @ptitude system allow these data to be married with other mechanical and performance data, identifying specific faults and producing actions.
Previously this information was not routinely recorded. And when it was, it varied from operator to operator and lacked consistency. Settings varied, particularly in terms of lubrication rates.
The operator inspection programme underscored the need for an operator-driven preventive maintenance programme in all channels. SKF Reliability Systems and SKF Hanover have brought a team together to begin implementation of such a programme.
The @ptitude system provides the means to capture, share and act on information obtained by the operator inspections.
An additional benefit of the operator inspection initiative was a review of the lubrication requirements for the spindles. This is currently being evaluated by SKF application engineering to provide information on the optimum lubricant and correct rate for each spindle.

3. Consolidating documentation.
The @ptitude system has an electronic document-management capability, which is at the core of the knowledge management focus of the tool. During the pilot project all personnel were tasked to bring the documents they used up to date and place them in a common repository on the network, linking them to the appropriate folder in the @ptitude system. This exercise yielded 300+ electronic documents and drawings. The common interface immediately shared and made this information readily available.

4. Reviewing and augmenting performance indicators.
The initial objective of measuring the impact of the @ptitude system resulted in the requirement to review and augment existing performance indicators. This concluded that the strategic indicators of quality, availability, rate and TVA were well tracked and documented. The same could not be said for the tactical indicators. Five additional indicators were chosen: a) spindle mean time between repairs (MTBR); b) spindle repair costs; c) motor MTBR; d) motor repair costs; and e) proactive vs reactive work orders. These indicators now show positive improvement.

5. Retention of knowledge.
Individual and collective knowledge about maintaining asset health has been captured by @ptitude. This knowledge is now retained and shared through the @ptitude system and is now available even if the key personnel who provided the knowledge are not.
Maintenance and operations have been brought together to work on the solutions from the data captured in these studies. The system software will serve as the bond to maintain this new synergy.

Mark Frogley
SKF Reliability Systems, San Diego, California, USA