Reference no: EM131051740 , Length: 1500 Words

BONUS REAL-WORLD CASE

Overstock. com

Overstock.com executives had to reinstate earnings for a five-and-a-half-year period, dating back to 2003. Overstock incurred accounting mistakes during that period, which led to a $12.9 million reduction in revenue and a $10.3 million increase in cumulative net loss. CEO Patrick Byrne explained the $14.2 million third-quarter loss to investors this way: "My bad." This was all due to an overly aggressive CEO and a problematic Oracle ERP rollout that started back in 2005. Overstock had previously used a homegrown system and rushed the Oracle implementation project in order to get the new system live before the fourth quarter of 2005 and the busy shopping season. "Honestly, it didn't have anything to do with Oracle per se, it was the implementation," Overstock stated. "We had consultants and we had help, but it was all driven by Overstock. We set the timelines?' The problems with the rushed implementation manifested itself in strange ways. "Some things were going through okay and a lot weren't," CEO Patrick Byrne said. "It was just spraying orders. Sometimes customers might not get a ship confirm. Sometimes the order might not flow through the system. Sometimes the order got misrouted." After the restatement and delivery of the third-quarter financials, The Motley Fool financial Web site named it as one of five stocks in a tailspin.

As part of their accounting module upgrade they changed from recording refunds to customers in batches to recording them transaction by transaction. After the implementation, in the instance of some customer refunds, this reduction wasn't happening, and Overstock didn't "catch it." Overstock uses internal "reason codes" that show why various customers get refunds. Under the new system, not all reason codes were automatically recorded; some customer refunds required manual entry in the financial system. Unfortunately, Overstock missed some of the manual customer refunds and, as a result, did not record all that were occurring. Over time, this error built up and, on a cumulative basis, eventually became material. In addition, the company learned that the system failed to "reverse out" shipping revenue for cancelled orders, "and these $2.95 charges also added up over time. Overstock had been underbilling its fulfillment partners for certain costs related to product returns over the past two years, they weren't recording some customer refunds and we weren't recouping some costs from partners on some returns. The combined result was that the returns costs looked reasonable. One observer said problems like those cited by Overstock.com can happen on any ERP project without the proper care and planning." The ERP system will do what you design it to do, which is why we often say it's very important to spend time on design and mapping. As you can see by these cases, not properly preparing and setting realistic time lines can lead to a disastrous implementation. It only takes one module to be corrupt to affect the entire organization. "Our 1st Commandment is 'maintain a bullet-proof balance sheet,' but while the spirit is strong, the flesh made a mistake," Overstock.com CEO Patrick Byrne said in an October 24 letter to shareholders. "The short version is: when we upgraded our system, we didn't hook up some of the accounting wiring; however, we thought we had manual fixes in place. We've since found that these manual fixes missed a few of the unhooked wires?'

QUESTIONS

1. Would a rapid SDLC approach have been a better implementation choice for Overstock? Explain.

2. Which SDLC phase(s) should not have been rushed? What phase(s) could have corrected Overstock's errors?

3. Even though this project was driven by upper management and had experienced Oracle consultants, it still failed. Where would you put the blame?

4. It seemed they used a big bang approach. Would a phased approach have been the better choice? Why?