InfoWorld Nederland has a fascinating and surprisingly deep article on the implementation of a fairly customized ERP system at Maruti Udyog, one of India’s largest automakers. Regular readers know that I’m not exactly a fan of software systems, but I’ll push that bias aside for a day to focus on a few interesting parts of this article.
Maruti is apparently fairly lean, at least from an inventory standpoint.
As the backbone for all operations in the Rs 14,653-crore (US$3.5 billion) auto company, IT enables the entire span of Maruti’s business — from maintaining a less-than-a-day inventory and manufacturing 700,000 cars per year, to selling cars worth about Rs 66 crore in a single day.
Although many of us who have visited the supposedly lean auto factories around Detroit will be immediately suspicious, and would look for trucks of raw materials parked in various dark alleyways nearby waiting to deliver their loads "just in time."
The cycle, from forecasting to production, is tightly integrated. For example, if a dealer forecasts that over the next 15 days, he would be buying 100 cars, the system processes a production plan with his forecast. It then gives him a delivery schedule stating that he will get, say, five cars of a particular color on the first day, a number of cars of the other color on the second day, and so on.
Hmmm… forecasting. Auto dealers will want to maintain some level of inventory so that potential customers can kick real tires, but I guess this isn’t too bad. At least the ERP system is working off of actual demand instead of a "how can we keep the factory working" criteria… which leads to overstock, high inventory, then discounts and paying employees not to work.
The shop floor functions with such high levels of precision and synchronicity that, if a car is in a paint-shop and its engine is being produced at another location within the plant, both functions culminate at the same time before arriving at a designated assembly line for production. IT also helps in putting the supplies in the very sequence they are going to be used on the assembly lines.
Ok, but is ERP necessary for this? Or should process flows be simplified, subassembly permutations simplified, and kanban used to ensure the right part is in the right place?
The hourly inventory is planned based on the production sequence. So, if a car is going to arrive at the weld-shop at a certain time of the day, the component must reach the operator at the same time. This is achieved by asking the supplier concerned to supply the material an hour before the component deadline.
Once again, is ERP really necessary, or would a kanban do the same trick. There are, presumably, standard sets of materials. Instead of trying to massively plan and control inventory down to the minute, thereby requiring a rather massive data transaction system, a kanban could ensure the right part is always available. When it is gone, a signal, physical or electronic, is sent to the supplier. Kanban quantities are developed to ensure sufficient quantity covers the resupply interval.
The article then goes on to tell the story of how electronic systems were implemented, removed, and re-implemented at Maruti over the years. A painful story, albeit with some success, involving hundreds of IT people.
High [IT personnel] attrition rates forced Uppal and his team into a premature migration to ERP, which turned out be a huge mistake. Since Maruti was finding it difficult to sustain the Oracle-based enterprise application, the IT team thought a full-fledged ERP would be the panacea. Despite the process re-engineering that had been done less than a year before, the IT team decided to undertake another project to reverse to an ERP platform again. "It backfired on us," rues Uppal.
But they kept plugging along at it, and eventually achieved an implementation that worked… sort of.
This time, Maruti re-engineered its processes and successfully migrated to ERP. "It was right time to re-look at ERP as our backbone and standardize the way to handle various business functions such as finance, sales and customer relations," says Uppal.
It appears they avoided the first challenge with most ERP systems, where an organization has to change it’s business processes to conform to the methods predetermined by the ERP software vendor. Maruti first re-engineered their processes, then implemented an ERP methodology around those processes. Sounds great… until you run into one of the fundamental problems of massive ERP systems: change. What happens when a fundamental process needs to be changed? How easy can it be done? Can it be executed fast enough to keep up with the competition? Or are they effectively locked in until the next great ERP implementation comes along?
I do take pity on one guy…
A general manager of finance was roped in as project manager with IT supporting him on the technical end.
"Roped in" is probably an understatement. I wonder how badly this poor soul had to screw up in order to be given this assignment. Or perhaps his boss convinced him this would be a "challenge."
Maybe my bias was not entirely hidden. ERP can produce some spectacular results by improving operational coordination and reducing inventory. But it’s essential to ensure it is also flexible enough to handle evolving processes, agile enough to handle operational problems, and friendly enough to allow employee knowledge and creativity to be leveraged. Staring at a computer screen and following commands is not leveraging knowledge.