IBM Versus Bridgestone: When Two Giants Collide

It usually never comes down to this. When one of the world’s biggest technology and consulting firms, such as IBM, figures in a dispute over a failed order-to-cash implementation with a major client like tire maker Bridgestone, the harsh words and recriminations are typically kept behind closed doors. A settlement is quietly negotiated.
 
So it was a surprise when Bridgestone Americas Inc. filed a suit against IBM in the US on 29 October (with a redacted version made public in November) alleging fraud, breach of contractual undertaking, deceptive conduct, bad faith and gross negligence – and demanded a “yet to be fully determined” amount for actual and punitive damages as well as attorneys’ fees and other costs.
 
IBM issued a statement to the website Business Insider, which was nearly as toughly worded as Bridgestone’s suit. “These claims against IBM are exaggerated, factually wrong and without merit,” said the company. “From the outset of this project, Bridgestone failed to meet critical commitments upon which the performance of IBM’s obligations was predicated.”
 
This article is not meant to come down on one side or the other – the US District Court in Nashville, Tennessee, will make the determination of who is in the right on the facts of the case. Our interest in this saga is not so much in what the legal outcome may be, as it is in what it discloses about how a financial technology implementation journey can go wrong, and the lessons that companies in Asia can learn as they embark on a similar journey themselves.
 
Creaky system
The story began on a positive note. Before the current fracas, Bridgestone and IBM had a long and apparently fruitful relationship. From 2000 to 2007, IBM was involved in two projects at the tire maker: 1) implementing ERP software for certain manufacturing and finance applications, and 2) upgrading, implementing and/or supporting new Internet-based product ordering systems.
 
Bridgestone also hired IBM, along with Booz Allen Hamilton, Fujitsu and other IT consultants, to work on a feasibility study to integrate the diverse order-to-cash processes of Bridgestone’s Commercial Tire Division. This involved knitting together SAP ERP software and other third-party “best-of-breed” applications, including those for electronic ordering, sales order processing, warehouse management, inventory control, accounting, finance and reporting.
 
These business process modules were largely integrated through a creaky computer mainframe system known as COPS (Customer Order Processing System), which was written in COBOL, a computer language developed in the 1960s. To stay ahead of the competition, Bridgestone decided to replace COPS with SAP’s ERP platform. IBM and the other IT consultants were brought in to investigate how the diverse business process modules could be seamlessly integrated with the new ERP system, using middleware from SAP or another service provider.
 
When the consultants turned in their report, Bridgestone proceeded to bid out the finalization and implementation of the new order-to-cash system. After submitting a 150-page proposal that stressed its existing relationship with Bridgestone and expertise in SAP implementations, IBM beat four other bidders to win the contract. IBM completed work on a final plan in the Fall of 2008, and also recommended that its own middleware, IBM WebSphere, be used in the integration of the SAP ERP and the non-SAP business modules.
 
It’s complicated
Then came a complication. Bridgestone decided to widen the scope of the order-to-cash project across the enterprise. The scope and volume of work that the proposed order-to-cash integrated system needed to handle increased exponentially – enterprise-wide, Bridgestone customers “submit an average of approximately one product order per second, eight hours per day, five days a week for delivery to over 62,000 locations.”  
 
The Commercial Tire project was winded down and a new request for quotation was sent out in 2009 for an expert to work on Bridgestone’s All Division Solution Design and Roadmap project. IBM once again won the bid. It was obligated, according to Bridgestone, to “deliver a Case for Action, Enterprise Design, Solution Architecture, and Deployment Activities and SAP [Order-to-Cash] Roadmap.”
 
IBM submitted a plan dated 1 June 2009 that, among other things, defined the steps to be taken for design completion and validation and, in the words of Bridgestone’s suit, “anticipated the finalization of the solution architecture and enterprise design, and the beginning of project deployment rollout in the fourth quarter of 2009.”
 
In late 2009, IBM said that it had substantially completed all solution design work and anticipated that the design solution phase should be finally completed in mid-2010. In December that year, Bridgestone signed the “IBM Statement of Work for SAP Order to Cash (OTC) All Division Rollout Project,” allowing work on the project solution design to continue and also contracted IBM to serve as implementation expert to put the design solution into place.
 
