ADP’s Customer Service Solution — Timing and
Drive a Microsoft SQL Server Decision
Understanding all costs associated with a systems implementation or a particular element of an implementation is sound business policy for any user organization. Although cost is not the sole determinant of value — potential revenue growth, competitive posture, strategic initiatives, etc., are all important considerations — it is a key metric in determining the value and return on investment (ROI) of any project. Despite the importance of understanding total cost of ownership (TCO), the difficulties in gathering the associated costs for an IT project are significantly daunting, preventing most organizations from attempting the effort.
Comprehensive, finely tuned TCO analyses, particularly those that compare competitive products, tend to be stylized assemblages of facts, extrapolations, and analysis that bear little resemblance to the real world. Prior Aberdeen research suggests that a “precisely calculated TCO … is unrealistic” (see Aberdeen’s Risk Management and Total Cost of Ownership Realities, March 1998). Even assuming honorable intent, the analyses often must alter data or exclude other decision factors to derive a meaningful comparative result. Yet the specifics of a particular customer’s situation are most unlikely to conform to the normalized results of such analysis.
As an alternative, Aberdeen research has found considerable merit in the “case study” approach to analysis, whereby the focus is on the specifics of a real customer implementation. By capturing the business context of a particular organization and its decisions, other organizations can compare their situations and assess any differences. By doing so, they can truly learn from the experiences of a sophisticated organization that has “been there, done that.”
Toward that end, Aberdeen recently participated in a project that Microsoft commissioned to understand how a major customer, ADP, made decisions about the database platform for its ACCESS project, a high-profile enterprisewide customer service initiative. Our goal was to validate claims that Microsoft SQL Server offered a superior TCO when compared with Oracle on the NT Server platform. As part of this project, Aberdeen met with key staff at both ADP’s corporate offices in Roseland, NJ, and the Boston regional office in Waltham, MA. To supplement the information gathered from the interviews, Aberdeen independently obtained additional information to clarify some of the interview data and to provide context.
ADP is a Fortune 500 corporation with annual revenues of $4.8 billion. A longstanding provider of computer services, ADP’s Employer Services division is the world’s largest provider of payroll services and human resource information systems, generating $2.7 billion in annual revenue. The ACCESS project, a major customer service initiative, commenced in 1996 and eventually will be deployed to 8,000 users in 40 regions, clearly making it “enterprisewide” in scale. The NT-based Clarify solution using Microsoft SQL Server has generated considerable publicity. As a major systems deployment built upon SQL Server, ACCESS provides an important reference point to Microsoft’s claims of the price-performance and scalability of its database solution.
The initial momentum behind implementing the new customer service solution came from a proposal for a custom project made to ADP senior management. That proposal, initiated outside the Client Services Division responsible for customer service, would have revamped existing customer service implementations and linked a variety of legacy applications into a more comprehensive solution. ADP was already on its second generation of internally developed customer service and support solutions.
These solutions — the first mainframe-based, the second an OS/2-based LAN — performed basic incident-related logging of service calls. The functionality of these solutions was roughly equivalent, with the OS/2 solution largely mimicking the mainframe’s customer service operations, but performing them more slowly. In a visit to the Boston regional office (one of ADP’s larger regions), Aberdeen found that the local Client Services group had opted not to implement the OS/2 solution because of performance concerns. This decision meant that ADP was simultaneously supporting two customer service implementations, neither of which truly met its needs.
Neither the mainframe nor the OS/2 solutions provided a consolidated view of ADP’s customers to the customer service representatives, because each customer phone call spawned a new record. Customer follow-up calls had no way of being associated with the initial record, and calls regarding one product could not be easily referenced to other calls from the same customer that might involve other products. Additionally, both solutions were inadequate in their ability to generate the reports needed to evaluate ADP’s responsiveness to customers.
A consequence of ADP’s experience with these previous implementations was a general wariness within the Client Services group concerning the ability to get an internally sourced custom solution on a timely or functionally satisfactory basis. That wariness fostered a desire to obtain a solution that had a greater proportion of productized functionality, rather than requiring significant custom development.
Figure 1 illustrates the decisions and early milestones associated with ADP’s project. Product decisions are not made in isolation, and business priorities often dictate — or greatly influence — available choices down the road.
In ADP’s case, the Customer Services group convened a project team to engage several customer service suppliers in a feature-oriented competitive review. This included major suppliers such as Vantive, Scopus, Remedy, Clarify, Software Artistry, and Broadway & Seymour. As previously mentioned, ADP was leery of a highly customized solution and felt that an aggressive project schedule also weighed against proposals with a high proportion of customization. Several supplier proposals were eliminated because of the amount of development required to provide core ACCESS functionality, and the final choice of supplier was narrowed to Clarify and Vantive.
Though users preferred Clarify’s interface, Vantive’s pricing — with heavy pilot discounts — made it a compelling choice until Clarify adopted an aggressive posture late in negotiations. Clarify eventually secured the project with a corporate license scheme that gives ADP access to any of Clarify’s various products for the same fixed price. Clarify’s ability to cite established NT references was also an important factor, given ADP’s interest in considering an NT-based solution.
Source: Aberdeen Group, February 1999
The selection of application server platform took precedence over the database choice and, in combination with the Clarify decision, fostered the initial database decision. Though ADP had Unix experience to call on, the application server choice for the ACCESS project was made in favor of an Intel/NT-based platform. ADP obtained a preliminary hardware quote from a prominent RISC/Unix provider and found that the hardware needed to support deployment to ADP regions was approximately $3,000,000 — with a prospective discount of 17%.
That was a preliminary quote, with fine-tuning and negotiation likely to have altered the final proposal. However, ADP did not pursue such fine-tuning, given that the alternative environment — Intel-based NT servers — provided cost advantages of a magnitude that precluded the need to pursue finely detailed RISC/Unix alternatives. The baseline difference in hardware costs between RISC and Intel servers approached $2,000,000. ADP’s Dell systems cost $20,000 per server, a total of $900,000 for the 45 servers needed to support all of the regions, as well as development/testing systems. Such a disparity between RISC/Unix and Intel/NT clearly illustrates the incentives that can motivate user organizations like ADP to pursue an NT-based solution.
The application choice of Clarify and platform choice of Intel/NT largely determined the 1996 database decision between SQL Server and Oracle. At the time of the ADP project commencement, Oracle had been ported to NT but was not supported by Clarify’s NT solution. That effectively removed Oracle from contention for the project’s pilot stages. ADP has stated that Oracle would have been a serious contender — perhaps the preferable choice — at the time of decision, because of familiarity with Oracle 7 and confidence in its performance. An enterprisewide deployment using SQL Server was viewed as a riskier proposition in mid-1996. Though Oracle assured ADP that support was forthcoming, the aggressive development and implementation schedule of the project would not allow for such delays.
In mid-1997, well after the ACCESS project had begun and ADP was into the pilot stages, Oracle was given the opportunity to propose a displacement of SQL Server. ADP’s consideration of a substitution was contingent on there being significant business advantages to warrant a change, with a primary consideration being the cost of the alternative. ADP indicated several times that replacement was predicated on any change to the database being “cost-neutral.” Table 1 outlines the costs that drove ADP’s analysis and illustrates that the price of Oracle was significantly higher.
Source: Aberdeen Group, February 1999
1 Upgrade costs are estimates based on current MS pricing and assume a 30% discount to the customer. SQL Server upgrades include five clients for each server; thus the total number of separate client licenses is reduced.
Several points of apparent difference between the respective quotes warrant explanation:
· The Oracle quote was for “concurrent users,” whereas Microsoft quoted “per seat” pricing for the clients. Concurrent licensing typically assumes a different model of user access and has a higher unit price than per-seat/per-user pricing because it supports a greater number of users. Several inquiries have identified no Oracle alternative to “concurrent” users — such as “per-seat” or “named user” — for the Oracle product.
· ADP required 7×24 support. Oracle proposed its Silver Support program for each user, with a full range of support inclusive of upgrades and maintenance releases. Microsoft proposed its Premier Support, an option that does not include upgrades. To address the three-year TCO period, Aberdeen has incorporated estimated upgrade pricing to move ACCESS from SQL 6.5 to 7.
· Oracle’s Silver Support for each of the 8,000 users appears to provide more than Microsoft’s flat rate proposal of centralized Premier Support for the entire configuration. The cost difference is startling large. Yet Microsoft’s Premier Support covers all ADP sites — the only restriction being the number of support incidents handled. In effect, ADP’s support costs from Microsoft would not vary significantly whether ADP deployed 500, 1,000, or 8,000 users. That provides a significant pricing advantage when compared with Oracle’s support program.
ADP notes that several factors diminished the real opportunity for Oracle to supplant SQL Server within a project that already was well underway:
· ADP had embarked upon an aggressive development and deployment schedule and was well into the project. Substituting Oracle for SQL Server would have entailed potentially significant switching costs.
· As a new port of the Clarify application to Oracle on NT, ADP was also wary of the stability of the solution.
· Original concerns about SQL Server 6.5 stability and scalability had been addressed in intervening months as the well-managed project moved forward, meeting deadlines and generating positive feedback.
In Table 2, Aberdeen shows ADP’s estimates of the additional staffing costs associated with administering the different database environments. Deployment and administration of a solution spanning 40 regions had potentially large ongoing costs, an important factor in evaluation of the respective costs of the solutions. An advantage to SQL Server was that Clarify was BackOffice certified, allowing ADP to exploit BackOffice services such as System Management Server (SMS) for software installation/upgrades. SMS — and the ability to operate as an NT Service — greatly facilitates deployment and administration of the solution.
ADP judged that the use of the NT/SQL Server platform allowed the local management of the ACCESS systems to be handled by regional staff administering its existing LANs. This was confirmed by Aberdeen’s visit to a regional office in which local IT staff professed little direct involvement in the system since it is remotely managed by ADP’s central organization. Therefore, while the internal cost to ADP for these LAN administrators is approximately $50,000 per year, ADP determined that the SQL Server solution represented no net new cost to ADP.
In contrast, ADP estimated that deployment of an Oracle-based application would require a database administrator in each region to perform services such as back-up, performance tuning, and database reorganization. This estimate was largely based upon ADP staff’s prior experience with Oracle-based solutions, though Oracle vociferously disputes this estimate. ADP estimated that the burdened cost of staffing an Oracle solution would be between $90K to $100K annually for each region. Aberdeen used the lower end of ADP’s estimate for comparisons.
Source: Aberdeen Group, February 1999
1 Reflects ADP’s assumption that existing local resources could administer system.
2 Represents the burdened cost (salary and benefits). Aberdeen has validated this estimate with inquiries to third-party recruiters, noting that costs vary with area of the country and experience of the candidate.
In Table 3, Aberdeen shows the costs to ADP of the SQL Server and BackOffice solutions as a percentage of the Oracle offering. As shown, ongoing support and administrative costs significantly increased the cost advantages to ADP of the Microsoft-based system.
Source: Aberdeen Group, February 1999
ADP’s ability to support regional deployments of the configuration with existing LAN administrative staff leveraged non-SQL Server-based functionality from BackOffice products like SMS Server. This made significant differences in ADP’s estimate of deployment costs and was an important element in its determination of TCO. Since those administrative advantages were not solely attributable to SQL Server, Aberdeen has not included an administrative comparison between Oracle and SQL Server alone, indicating “N/A” in those fields of the table.
ADP’s deployment incorporates 40 regional systems that range in size from 80 to 500 potential users. Initial deployment was to “Tier 1” users, of which approximately 4,600 are currently on-line. Tier 1 users are primarily customer service representatives (CSRs), handling calls and resolving issues — the heaviest users of the system. ADP characterizes the volume as high and fairly complex. Given the intensity of the current usage, ADP does not expect that the rollout of ACCESS to Tier 2 users will create performance issues.
The systems deployed in each region mirror a standard, corporate-approved system with an identical hardware/software configuration, regardless of region size — a Dell multi-processor server with 20 GB of storage. The use of Intel-based server hardware allows ADP to over-configure systems for the smaller sites to ensure a standard “out-of-the-box” solution applicable to all regions, rather than sizing to specific user populations. The relatively low-cost hardware also permits easier expansion to accommodate performance issues, should they arise. ADP notes no problems to date with support of the larger regions with these systems.
The main integration requirements for the servers involve regional mainframes and the phone switches that support the regional call centers. Updates to customer profile information are batch-downloaded every evening from the mainframes to the ACCESS system. This process allows the Clarify application to perform “screen pops” that display pertinent customer information when incoming calls are routed to the CSR. Much of the call volume involves actions that are processed on the mainframes. Though Clarify tracks activity associated with the inquiry, the operations to respond to the calls typically require significant mainframe interaction.
To manage this activity, each CSR is configured with an NT Workstation desktop and has up to five mainframe sessions in operation at a single time, accessing different versions of ADP products to respond to questions or to illustrate ADP product capabilities while the CSR has the customer on-line. Integration with the mainframe is done with Wall Data’s Rumba emulator and is handled independently of the NT server. Subsequent phases of the project will utilize Microsoft’s SNA Server to enable a third-party scripting tool to automatically link the CSR desktop to appropriate host screens for inquiry or data entry. These links will minimize the time and knowledge demanded of the CSR to access the appropriate screens, further accelerating call completion.
Although the ACCESS solution was a centrally developed and managed project, each region operates as a relatively distinct business unit. Customer data is maintained on the regional systems (mainframes for the core ADP business applications, the Clarify system for customer call records). This data is not rolled up into a centralized repository for consolidated reporting. Thus, while ACCESS involves distributed software deployment and management, it does not require a distributed database system that synchronizes the regional databases.
Aberdeen views the business and technical specifics of ADP’s deployment as mitigating some of the traditional technical challenges that Oracle could — and did — attempt to mount against the use of SQL Server in such a large-scale distributed environment. At the time of the 1996 decision, Oracle noted that SQL Server 6.5 did not fully support row-level locking (remedied in SQL Server 7). Because row-level locking did not impact the Clarify application’s ability to use the underlying database, it was not a material deficiency to ADP. Nor did the absence of two-way replication — another advantage asserted by Oracle — prove to be a significant issue. ADP’s configuration does not require any replication because each regional system operates as a stand-alone system and doesn’t share information with other regions. Should CSRs need customer information from other regions, ADP will provide Web-based access in a future phase of the Clarify deployment.
Finally, Oracle’s challenge to SQL Server’s scalability has proven not to be an issue. The use of low-cost Dell server hardware and the NT operating system means that ADP can configure the regional systems with enough horsepower to effectively overcome any potential deficiency in transaction throughput. ADP uses the same configuration in each region, regardless of the number of users. The company prefers a standardized setup and deployment methodology rather than precisely sizing and tuning each system to the number of users in the region. ADP has found no problems with SQL Server’s performance in even its largest regional systems.
The details of Aberdeen’s case study illustrate the significant cost advantages to ADP of SQL Server in product license, as well as support and administration. Oracle was 1.6 times the cost of SQL Server in software license and 3.7 times the cost when three years of support were included. Even when Aberdeen attributes an estimated cost to ADP’s expected upgrade to SQL Server 7, Oracle still would have proven to be 2.8 times the cost of SQL Server over three years. With discounts available to customers who purchase SQL Server bundled as part of the BackOffice Suite, the cost advantages clearly are on Microsoft’s side. ADP needed several products within BackOffice. As the pricing in Tables 1 and 3 illustrate, ADP could license the entire suite for the approximate cost of the Oracle database alone. Oracle’s bid proved not to be “cost neutral” — and the decision to stay with Microsoft was straightforward since SQL Server was performing well in the pilot.
The cost advantages of SQL Server to ADP became all the greater when the projected cost of administering the respective solutions was considered. The specifics of the planned deployment exploited advantages to SQL Server (as well as BackOffice) while minimizing potential advantages to Oracle. ADP’s multiple regional systems operate as stand-alone applications but require centralized administration. ADP successfully leveraged the services of products like SMS, as well as SQL Server’s overall ease of administration, to minimize the need for local staffing. Given the people that ADP already had in place, this translated into tremendous projected cost advantages for Microsoft versus Oracle, as Table 3 illustrates.
The timing of the project allowed ADP to make an initial SQL Server decision in the absence of a real alternative and, in essence, to get comfortable with the solution. Given the situation and timing, Aberdeen feels that Oracle faced significant challenges in establishing the business case, including pricing, which could persuade ADP of the requisite advantages needed to entice a switch. The information available to Aberdeen in this case study illustrates that Oracle did not approach the ADP opportunity with the creativity needed to overcome Microsoft’s advantages.
Not every situation will mirror ADP’s deployment, but Aberdeen views ADP as a clear example of a situation in which SQL Server can play a significant role in an enterprisewide solution of strategic importance. The Microsoft solution becomes all the more attractive given its approach to pricing and support, where central administration and distributed sites can be justified. Enterprise solutions put as great an emphasis upon deployment and administration as they do “feeds and speeds.” With the advancements in SQL Server 7, Aberdeen sees the Microsoft solutions as becoming ever-more-serious contenders for these types of applications. While ADP is only a single example, the pricing and cost comparisons evident from this project strongly suggest that Microsoft will be an attractive option for many organizations — and SQL Server a formidable challenger for enterprise deployments on the NT platform.