The model implemented by Pete Solvik at Cisco in 2004 had a significant impact. Solvik was hailed as a visionary and many managers admired his unique ideas on using IT to bring about changes within the company. During this period, Cisco experienced rapid growth, and John Chambers believed that as long as the company continued to grow, the business units could freely allocate funds for IT initiatives.
Solvik’s primary goal was to have an enterprise IT solution in place to manage inventory and manufacturing processes. To achieve this, he opted for a single-vendor solution from Oracle. This choice allowed for smoother global implementation. However, difficulties arose when the system needed to be upgraded and streamlined after Boston joined the company.
Before Solvik’s tenure, the IT department was viewed solely as an internal cost center. Solvik changed this perception by relocating Cisco’s IT organization from the finance department to the customer advocacy group.
This resulted in a shift in thinking regarding IT spending, as it was no longer considered an expense that was separate from each business unit. Instead, each business unit manager now had the responsibility of making their own investment decisions, leading to the implementation of a client-funded project system. However, Oracle’s available functionality did not meet the specific requirements of every business segment. While ERP systems are designed to streamline processes, ensure data integrity, and improve resource management, managers still needed to customize it to suit their individual needs (Bendoly, p. 79). Nonetheless, managers were optimistic because they had the freedom to purchase and install any software that they desired on the Oracle platform.
According to McAfee (p. 104), inconsistencies emerged between various business units and even within different regions of a specific segment. An instance of this is seen in the sales team in Europe and the sales team in the US, which both developed separate tools for the same process but relied on different data sources. Consequently, the need for multiple teams across different locations to monitor order status led to the development of redundant tools (Case study, p. 4).
The reason for Solviks’ model’s failure was primarily because the ERP system grew to the point where it couldn’t retrieve information from just one database. Additionally, the client-funded-project system still relied on a central IT unit, and with numerous ongoing projects, they didn’t have the resources to keep up. As the business rapidly expanded, they had to hire more personnel to ensure the infrastructure could scale accordingly. (Case study, p. 4) Due to managers instructing IT to fulfill their specific demands, Boston struggled to eliminate customized solutions.
According to the text, it was understood that in order to upgrade the ERP, it was necessary to cease causing further disruption in the system. Unfortunately, due to Solvik’s model, business managers had become accustomed to acting as they pleased. Even when corporate IT declined their requests, they persisted in financially supporting IT projects for additional solutions. These unauthorized “shadow IT” projects posed a significant issue because they employed contractors, and Cisco lacked any means of managing them. As stated in Mabert’s article (p. 75), a successful enterprise solution must establish explicit guidelines for utilizing external IT consultants.
In summary, Solvik did not consider that companies, especially fragmented ones like Cisco, require other systems for specific functions. His model failed due to a lack of oversight and failure to properly plan the Oracle implementation. Cisco is aiming to achieve certain capabilities with its IT efforts described on page 5 of the case (Boston’s actions). Specifically, Boston needed to gain control over Cisco’s IT expenditure and transition towards a globally consistent infrastructure, moving away from local independence.
If Cisco follows Solvik’s strategy, the task of resolving IT issues would become more challenging and expensive. According to Boston, “standardization needs to be considered in terms of the advantages it brings” (Glaser, p. 33). There were multiple ongoing projects that did not provide any benefits to the business and had to be halted. Boston’s main focuses were to enhance the Oracle ERP system, create a centralized customer database, and implement an enterprise reporting and business intelligence solution (Case study, p. 5).
The upgrade would have a significant impact on all the additional systems that were added on, requiring careful and strategic execution. One of the challenges encountered was the existing culture, where managers had the freedom to implement their preferred technology without considering standardization across functions. To address this issue, Boston decided to no longer allow business units to have sole control over their own destinies, instead encouraging them to contribute resources towards the overall organization’s goals. This change required everyone, including the corporate IT function, to be accountable. To facilitate this accountability, Boston divided the allocation into three categories: infrastructure, application development, and direct charge items. The infrastructure would be managed by corporate IT, while the business units retained control over application development and direct-charge funds. This approach aimed to ensure that all individuals and departments contributed to companywide initiatives.
Cisco needed to find a compromise between Boston’s implementation and Solviks’ model. Each initiative had an owner in the business unit responsible for ensuring proper execution and meeting their specific needs, including manual data clean-up. Aungle emphasized the importance of data and the need for correct policies to facilitate innovation. Boston aimed to resolve data issues by establishing a “single source of truth” for their customer database. However, the “e-customer” initiative faced challenges, such as the need to navigate multiple layers to obtain end-user information. Cisco had to collaborate with partners to acquire the necessary data. Inconsistencies in data naming conventions, especially with company names like “IBM” and “I. B. M”, posed another problem that required consistent recognition across the board.
The issue of dealing with similarly named subsidiaries of a larger parent would pose a challenge. The implementation of the customer database was a significant undertaking, leading to the development of an enterprise reporting and business intelligence (BI) solution. This solution aimed to streamline and consolidate the data in one accessible location for all users. While multiple BI tools were already in place, they lacked integration. With the introduction of a unified solution, both the European sales team and the US finance team were able to access and analyze the same booking and shipment information effortlessly. (Case study, p. 6)
Following the implementation of three major initiatives, Boston successfully restructured its IT into business process groups. As a result, each area of IT now has its own dedicated specialist, allowing for a collaborative partnership to foster growth in specific areas of the business (Case study, p. 8). The formation of the BPOC aimed to involve key figures from various groups in making policy decisions and influencing others to bring about cultural change. However, it is important to maintain a balance between old and new practices as Cisco remains a highly decentralized organization. Therefore, each new initiative must be approached carefully.
According to Mabert (p. 75), successful ERP implementations require teams to invest more time upfront defining the correct approach. Cisco is still struggling to prevent the new process organization from causing frustration among individuals who cannot initiate their projects. Nonetheless, Boston aims to establish a sustainable model for the future, which necessitates proper management of policies, processes, and data before IT projects can progress.
