Ilmor Engineering’s Operations Manager, Rupert Russell, depicts some of the difficulties they face, so that the full scale of the challenge may be fully appreciated: “First you need to understand that we currently have over 85 IRL engines in existence, each of which requires a complete component lifecycle history unique to that engine. That’s 3,000 components in each engine. Then you need to appreciate that we have 2 distinct yet interconnected areas – engineering and design, and manufacturing. These domains bring their own challenges, not least because each utilises the Bill of Materials (BOM) in a different way.”
The key concerns of the engineering division can be summed up by the questions, “What part is it?” and “Is there one in stores?” Given the ongoing development that is an integral part of the business, the engineers are dealing with a continually changing BOM. To complicate matters further, all BOM information has historically been held on the company’s ageing textbased business information system. A typical scenario would be an engine builder disassembling an engine, identifying a part that needs replacing, and then requiring a replacement very quickly in order to reassemble the engine. To achieve this the engine builder needs to be able to accurately identify the part concerned, and then communicate this to the stores where someone in turn has to interrogate stock levels to check availability. As Russell comments, “Change is the nature of the beast – parts change rapidly which necessitates complete visibility of what it is you’re dealing with.”
External events, some of which by definition cannot be easily predicted, also present considerable challenges to Ilmor. An example of this was the change in regulations introduced in 2004 to reduce engine capacity from 3.5 litres to 3. This naturally meant the redesign of a considerable number of components and the creation of yet further part numbers. However as Russell explains, this wasn’t the complete picture: “To add to the complications the regulations came into force mid season to coincide with the Indy 500 race. Not only did that mean that all of our redesigned engines would have their first ‘real’ race scenario in a hugely public environment, we also had to gauge how many components would be required for the earlier part of the season for the old specification engines.”
A final engineering consideration is the element of retrospective component replacement which again demonstrates the need for complete component traceability. If a component unexpectedly fails it is imperative to discover if it is an isolated incident due to a particular combination of factors, or whether it’s a potential fault that could affect a particular batch, or in the worst case scenario, every other identical component. Depending on the outcome of what is discovered, all the affected components must then be identified and either replaced or modified accordingly.
The manufacturing division’s biggest challenge is supplying the demand from engineering. In order to do this, manufacturing needs to maintain rigorous stock control by keeping on top of suppliers and subcontractors alike, in addition to managing its own capacity requirements. This is compounded by the specialist nature of components, some of which can take 12-14 weeks to either order or manufacture, which presents what Russell describes as an extremely difficult balancing act: “On one hand it’s unacceptable not to be able to supply a part when a customer requires it. On the other hand, given the continual nature of change we cannot over order a particular item because we would then be left with unacceptable high levels of stock which would essentially be redundant and worthless to us.”
Ilmor also have a unique batching system in place, which is largely driven by the need to maintain complete product traceability. Ilmor require suppliers to physically incorporate a unique supplying batch number within the component, which is different to the actual final batch number used internally within the ERP system. What they have in common with other very high specification manufacturers is the need to maintain meticulous quality control through a rigorous goods inspection regime and continual supplier relationship management.
As Russell comments, “Taken in isolation it’s a challenging business. Because all of these issues are happening concurrently and interacting with one another, it’s vital to keep on top of the bigger picture and see exactly what’s going on. At any given time there will be ongoing design necessitating the manufacture of new components.”
Given the sheer complexity of business Ilmor have always relied on IT as an enabler to decision making – historically in the form of a text-based system called Command which sat on a VMS platform. Originally installed in the 1980’s this has been extensively customised to deal with the very particular demands made on it by Ilmor’s business processes. Russell is adamant however that one reason for the company’s success is what he describes as a ‘culture of information sharing.’ “Individuals are actively encouraged to take responsibility for their position in the information chain. They need to be aware of who they need to share information with and to then carry that out.”
Even with this culture in place, Ilmor were having increasing issues with their legacy system. While the engineering users liked the speed of the text-based platform, the fact that it was not Windows-based meant that it often required very specialist knowledge to get access to anything other than basic information. Management reports were especially difficult and needed to be programmed into the system and then exported into spreadsheets. The accounting functionality was also weak. Month end accounts took literally weeks to compile. There was no drill down facility or interrogation functionality so additional queries had to be continually re-entered into the system in order to get the precise information required – all of which was very time consuming.