· Case Study 2

Cisco Systems, Inc.

Class case study — implementing ERP

Why Solvik and Redfield Opposed ERP Deployment

• Solvik believed the legacy system was still usable, even though it was messy — the case describes it as having "too much spaghetti, too customized" (p.2, par. 4)
• Because of this, he initially wanted stabilization only — the case says he "planned to let each functional area make its own decision" rather than force a big ERP (p.2, par. 5)
• Solvik feared massive ERP projects, since they too often turned into "mega-projects" (p.2, par. 5)
• Redfield agreed, noting that big IT proposals usually become "monolithic… take on lives of their own" (p.3, par. 6)
• Together, they believed a full replacement would cost too much and take too long, and that disrupting operations was unnecessary
• Solvik and Redfield both preferred a fast patch approach over a full replacement

The Process of Selecting Cisco's ERP

• After the outage, Cisco formed a single team because they "needed to take faster action" (p.3, par. 7)
• The team partnered with KPMG
• The case notes that KPMG provided "very experienced" people rather than "greenies" (p.4, par. 4–5)
• To speed up selection, the team consulted larger firms and analysts, narrowing the field to five packages within two days (p.4, par. 6–7)
• Cisco then required vendors to perform three-day demos using sample data to prove the system could handle key processes (p.4, par. 9)
• Oracle was chosen partly for its "better manufacturing capability" and promise of long-term improvements (p.5, par. 1)
• The final pitch to the board showed Cisco's old system was unreliable and would "not support our anticipated future growth" (p.6, par. 2)

Solvik changed his mind

after a major crash shut the company down — the core database was corrupted and Cisco was "largely shutdown for two days" (p.3, par. 3). The case shows the system was on the brink of collapse, and Solvik realized small patch fixes could no longer protect the company.

Four Issues Found During CRPs

1. Order Entry — Cisco found that Oracle's default Order Entry screens didn't match how Cisco actually processed orders. The OE form needed fields for "discounts," "pricing information," and "additional sales order data" (Exhibit 7, OE Form).
2. Manufacturing — Oracle could not support Cisco's manufacturing operations. It required the ability to "record contents," "assign serial numbers," and "backflush inventory" (Exhibit 7, Packout).
3. Financial Structures — Cisco's accounting setup did not fit Oracle's default model. The Flexfield needed "5 segments" with specific codes, rules, and multi-digit structures (Exhibit 7, Flexfield), and Cisco's reporting had to be redesigned within the ERP.
4. Configuring — Oracle had no built-in way to handle Cisco's router configuration. Cisco needed logic capable of entering "rules regarding orderability" for product combinations (Exhibit 7, Product Configurator).

Unsupported Software & "Red" Modifications

• Cisco used a model where all modifications were classified "Red, Yellow, or Green" (p.9, par. 1)
• Red items required Steering Committee approval and included changes to Packout, the OE Form, and the Product Configurator
• The case shows Cisco needed "30 developers… for three months" to complete the modifications (p.9, par. 3)
• Core code modifications were avoided where possible to keep the upgrades manageable (p.9, par. 3, 5)

Why didn't such a configurator exist in the "vanilla" Oracle ERP?

• Oracle's system was built for traditional manufacturing, not Cisco's complex hardware
• Cisco needed logic for "physical and technical constraints on ordering" (Exhibit 7, Product Configurator), which wasn't supported out of the box

Primary Cause of the Post-Launch Performance Drop

• After go-live, the system became unstable — it "went down nearly once a day" (p.10, par. 1)
• Hardware was undersized because Cisco had tested with a "partially loaded database" (p.10, par. 3)
• Processes had been tested individually, but in real use everything ran together and caused overload
• The failure caused on-time shipping to fall from 95% to about 75% (p.10, par. 1)
• To avoid this, Cisco should have run full-volume load tests with a complete database, more hardware capacity, and avoided going live during a peak period