"Subbu, what is the progress in Costing?", asked Mr.Natarajan, the GM of the company and the project sponsor. It was early winter in 2004. We were all attending a project steering committee meeting to discuss the project status. Subbu was the key user in charge of process costing.
"I don't know", Subbu responded sarcastically, "I have no idea how costing work in Oracle. Ram has not yet explained it to me. Please ask him.", Subbu replied.
"Probably he also do not know how costing works", Subbu added for good measure.
Everyone looked at me. I id not have anything to say. I looked out of the window.
********************************************************************************
Sometime in the month of June 2004, Vikas, my ex colleague, called me.
"I have an opening to implement Oracle Process Costing for a leading jewellery company. Are you interested?", he asked
In my four years of implementing ERP, I had not implemented Costing solutions. I was a bit hesitant. I told Vikas as much.
He had more confidence in me than I had. "I have seen you work Ram. Your concepts are clear and you are a quick learner. You can easily handle it.", he assured me.
I said, yes, I am interested.
Things moved very fast after that and by August, I was in the office of the customer, as 'Lead Consultant - Finance and Costing'
******************************************************************************
Costing is a key process for any manufacturing company. Costing has two implications. One is the profitability, so called Gross Profit which is nothing but Total Revenue minus the Cost of Materials Sold. Every organization has process to keep track of the sales revenue. However, most organizations lack the systems and process to accurately capture the cost information. This hampers their ability to calculate profitability. Another impact of not having detailed cost information is the inability to analyze the cost elements and tailor effective cost reduction interventions.
The second implication of costing is related to inventory valuation, which is the valuation of closing inventory. Inventory is one of the key elements of 'Current Assets' in the Balance Sheet and investors place a lot of importance to its valuation. Without accurate costing, the inventory valuation becomes suspect.
********************************************************************************
The customer was implementing the ERP application from Oracle called as Oracle E Business Suite. This is a suite of applications to handle various business ares. These applications handle Purchasing, Inventory management, Manufacturing, Order entry and fulfilment and Financial transactions and reporting. Due to the peculiar nature of the business, the customer had decided to use Oracle Process Manufacturing, also known as 'OPM'. I was in charge of OPM Financials that handled manufacturing costing and accounting.
OPM Financials is the most complex of what are known as the 'Core Applications'. The core applications handles the core business processes as mentioned above. Since I had not worked on OPM, I got down to studying the application in right earnest.
I was handicapped by the fact that I had know conceptual clarity on the costing process. I have found that it is easy to learn the application if you are clear of the underlying business concepts. Not having conceptual knowledge and not knowing the application, made me a complete novice.
For an ERP consultant, understanding the business concepts (called 'domain knowledge' ) is about 70% of the job. Domain knowledge helps them to intelligently engage with the customer,provide value adding recommendations and build credibility with the customer.
In order to build up my knowledge of costing, I purchased that mother of all costing books 'Cost Accounting' by Jawahar Lal. I also downloaded application the user guides provided by the product vendor, in this case Oracle.
I got down to it in right earnest.
The complex OPM Financials application is closely linked to Purchasing, Inventory Management, Process Manufacturing and Order fulfilment business processes. This meant that to learn OPM financials, I had to learn the entire suite of applications including finance and accounting.
Having started with just one application, I was not looking at having to learn the complete suite of Oracle Applications.
And this was my first Oracle EBS Implementation project !!!
In addition to being complex, the OPM application is counter intuitive. Take for example costing. In normal discrete manufacturing (One of) the costing method is called Transaction Weighted Average Costing. In this method, each material receipt transaction modifies the cost of the item. For example, let us say you purchased 10 Televisions sets at a cost of 200000 rupees. Each TV now costs 20000. Next you sell 5 TV sets, they are sold at a cost of 20000 per TV set. Now let us assume that you purchased another 25 TV sets at a cost of 625000, which means each TV in the new lot costs 25000 each. Currently we have 30 TV sets in stock with a total value of 725000 and the cost per unit of TV (as per Transaction Weighted Averaging) is updated as 24167. Any new TV sale will be costed at this value for the purpose of profitability calculations.
This is intuitive costing.It is easily to visualize the cost flow.
OPM costing uses a method called Period Moving Average Costing (PMAC). In this method the cost is calculated on a monthly basis and all the material issue transactions are costed at the PMAC cost. Since cost cost is calculated at end of the month, you can get the profitability information only at the month end. This is frustrating CEOs and CFOs who want real time profitability information.
Final complexity relates to the Jewellery industry. The bill of material in the industry consists of a few raw materials that are used to produce huge number of finished products (more than 300000 items). The the 'Inverted Pyramid' Bill of Materials in the industry coupled with huge number of finished products adds to the complexity of costing in the industry.
******************************************************************************
Project review meetings were very difficult for me. Every month we will have the steering committee meeting. The invites included the senior management from the three main stakeholders, my company, the customer and Oracle being the product vendor.
By December of 2004, all the other streams in the project had made good progress. Product emo had been done, requirement gathering sessions were in full progress and the consultant and the customer team were walking around with a clear sense of purpose.
Except for costing, my module...
I was yet to get some handle on PMAC costing. Since costing was the end outcome of transactions in the areas like Inventory, purchasing and Production, I could demonstrate my application only after all the other applications were configured and process flows were tested,
"How is costing progressing?", Mr.Natarajan,, head of steering committee asked Subbu.
Mr.Natarajan was the General Manager of the company and the project sponsor. A jovial person, he always had a twinkle in his eyes, which recently was turning into a frown every time costing was mentioned.
Subbu was the costing user associated with me. He was blunt.
"Ram has not shown me anything yet. I don't know how costing work in Oracle.", Subbu replied.
All eyes turned to me.
It was difficult explaining to the group that the transactions done in demon instances using demo items were difficult to cost and that OPM costing was different from the costing methods.
"I am working on it. Hopefully I will be able to show it in the coming fortnight", I wearily replied.
********************************************************************************
The PMAC cost is calculated on a monthly basis. It uses inventory value or the previous period and averages it with the transaction values of the current period to arrive at a cost for the current period. The costing is complex and is done by a costing engine. For the cost to be accurate in the current period, costs should be accurate in the previous period as well. The challenge in demo instance is that there is a lot of incomplete data that complicates the costing engine. To accurately understand the impact of costing, you have to configure the system specifically for this company, create new items and then test the process flows. This was not yet done. This is not a challenge for other consultants since they are entering new transactions in the demo instance and showing the same to the customer. I was not able to do the same for Subbu since previous costing periods, some going back to 3 years, were still open in demo instance.
********************************************************************************
At the beginning of the project we had a team building exercise where the team spent two days in a resort in Bangalore. The ideas was for both the teams, client team and ours, to work together on challenging tasks to build bond and trust. The exercises were held by two ex-armed forces personnel who had started their own company. Most of the challenges were physical like river crossing, rope climbing, tree climbing and other obstacle courses. Since I had spent a lot of my childhood on trees, these exercises were cinch for me. For my expertise in these exercises, team named me Tarzan.
Midway through the project this name attained a new relevance. The costing method that we finally implemented was new and had a number of bugs. We laid out a process to handle these bugs. As soon as we identified a bug, we raised a support ticket with Oracle.Those tickets were called Technical Assistance Requests (TARS). I ended up raising more than 200 TARs and I was named (again !) as 'TARzan' in this project.
In any ERP implementation, there are some brilliant and colourful consultants who make the project interesting, add significant value to other consultants and make the time spend on the project worthwhile. This project had many such people. One of them was the PM from our company. He was more of an independent consultant and could do great work on his own, but handling a team of professionals in a highly stressful project was not his ken. Since I was handling a complex application with a difficult customer, very often I was the targets of his 'project management'.
It was comical, if it were not so stressful. I remember one incident. One day he wanted the status of some activity related to costing.
He came into our room.
"Guys, don't treat meas a PM. Treat me at your level, as a consultant. Ram, what is the status of costing?", he asked me.
I was also under tremendous stress and was on the edge. That was the phase in the project when nothing was working and the consultant is really stressed out.
"You are asking me as a PM or as a Team Member? ", I asked.
He folded his hands, "Boss, please give me that status. I will fall at your feet if you want", he pleaded.
Everyone in our team was embarrassed by this behaviour. In hindsight, I am not proud of what I did. But the project was tough and the environment was dysfunctional.
That is not an excuse, though.
Shantanu was another colourful character. He was the OPM process consultant and at that time he was one of the best in the world. He could be very funny or very biting if he chose to. He was what you will call a 'Techno-functional' consultant. He was brilliant from both technical and functional perspectives. Even senior technical developers used to take advice him n the details of coding.
He was a storehouse of anecdotes.
"Do you know the difference between a function and a procedure?" he once asked the team. These are two terminologies used in Oracle's coding language called PL/SQL
No one replied.
"Both perform the same activity, but the procedure returns an output back to the code", he explained
We asked for an example.
"Let us say I write a program called 'FetchBalls()'. I want the code to bite off 'Hishi Babu's' balls. As a function, the code will bite off 'Hishi Babu's' balls but will not do anything further. A procedure called FetchBalls() will not only bite off Hishi Babu's balls, but also return the balls back to the code", answered Shantanu.
At another time, Shantanu announced, "Oracle is like a four legged animal."
"Why so?", we asked as if on cue.
He was frustrated and was writing a program to rectify some data errors directly in the database, also known as backend.
"Because all the important activities happen in the backend", he replied, "For example, I would not have been able to rectify this data error from the front end", he explained.
*******************************************************************************
"Let's have a beer", said Bhasin.
As mentioned earlier, the project location was in Hosur, forty kilometres from Bangalore, where a few of us were staying. While the project team size ebbed and flowed with the project requirements, three of us travelled between Bangalore and Hosur every day through the duration of project, me, our PM and Vijay Bhasin.
Bhasin was a junior consultant in charge of OPM, working with Shantanu. A typical Punjabi was he, highly intelligent, gregarious and very funny if he chose to.
It was a tough day at work and three of us were on our way back in the company provided vehicle. It was a warm evening and despite AC being on in the vehicle, we were feeling sultry and tired.
"Why don't we have a beer?", suggested Bhasin.
Good suggestion. We stopped at a bar and bought a few cans of beer and some munches.
We consumed it over our way home and the ride was very pleasant. We discussed issues, bitched about the client users, criticised our company, pontificated on politics...
Having a couple of beers on our way back became a tradition. As our team sized increased, we pulled more and more members in this activity.
This is when I found my taste for Fosters beer.
********************************************************************************
Sandip's hobby was share trading and investments.
Sandip Daruka was the finance consultant in our tam. An accountant by profession, soft spoken Sandip had a clear eye for issues and quick solution to most of them.
Sandip and I shared a passion for stock market. Based on advice from his broker, Sandip had purchased few share of a company called Ind Swift Labs at a price of about 30 rupees. Over the course of the project the shares of the company crossed 200 rupees and Sandip strutted around the room like he was the big bull of of Sensex.
When we started the project at the end of 2004, Sensex was trading at about 3000. As it crossed 4000, I made a bet with Sandip.
"I will bet 1000 bucks that Sensex will not cross 7000", I grandly announced.
To my dismay, Sandip accepted the bet.
Before we knew, Sensex had touched 8000 on its way to the mega bull market which took it to 22000 before it crashed in October 2008. That was a 1000 rupees that I was glad to lose.
Staying on with stock market..
To make money in stock market, you need to do two things. One identify opportunities and two, play long term. Despite my professed knowledge of Stock Markets and investments, I sucked at both.
Consider the facts.
In 2004, I was working for India's largest IT consulting company. And we were implementing the project for India's leading Watches and Jewellery manufacturing company.
In the year 2005, my company came out with its IPO. The shares were priced at 850 rupees and there was a discount of 5% for employees. In addition, the company was giving very good financing options to purchase the shares.
Since I was the 'expert' on share market, my team members asked my opinion.
"The share is highly priced. There is limited upside from here. It could also fall below the IPO price after listing. I wouldn't by it in IPO. I will wait for market to identify its value", I expounded my wisdom.
I completely overlooked the employee discount and the excellent financing options.
To be fair to me, I walked the talk. I did not buy the shares at IPO.
Fortunately some of my colleagues saw me through for what I was. An empty windbag. They invested in the share of the company.
How wrong was I?
Since the IPO, the company shares have gone up manifold.An investment of 80000, to buy 100 shares in 2005 is worth 16,00,000 at today's rates, a cool 20 bagger (a share which has given 20 times returns) in about 13 years !
Another painful memory is about missing the opportunity to invest in the shares of my customer. This company was India's largest Watch maker and was venturing into Jewellery business. The business was about to explode and I did not see that.
The share was trading at 50 with a PE multiple of 150, which meant that the market was factoring the earnings explosion. This company was from India's largest and most trusted business house and had some marquee investors.
I was there, doing ERP implementation for this company. I knew the people and I knew the business. I could see the enthusiasm and excitement in the eyes of workforce. I knew that the business house had a history of creating sustainable businesses....
I knew everything that was there to know from an investment perspective.
But I just focused on high PE.
I had read that a high PE is not good. A PE of 150 meant that it will take 150 years for the investment to be paid back, the 'books' told me.
I did not have 150 years.
What I missed was the implicit expectation of 'at current earnings'. The books did not factor in earnings explosion of a franchisee business as the GDP of country grew at a rapid rate.
Had I invested 5000 rupees on the shares of my client in 2005, I would be sitting on another 50 bagger by now !!
In his book, 'One up on Wall Street', Peter Lynch explains why a common man can become a better investor than the expert. "You are more familiar with your company, you customers and the market. You can see the excitement and enthusiasm of workforce. You can see the long queues before market can spot them. You can identify a good business it it starts its first franchise. if you take advantage of these opportunities, you can become a successful investor", he says words to that effect.
I was right in the middle of two great investment opportunities and I missed both of them !!!
********************************************************************************
By February 2005, things somewhat stabilized in the project. Out team ha collected and documented the customer requirements, collected sample data, configured, the customer specific environment, completed the sample testing and stabilized the key process flows. For my part, I had tested and found PMAC costing working correctly and was confident that I could explain the PMAC logic to Subbu. We were about to start CRP1.
There are five phases in an ERP Implementation. These are Requirement Gathering, Conference Room Pilot 1 (CRP1), CRP2, User Acceptance Test (UAT) and Production Cut-over. In CRP1, the implementation team will use the customer specific data to demonstrate the basic processes as they will be applied in ERP. The team will demo how to create a Purchase Order, for example, how to get it approved, how it is released to the vendor, how the material is received from the vendor, how it is inspected, accepted, costed and accounted etc. Team will show the standard reports available with the application. Customer will review these reports for information accuracy and suggest format modification if any.
If any of the processes do not meet specific customer requirements, customer will ask to customize that process to meet their requirements. CRP2 will augment the CRP1 by including the customized processes as well. This will be a full fledged demonstration of the application ready to be used by the customer. The implementation team will show the end to end business processes and the critical reports in the format required by the customer.
Once customer signs off on CRP2, we are ready for UAT. This is owned by the customer. Their team will perform all the tasks related to project. They will verify everything including the process flows, costing, inventory valuation, data accuracy, reports data and formats, accounting and financial reports.
Once the customer signs off on UAT, the project ownership transfers to the customer, Due to this reason, it is a tough task getting the customer to sign off on UAT. In a typical ERP implementation, we identify bulk of the problems during the UAT stage only.
Coming back to the project, we started CRP1 as mentioned above. We did all the processes and I demonstrated PMAC costing. I explained to Subbu the configuration and it logic. I showed him the costing implications when an item is purchased, explained to him the evolution of cost as the item progresses through various stages in the manufacturing process, from being a raw material, through semi-finished inventory and to becoming the finished product ready for sale. I showed him valuation reports and how inventory was valued in different depots. Finally I showed him how the costing transactions were accounted in the books of accounts.
I felt satisfied about my work on CRP1. There was only one problem.
Customer felt that PMAC costing was not applicable for their industry. They rejected PMAC costing.
We were back to square uno.
*********************************************************************************
PMAC costs an item in a warehouse based on the transactions in the current period. The costing engine allocates the same cost to all the units of the item in the warehouse. The main raw material, gold, is a commodity whose prices fluctuates rapidly in the international gold market. The cost of two different units of the same item will differ based on the quantity and cost of gold used in making those units.
Another requirement is for cost rollover across periods. The the cost of a specific unit of item should continue over multiple periods till that item goes off the shelves.
PMAC, by averaging the cost of an item over each period, do not meet these complex costing requirements of Jewellery Industry. This is a low margin industry and accurate costing of each unit is very essential to ensure adequate profitability.
*********************************************************************************
The project was at an impasse. We approached Oracle, the product vendor to provide us with a solution. I so happened that Oracle was testing a new costing method called 'Lot Specific Costing' also known as 'Lot costing' which addressed the above concerns. The product was at the developmental stages and they promised to fast track the development and release it specifically for this customer. It was a risky option. A semi tested product many have product bugs that could delay the project closure. In a fixed bid project such as this one, our company was carrying the risk of cost and schedule over run.
From my perspective as a consultant, I had to start again, learning a new application, configuring , implementing and getting the customer satisfied in not delighted.
Oracle delivered the application in a fortnight along with a user manual. By now Subbu was very comfortable with my working approach.
We, me and Subbu, started testing the application. Next few months were a real struggle. We tested all the processes including purchasing , material transactions, manufacturing and sales. We started off with the basic transactions. Straight forward, no complications. We encountered many bugs during testing. For each bug we raised TARs with Oracle Support. Oracle on their part, assigned their best developer to support us.
Dinesh, the developer was a part of the team that developed the lot costing application and was fully conversant with the same. Soon, the three of us, me, Subbu and Dinesh fell int a pattern of working. Either me or Subbu will test the process and document the same. If we identify any bugs, I will be informed and will raise a TAR. Dinesh will own the issue, provide solution and we will test again and accept or reject the solution. The TAR will remain open till we accept the solution.
Over the next 3-4 months, we closed more than 200 TARs. The team even named me TARZAN.
I still remember that on the night of Diwali in 2005, I and Subbu were sitting in the office having a Web Conference with Oracle support team from US on a particularly difficult bug.
We continued testing and bug fixing while other teams were busy with development of the customizations.
Finally after a series of testing, retesting and bug fixing, the Lot Costing application was ready to be deployed.
*******************************************************************************
In the end of July 2005, just before UAT was about to begin, Subbu sent a mail to everyone.
"I am now fully ready to handle the lot costing application.", he said, "I want to thank Rm for teaching me everything that I need to know of costing application. I take full ownership of UAT for Lot Costing. I request that Ram be available to support me if I face any unexpected challenges"
That was the UAT sign-off even before UAT had begun.
Speaking at the start of UAT, Mr.Natarajan, the customer GM and the project sponsor, made a specific reference to the contribution that I had made. "We have come a long way", he said, "we have faced many challenges to reach the UAT stage. I want to make a special reference to the contribution of Ram and Subbu in stabilizing lot costing. It was a new application with a lot of bugs, but these gentlemen have patiently and thoroughly tested and stabilized the application. Thank you Ram for your efforts."
******************************************************************************
I shifted my focus to data conversion. This is one of the most important activity in an ERP implementation and one where least focus is given. Typically 80-85% consultant time is dedicated to configuration and process mapping and a minimal time is dedicated to other activities including data conversion, user training, cut over and documentation.
Data is one of the two foundations in an ERP Implementation, the other being configuration. Once you get thew two right, your implementation will meet the critical success criteria.
I approached the data conversion in three steps. First step is deciding the data conversion strategy. Here we identify data for cut-over and also decide how to handle historical data requirements. We also look at data volume, expected time taken, the sequencing of data load etc. In this case, since we were going live around festival season, it was important that the data of finished products is converted first since they should be available for sales fulfilment at the depots. Another key decision in this step is about the handling of Goods In Transit an partial receipts. A set of decisions are taken in this step.
Next step is the preparation of Cut-over plan. We identified each data element to be converted and identified tools, approach and the conversion sequence. Inventory was the most challenging. We had more than 200000 items and 120 inventory organizations leading to huge number of data to be converted.
Subbu took complete ownership the third step, which is the actual data conversion. He will start the process every morning at 4.00 AM and complete that days tranche by 7.30 AM when depots open. That way depots never ran out of materials.
I ensure that Subbu send confirmation y daily mail that the day's data has been converted and verified for accuracy.
The rigour that I insisted upon ensured that 100% of all data was converted, verified and accepted by the customer.
By September of 2005, the project had gone live and the our team was being gradually dismantled. One of the first to leave was our PM. This was followed by various consultants. I, along with a couple of consultants stayed in the project till it stabilized.
Stabilizing was not easy. We had to work round the clock to identify, document and resolve the bugs and performance issues.
Ultimately the project stabilized. The customer told our Organization that had I been the Project Manager, the project would have finished much better and much earlier. I can't vouch for this statement.
No comments:
Post a Comment