My Encounter with Enterprise Resource Planning Software for a Steel Plant.
I do not believe that ERPs are sure-shot enablers of Corporate efficiency- and I am not alone.Too many horror stories of disastrous corporate experiences with ERPs abound.For starters read Patricia Barton's article.
To be fair, Ms. Barton's article lists those companies which have reaped outstanding benefits from ERPs as well.Which leads to the issue of the corporate planning required for a successful ERP implementation, an area where Management Consultants operate. Since I am not one of this breed, I will avoid this angle altogether.
My own experience occurred some time ago, and relates to my background.I am an old school engineer, experienced in Steel Plant production and projects. Along the way I acquired an interest in Java programming and Relational Databases.
The company I work for plunged into the implementation of an ERP on the advice of its auditors. Although not part of the company's computer department, I had one interaction session with the Vendor as one of the users in the Production Department.I received a rude shock when the vendor insisted that there had to be a standard bill of material for a particular product.
Now a steel plant has a particularly nasty( from the point of view of an ERP implementation) mix of batch and process production: the bill of material is usually obtained as an output of the analysis of production data rather than an input.My attempts at explanation were disregarded, politely by my own Computer Department, and assertively by the vendor.I clammed up, waiting for the unmentionable to hit the fan- which it unerringly did, six months later.Bitter wrangling, blocked payments, a stalled program- all the typical ingredients of a botched project were the outcome.
The lack of a highly experienced project leader, or the lack of domain knowledge on the part of the vendor, or the lack of adequate Management appreciation of the hazards of ERP implementation could have been the cause of this problem.So at an ERP conference conducted by one of the World leaders in ERP implementations I broached the problem of the Production Module for Steel Plants to one of their experienced Sales Managers.
"Steel?" was the reply."That's a process industry. The production module doesn't work too well here."So I learnt nothing new. I battled on.
"Why don't you guys have user-friendly data input?" I asked."Typically, a Steel Plant generates dozens to hundreds of production reports a day. These reports constitute the Company's data warehouse.No manager would like to scrap these, they give him quite a bit of control over the production process.Much quality and cost improvement measures follow the analysis of this data.They are filled out by busy operators and supervisors as part of their job and cost nothing to generate. Why do I need to hire a team of data-entry operators to fill out a subset of this data separately on a computer, constantly impeded by a computer system that complains incessantly about invalid data input?"
"Subset, eh?" was the reply."Why don't you capture the input as it is in a separate database, to be ported directly to the ERP application on an intermittent basis?"
Now that was a thought.Fed up by the delay in ERP implementation, I had installed a network-enabled Java application with an embedded open-source database at the company's Galvanizing Lines.By almost slavishly following the existing production report format, I had managed to coax and cajole the supervisors to simultaneously enter the data in the computer and fill in the production reports.I had designed complex queries that allowed me to generate the type of answers that a Manager needs at the click of a button.It was a non-communicating island of non-communicating information, granted, but it provided valuable information in its own right.All I need to do now is to write a separate application that will upload the required subset of data from the embedded database to the one residing on the ERP server: a very doable project.
As far as the "invalid data input"is concerned, this relates almost exclusively in Steel Plants to incorrectly identified input batch numbers ,packet numbers or coil numbers.The best way to resolve this is by using barcode readers and writers.
As we do not use these items, there will have to be manual intervention at the data transport stage.Even so, it is infinitely preferable to the drudgery of having to read and retype hundreds of fields in a day, praying all the while for no human error in the process.
Above all, the emergent model is now intereting.We now have two tiers of information: one at the operational level, useful for all kinds of analysis not interesting to the Corporate Office. The other, a subset of this data, automatically generated through computer program, goes into the ERP.There is no inconsistency.
What will be the outcome? Maybe I'll have something to say once the project is done. Purists might complain, but life is a compromise.Meanwhile we may save the ERP yet.
I am going to develop this idea further. Please click on this link for the next article.
No comments:
Post a Comment