I would like to share with you the idea behind and the processes involved with an award-winning continuous improvement project I led during my time with Shell Oil.
Background. The origins of continuous improvement techniques can be traced to management scientists such as Juran and Deming, but the cradle of continuous improvement as a management philosophy is undoubtedly Japan, where the ideas of these smart “gaijin” were embraced most. The processes and ideas pioneered by the Japanese industrial giants, such as Toyota, have created not only a literature of continuous improvement, but also a field, an industry of its own where consultants have long sought to improve the efficiency with which their clients operate and certified professional provide training for their clients in effort to instill the continuous improvement mindset among employees so that they can find homegrown solutions for their problems.
I am not going to talk about the long history of continuous improvement and how it changed the way firms operate, globally. A popular book, The Toyota Way, provides a good primer on the subject. But it is worth noting that continuous improvement techniques have gradually lost their potential to support competitive advantage due to their ubiquity, where management consultants, acting as cross-pollinators of best practices among competitors, have been flattening the efficiency landscape since the 80’s using lean and Kaizen methods. Instead, I will tell my most inspirational story of “kaizen” (a Japanese word for continuous improvement, coined by a Japanese management consultant named Imai; ironically, he also had began his career in the U.S.)
it is worth noting that continuous improvement techniques have gradually lost their potential to support competitive advantage due to their ubiquity, where management consultants, acting as cross-pollinators of best practices among competitors, have been flattening the efficiency landscape since the 80’s using lean and Kaizen methods
Back when I worked for Shell Oil (circa 2010), it had a strong emphasis on continuous improvement by improving operational efficiency which entails: a) encouraging/rewarding initiatives taken by employees; b) enabling the employees to make an impact based on these initiatives by providing training and flexibility (mainly in terms of work hours).
Making processes more efficient involves eliminating waste (“muda” in Japanese). Accordingly, Shell followed and trained its employees on Lean Six Sigma methodology (I guess they still do). While kaizen is more of a mindset/culture, Lean Six Sigma is a methodology that aims to eliminate waste at the workplace based on a) lean manufacturing principles (pioneered by firms such as Toyota); b) Six Sigma (a methodology for improving quality by eliminating defects; pioneered by Motorola in the 80’s). Mathematically, Six sigma stands for performing defect free 99.99966% of the time (3.4 defects in a million).
There are multiple methodologies followed in the pursuit continuous improvement or eliminating waste, DMAIC (define, measure, analyze, improve and control) is probably the most popular and the one that was utilized by my employer. After attending a series of training sessions, I was asked to define a problem within the processes I am involved in and formally begin a project to be led by me under a supervision of a Lean Six Sigma Master Black Belt project leader.
The problem. As a credit analyst, I managed a portfolio with over 10,000 client accounts which made up for a total monthly credit line over $250 million and $1 billion in annual sales. Each customer had a monthly credit limited assigned based on: a) financial health/credibility, assessed by me based on the financial statements provided when the customers first request a credit line; b) liens (e.g., cash deposits, debt securities, bank letter of guarantee, real estate). Customers often exhausted their credit limits before the end of each month due to the price surges in retail oil prices (oil was still the black gold then) and unpredictability of customers’ consumption. As a result, customers who are in great financial health, willing provide debt securities and consume more were denied further purchase. Increasing a credit limit wasn’t an instant process since it involved a three-way interaction (customer, sales representative, and me, the credit analyst) and an additional analysis on my side. This had four important consequences, combined, constituting the problem for my project:
- Shell had to give up additional sales on hundreds of existing customers every month (decreased revenue).
- Customers were unhappy when they were denied sales at the pump. Most of these customers were corporate accounts so sometimes the drivers of the vehicles didn’t even have enough cash to purchase the gas for the corporate vehicles they drove (decreased customer satisfaction). I once had to deal with a driver carrying a truck-load of ice cream, ran out of gas and stuck at a remote gas station.
- Salespeople were unhappy that customer satisfaction was affected as a result of unexpected credit limit exhaustions (decreased internal stakeholder satisfaction).
- Usually during the last week of each month, a large team of salespeople called me over the phone, one by one, often repeatedly, and requested action on my side for their customers (time wasted).
In short, the problem was one of communication: customers didn’t know how much they were allowed to spend (a hard task considering the price fluctuations), salespeople didn’t know how much the customers were spending during the month (they received report only by the end of each month which was used to evaluate their performance), and although I, the credit analyst, had all this information, didn’t communicate with customers.
Measure and Analyze. As you can see, the consequences of this problem existed in three levels, affecting the firm as a whole, the sales team, and me. I didn’t have the possibility to measure customer satisfaction and the level of frustration of the salespeople, but I managed to measure how much time I spent on handling these ad-hoc requests and how much money my employer potentially lost on these credit limit hiccups:
- I conservatively (a pessimistic scenario) estimated the foregone sales based on historical figures using a simple logic. For all customers who were denied purchase due to credit limit exhaustion but later given a higher credit limit in the prior calendar year: the number of days the customer wasn’t able to make purchase multiplied by their average daily consumption during the month prior to credit limit exhaustion. This added up to $250,000 annually only for my own portfolio.
- The telephone calls I received from salespeople would add up to more than a full work day each month on my side. If I spent 8-10 hours a month over the phone on such calls, then the sales team as a whole spent another 8-10 hours a month talking to me.
Improve. This is where thinking out-of-the-box and basic programming skills made the project feasible. I needed to forecast when the customers are likely to exhaust their credit limit and give an early warning to the sales team (preferably not on phone). At the time, the members of the sales team mostly worked in the field and used their mobile phones to get in touch with me. So using spreadsheets or the instant messaging service installed on office computers were not feasible options for communication. Furthermore, with today’s standards, the corporate phones they were provided with weren’t so smart; everyone was given a Blackberry Classic (this is before the reign of Iphone in the corporateland); without a touchscreen, navigating through documents and applications on this phone was a tedious task, hence the salespeople preferred to give me a call, rather than writing an email containing critical information such as the customer name/account number.
All of these gave me the idea of building a database which can easily accessed by the sales team. So I built lightweight database with a single search bar on a simple html file which can easily be opened and navigated on Blackberry handsets and that which can also work offline (in case salespeople were travelling, which they usually did). Admittedly, I might have been inspired a little bit by another popular book published a few years earlier: The Google Story, which is a testimony to do the power of a simple tool which allows the user make text-based search. Combining a simple sales estimation algorithm and a little Java-Script, “TTSDatabank” appeared (TTS was the name of the vehicle identification system installed in customer vehicles, acting as a credit card when they drove to gas stations; show above). This was a small html file which contained information on thousands of customers, forecasting their end of the month consumption and whether their credit limit would be sufficient based on this consumption. Members of the sales team could search for either the name of their customers to see how a particular customer is doing in terms of the consumption/credit limit ratio or their own names to see the information for all of the customers in their portfolio. Essentially, this was an html kanban board (a simple tool utilizing colorful cards and used in a variety of processes from inventory management to manufacturing by Toyota) that helped me communicate with the sales team. An updated version of this file was sent twice a month to salespeople who downloaded this file to their phones and carried anywhere with them.
Control. following the deployment of the project, I measured the two problem parameters once again: a) time I spent on the phone with the sales team on the credit exhaustions of fleet customers; b) the number of fleet customers exhausting their credit limits before the of month. I captured significant improvements for both in line with the predictions generated in the “Measure” stage.
The project took 4-5 months from beginning to the end. However, it should be noted that I began the project with a solid idea on what problem I wanted to solve. I have been working on my day-to-day tasks as usual during this period. “TTSDatabank” was an instant success. It saved me countless hours and I received positive feedback from the sales team, including tongue-in-cheek recommendations for me to get a job in the Silicon Valley (in those years, coding was still seen as a complicated activity reserved for IT specialists). For Shell Oil, a quarter of a million dollars was a drop in an ocean, but I delivered the project successfully; my mentor in India named Balajee, with whom I collaborated remotely, a Lean Six Sigma Master Black Belt Project Leader (and a fellow avid Dire Straits fan), approved my project and I was awarded my Lean Six Sigma Green Belt. To my surprise, I was given a “Special Recognition Award” by Shell Oil and was asked to present my project to an audience of over 1000 people at our biannual meeting. Finally, I prepared a training manual explaining how the file is prepared and a short training video for the salespeople demonstrating how they can use it.
The highlight of this project was that it was triggered by a relatively minor problem on my side (time wasted by hundreds of phone calls), but the root cause of this problem, the lack of a procedure for estimating and communicating potential credit limit exhaustions, had much larger consequences. So although my solution was simple, it was stakeholder- and customer-focused, aiming to solve problems of customers and the sales team rather than my own, allowing to have an impact far beyond my day-to-day work. Further, my manager was ready to champion and market it to other countries where my employer used similar processes and technology.
In the hindsight, however, I might have missed having phone conversations with the overly chatty salespeople (!), so shortly after delivering the project, I decided to quit my job and pursue grad studies in Management.