That contract anticipated that the system will go live “as late as June 2011,” according to the Bridgestone suit, “with two months stabilization thereafter.” The total estimated IBM service fee was approximately US$41 million – IBM would bill Bridgestone hourly fees plus expenses.
 
The work included, but was not limited to, “the configuration, coding, and interface development for IBM’s WebSphere middleware software, the configuration and coding of the SAP ERP software platform and interfaces, the project management for all of these tasks, and the writing and oversight of all testing.”
 
The final project solution design was completed in Fall 2010, not mid-2010 as originally anticipated. The two parties then agreed on a new go-live date of 1 October 2011, from the original June 2011 date. “At that time,” said Bridgestone’s suit, “IBM represented . . . that its SAP OTC All Division design solution was final and would provide the promised implementation of a single instance of SAP OTP functionality.”  
 
People problems
Under the 2009 contract, Bridgestone had primary responsibility for some tasks relating to its legacy systems. However, said the suit, Bridgestone in January 2010 “began the process of entering into a number of separate agreements with IBM . . . whereby [Bridgestone’s] responsibility for [legacy] systems work on the SAP OTC project was outsourced to IBM.”
 
These agreements were to fall under a separate Master Services Agreement (MSA) signed in 2008, under which IBM “began the process of taking over a part of [Bridgestone’s] Application Management Systems Services . . . which had historically been performed by [Bridgestone’s] IT employees.”
 
It’s unclear from the suit whether those separate agreements were indeed entered into, or if they were, whether those agreements actually transferred responsibility for the legacy systems to IBM. The statement IBM sent to Business Insider suggests otherwise. “Bridgestone failed to staff the project with people who sufficiently understood its own legacy systems and could assist IBM in designing and converting them into a new SAP system,” it said.
 
IBM also noted that in a two-year period during the project term, Bridgestone replaced its CIO on six occasions. “Throughout, Bridgestone lacked the necessary leadership to effectively manage the project,” said IBM. It also charged that Bridgestone “failed to supply the necessary software, hardware and network infrastructure for the system to operate properly. In many instances, Bridgestone supplied inferior resources or no resources at all.”
 
But it seems that IBM had people problems too. In late 2010, said the Bridgestone suit, “key IBM subject matter expert leaders important to project completion began leaving without explanation.” The exodus continued into 2011, said Bridgestone, “and many key IBM personnel in leadership positions were either never replaced with comparable personnel, or were replaced multiple times without meaningful project knowledge transfer.”
 
Finger-pointing blues
Worried that the October 2011 go-live deadline would not be met, Bridgestone escalated the issue “within IBM’s management structure as anticipated in the contract.” IBM performed an assessment, according to the Bridgestone complaint, but acknowledged only minimal responsibility for work delays – “and represented that its analysis established that [Bridgestone] was primarily responsible for project delays.”
 
Meanwhile, in May 2011, five months before the scheduled go-live, the two parties finally completed negotiations on the material terms of Project Change Request No. 8, which documented the project changes agreed by the two parties in late 2010 and the additional fees Bridgestone must pay. Later that month, testing began of the IBM middleware integration interfaces for both legacy systems and SAP.
 
IBM delivered an assessment report dated 7 June 2011 that acknowledged the need for review, but also accepted only limited responsibility for the project delays and integration interface test failures, which it said were primarily caused by Bridgestone. Later that month, new IBM middleware experts were deployed to Bridgestone.
 
In mid-August, IBM acknowledged “that it could not correct the issues in IBM interfaces for the October 1, 2011, go-live,” Bridgestone said in the suit. IBM said it might be ready for a November 1, 2011, go-live, but proposed that the new date be set for December 1, 2011. “Bridgestone advised IBM leadership that there were critical business reasons that required the SAP system go live no later than January 1, 2012,” the suit continued.
 
But the tests did not go well. After the last alternative IBM topology failed in early December 2011, IBM proposed that Bridgestone buy additional hardware capacity from it. Bridgestone “promptly agreed in order to meet the January 2012 go-live date,” said the suit. The two parties also “explored the potential risks of the planned cutover to the IBM solution design beginning December 24, 2011, and going-live with most of the system on January 3, 2012.”
 
