Reengineering Before Internet Days
When we started working to implement Business Process Reengineering in our client organisations, we had to manage with available technology; the internet was a far cry away from being a norm as it is today. Also, many of the tech solutions like smart phones were unheard of and mobile phones were just getting launched and were very expensive to use. The nearest device to affordable wireless communication technology was the Pager, which allowed short messages to be sent between two parties. The only technologies of interconnected desktop computers available were WAN and LAN, but they required wired networks to be established everywhere, which had practical feasibility issues where two locations were far apart.
The Department of Telecommunications (DOT) was the only agency capable of providing VPN service, and this was prohibitively expensive for many organisations to consider for networking across various distant locations. MRP softwares was available but could be affordable only for very large organisations; ERP was just being introduced and there was a wide choice of ERP suites available from various vendors. Many of these vendors were promoting their products with a selling proposition that if an organisation installed their software, the processes would be reengineered without need to go for a formal BPR exercise. And, as was bound to happen, many of these packages ended up becoming expensive solutions since, in the absence of a prior BPR exercise, many organisations ended up tweaking these softwares to align with their current manual processes and hence a seamless software process got broken in implementation.
When we started working in such organisations where they had already implemented MRP or ERP before we entered, we had to prepare the organisation to reverse many of the customisations which they had already paid for!!!
Apart from that, many organisations had invested in computerisation which involved simply dumping all the current manual way of working into a computerised way of working; hence they had usually a paper trail coexisting with the computer data trail. And, in the absence of networking and process focus, the same data were getting entered in different locations using the paper trail. Despite such limitations as seen from today’s perspective, we could come up with some original solutions in many of our early assignments prior to the advent of the internet. I share here the examples of interesting ideas which got implemented in those days.
In the first assignment at Hyderabad Batteries, when the team analysed data of past quotations, they found that 80% of the tenders were coming from 4 or 5 major customers who had standardised their system requirements around certain specifications. The team therefore came up with an idea that, for such tenders, there was no need to design the solution from scratch, and a checklist of standard specifications could be incorporated in the software they had developed for making the quotation. One of the team members, Mr. Narayana, was from the accounts department and he had no idea of the technical aspects of the product the company was offering. One of the team members suggested that we had to make the process for making an offer “Narayana Proof”, which implied that the accountant should be able to prepare a quotation based on the checklist!! This also enabled standardising the Bill Of Materials (BOM) for procurement and manufacture without wasting time, once the order was confirmed for these 80% cases. The technical persons needed to play a role only in the remaining 20% cases where the customer requirements deviated from the standard list.
In the next assignment at the Apollo Diagnostic Centre, apart from the issue of standardised report delivery using the 80-20 rule, we had a major logistics problem to address. Since ground floor space was in demand for consultants to see their patients, the sample collection room was on the ground floor and the testing lab was located on the second floor exactly above the sample collection room. Since the samples had to be taken 2 floors up, the house keeping person would wait for several samples to be accumulated before carrying them two floors up the stairs. This caused a major part of the delay to begin with. When the report was finally prepared in the lab on the second floor, the same house keeping person had to bring it back down to be delivered at the reception on the ground floor. So he would similarly wait for all the reports for the day to be ready before bringing them down all together, which caused another major delay.
The team observed that both the sample collection room and the lab had windows located below one another on the two floors, and wondered if this could in some way be used to speed up sample delivery to the lab. So Raghav and an enterprising friend of his installed an eight-inch plastic tube between the windows and designed an electric lift to carry the samples from the ground floor to the second floor within this chute as soon as the sample was taken. This minimised the long delay between sample collection and lab analysis. The rest of the process could be completed seamlessly in the targeted 30 minutes using computers. This was another out-of-the-box solution that the BPR team could come up with while working on BPR.
In the case of Glaxo, compulsions of a proposed VRS forced the team to look at the option of using third party contractors for some of the activities done by their own employees, and also empowering the field managers to take administrative decisions on a day-to-day basis while using the computerised process for these actions to do random statistical audits to check misuse. In the absence of networking between far away locations, the data was moved from these locations to the head office by courier every day, or every few days, by floppy disk or other media available to the central computer centre for processing and updating.
In the case of the Nagarjuna Steels assignment, we were faced with a major challenge regarding daily cash purchases for urgent or low-value items. The factory was located at Patancheru, 30 km away from the nearest market at Secunderabad. The present system was that, every day, one of the purchase executives would come all the way to the factory to report for duty and, with the list of cash purchases given to him, would come all the 30 km back to the city to buy and go back 30 km again after all purchases were made. Sometimes, some of the items would not be available during his visit and he had to make another trip the next day for the same item. This involved a lot of waste of time in commuting. And when we computed the cost of buying the cash purchase items, in many cases it was several times more than the actual value of the item.
During the team discussions, the member from purchase pointed out that there was a vendor for small engineering and store items who visited the factory every day, took orders for these items and delivered them the next day and collected his payment once a month. So why not offer this vendor the increased business of making all the cash purchases? This would free the purchase executive to more useful work at the factory. So, once the purchase team member discussed this proposal with the vendor, the new process was recommended to the management which cleared it forthwith. In the process, we introduced a category of vendor called “buyer” in the reengineered process!
When we were working with Bakelite Hylam on the second assignment involving field sales operations at Delhi as the pilot project, we had the most interesting ideas coming from the team. Delhi had a sales office located in Defence Colony area in the middle of the city. It was headed by a Branch Manager and he had a team of field sales personnel for different business divisions. They had close to 20 field people along with a few office staff to provide administrative and clerical support and a receptionist-cum-telephone operator.
All the employees had to report to the office at 9.30 am every day, and, based on their sales call routine or responding to urgent calls from customers, they would move into the market and had to come back by evening to submit the call reports before going home. Sometimes they would be delayed in reaching the office in the evening, in which case they would inform the office and submit the call report the next morning. The interesting finding was that the receptionist-cum-telephone operator was fielding many of the customer calls on her own, with all the correct information needed, in the absence of the concerned field salespersons, and she would inform them when they came back to office about the call for any follow up. The team realised that the current way of working involved a lot of waste of time in commuting between home, office and field work. The call rates were hence low. Moreover, as the number of staff increased, the office space was getting cramped and they had proposed to move to a larger place, which was awaiting approval.
During the discussion, the team observed that many a time the same geography was getting covered by different sales persons representing the various divisions, and in some cases the same customer was met by more than one salesperson representing different divisions. Many felt that this waste of time and resources should be eliminated in the reengineered process. Someone asked why the sales people should report to the office every day; why couldn’t they go to the field directly from home and inform the office by phone for any urgent follow up from the back end based on their customer needs? This way they could meet more customers per day. Another member suggested that when the office needed to contact the field person, they could send a message by pager to him and he could call back the office from the nearest public phone. In this process, the role of the telephone operator-cum-receptionist became very important and she became part of the sales team. In fact, the team came up with a reengineered process where each field person would cover all customers in his geography and all divisions closest to his home, and all of them would only come to the office every Saturday for a meeting with the sales manager to review operations for the last week and plan for the next week. Suddenly, the need for additional office space vanished and, as the call rates improved, the sales performance also improved significantly in the next 3 months. The management immediately asked the marketing chief to implement the same pilot model across all other territories.
As we can see from the above cases, remarkable process reengineering can be done even without significant IT enablement, provided the focus is on the outcome. Later, when IT technology had evolved considerably, we carried these experiences with us when we moved on to other organisations, giving us greater leeway to come up with more innovative solutions.