Bridgestone claims it “aggressively worked on its risk mitigation plan for the known risks throughout December 2011 and understood that IBM had lowered the level of the potential risks based on IBM’s work and the risk mitigation work.”
 
The cut-over was done on 24 December as scheduled. But on 27 December, as Bridgestone tells it, IBM “appeared to have re-evaluated the risk related to the status of IBM’s work.” By then, however, “the cut-over process from the COBOL systems to the IBM SAP OTC solution and other applications was well underway. It was therefore too late to roll back the go-live, which had already proceeded to far at that point.”
 
‘Crippling defects’
IBM contests Bridgestone’s version of those events. “Bridgestone ignored the clear and repeated recommendations from both IBM and members of its own IT staff to implement a staggered roll-out of the new system to mitigate risks to its business operations,” the IBM statement said.
 
“Instead, Bridgestone’s management insisted on a ‘big bang’ go-live in which all aspects of the SAP system were required to be implemented simultaneously, across all of its North American tire operations.”
 
For a period of at least six months, IBM had advised that the go-live date was premature and fraught with business risk, said the statement. Yet Bridgestone continued to demand that the system be implemented in a big bang manner and on the scheduled go-live date. “As the go-live date drew near, IBM urged Bridgestone’s management, in writing, to reconsider its decision,” said IBM. But the company “elected to proceed regardless of the identified risks.”
 
Everyone’s worst fears were realized. Bridgestone said the new system “experienced crippling defects that had a devastating impact” on its business. Some 17,810 “trouble tickets” were generated related to orders that customers said they placed but which Bridgestone did not receive, orders not processed or not processed correctly, the Distribution Center not receiving instructions concerning order and transportation documentation.
 
Bridgestone estimates lost profits during the first six months of 2012 amounted to no less than US$75 million. It said it had to spend US$38 million in additional expenses, after paying IBM US$74 million on the implementation project.
 
For its part, IBM acknowledged in its statement that “the system did experience some of the errors that IBM had predicted.” But it said it provided extra personnel and resources to quickly address those errors. Operations then returned to normal, it insisted. Since the implementation, said the statement, “Bridgestone has achieved recording-setting financial results.”
 
Lessons learned
It will be up to the courts to decide which of these starkly different versions of events to accept as true. For now, there are lessons to draw from this collision of giants:
 
Don’t bite off more than you can chew. Had Bridgestone gone ahead with the Commercial Tire project instead of opting for the much larger All Divisions project, a failure would have had limited impact. Technical, management and people lessons would then have been learned by both parties that could be applied enterprise-wide.
 
Don’t seek to outsource all core IT expertise. Reading the lawsuit, one gets the impression that Bridgestone seemed all too ready to turn over to IBM almost all of its information-technology functions. Outsourcing responsibility for legacy systems to the service provider that is replacing them seems foolhardy. No one knows better how legacy systems work than the company itself.
 
Don’t abrogate IT leadership. Changing CIOs on six occasions over a two-year period will almost certainly delay decisions on contracts and project changes. Indeed, according to IBM, “after insisting that it have control over the design and final approval of the system, Bridgestone failed to timely approve those designs, failed to provide the necessary design documents for IBM to complete its work, and failed to conduct the required user testing necessary to understand how the system would work under real world conditions.”
 
Don’t lock yourself into a deadline. While slow progress and failed tests can be maddening, be wary of inflexibility when it comes to IT implementations. It is not a good idea to fixate on a date and worse, make commitments to customers, suppliers and other partners based on that date. While your service provider may believe in good faith that such and such a deadline is feasible, there are many factors that can go wrong, even if there is an aggressive effort to mitigate the risks. Haste makes waste.
 
About the Author
Cesar Bacani is Editor-in-Chief of CFO Innovation.
 

Photo credit: Shutterstock 

 

Suggested Articles

Some of you might have already been aware of the news that Questex—with the aim to focus on event business—will shut down permanently all media brands in Asia…

Some advice for transitioning into an advisory role

Global risks are intensifying but the collective will to tackle them appears to be lacking. Check out this report for areas of concern