Copyright 1992 Association for Computing Machinery (Posted on the Internet by the author by permission of the ACM.) "Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing machinery. To copy otherwise, or to republish, requires a fee and/or specific permission." ACM-SIGUCCS XX, November 8-11, 1992 Proceedings of the User Services Conference (Association for Computing Machinery Special Interest Group for University and College Computing Services) ---------------------------------------------------------------------- DOWNSIZING AND OUTSOURCING OPPORTUNITIES: Right-sizing Requires Right-sourcing Don M. Wee, Associate Director, Network Software Loyola University Chicago Information Technologies Division 6525 N. Sheridan Road, Crown 104 Chicago, IL 60626 $ACSDMW@LUCCPUA.BITNET ABSTRACT Many systems in academic computing are being "right-sized," creating a diversity of platforms to support. This diversity offers differing support options for each platform, so attention must be paid to HOW decisions to insource or outsource are made. Examples of source-of-support decisions (including microcomputer repair, LAN design, and LAN training) are examined. Then the relative strengths of various support source options are reviewed. INTRODUCTION In the academic computing community, we have seen many opportunities arise in the past ten years to serve our institutions better by down-sizing or right-sizing applications. Some down-sizing has happened without a lot of planning because the path of least resistance and the most effective solution and the cheapest solution were all rolled into one: no strategic planning committee had to sell the faculty senate on the benefits of word processing with WordPerfect (or Microsoft Word) over SPF and VS-Script (or over vi and nroff). In other cases, our central computing organizations have had to lay the groundwork before new solutions could grow, such as wiring our campuses for LANs to enable new varieties of both structured and informal data sharing. Vendors also have brought right-sizing opportunities to our doorstep, by offering vertical market applications on multiple platforms -- they told us to choose whether to run it on a LAN server or a minicomputer. And as we all carefully set up our pilot projects in client-server databases, we will be ensuring that the diversity of applications on diverse platforms will continue to grow. The diversity of system solutions leads to choices for how to support them. A Blue shop that recruits a big-name researcher who has always run her lab on a VAX will need to provide that VAX...and the support organization for it. A VAX shop with an opportunity to cut capital costs and annual maintenance in half by moving an application to a LAN file server must get a LAN administrator and an Ethernet or token ring guru from somewhere. The institution, then, must define "somewhere." "Do we grow the internal support organization, or re-tread existing systems staff, or depend on a value-added-reseller (VAR) or consultant? Do we insource or outsource -- how do we right-source?" The question comes up again and again throughout our computing support organizations. OPPORTUNITIES TO RIGHT-SOURCE PC Maintenance At Loyola University Chicago, the early growth of PC use was widely dispersed, as was the responsibility for maintaining the PCs. By 1985, however, the PCs had reached a critical mass, and the Information Technologies Division (IT) saw an opportunity to improve the repair service that departments received and to reduce the costs to the institution. The decision at that time was to insource: to create a self-maintenance program. Several factors made Loyola's self-maintenance program effective in its early years. * Open architecture of the IBM PC and clones: Loyola's self-maintenance program was based on hiring full-time and student technicians to diagnose problems to the board level. Defective boards, displays, and drives were swapped out and exchanged with the manufacturer or sent for repair to third-party refurbishers. * Standardization: All computer purchase orders of $500 or more were reviewed by IT. This gave IT the chance to dangle the carrot, "If you buy from one of the supported manufacturers, IT will cover any repairs; if you buy an unsupported brand, your department must arrange and pay for its own repairs." * Critical mass: IT limited the support list to three vendors and kept volumes high enough to merit close attention from each manufacturer. One effect was to give us clout with service organizations. For example, Loyola was one of the first schools to be authorized by Zenith Data Systems to perform the school's own warranty work and exchange parts as an authorized service center. * Unified hardware and software support: The ability of the average person who uses a microcomputer to decide whether a problem is in software or hardware is, in a word, poor. Microcomputer staff were trained in major software applications as well as hardware maintenance, to be able to diagnose both kinds of problems over the phone, and to respond flexibly on a house call to the inevitable, "Oh, while you're here, could you also look at this PC...." In spite of the success of the first few years, the self- maintenance program began to break down. PC counts grew exponentially -- staffing never does. In spite of the continued existence of strong standards, the pace of industry growth made cost-effective stocking of parts impossible: the same number of models were available for new purchases, but we also had to stock parts for all of the models that were supported in previous years. (By mid-1992, only a handful of microcomputers had ever left the institution: hundreds of computers bought in 1983 and 1984 were still being repaired rather than being replaced.) With both staffing and parts falling behind, mean repair times exceeded a week, and median repair times approached a week. Thus, in 1990, a third-party maintenance organization was contracted to provide repair services for the university. (See Appendix B for an outline of the Request For Proposal.) The existing microcomputer staff continued to provide initial diagnosis and triage, but turned over a work order to the repair vendor's on-site technicians (dedicated to Loyola) as soon as it was diagnosed as a hardware problem. This allowed the internal staff to devote more attention to software problems and to installing new systems. The two largest effects of outsourcing PC maintenance have been greatly improved repair times and increased spending on repairs. The first effect was obviously the desired one: the requirement to restore service within one day for at least 85% of all service calls was met in every month in the 1991-92 contract year. The growth in spending on repairs was clearly not a desirable goal in itself, but a necessary tradeoff to avoid the hidden, unauditable costs of downtime. Under the self-maintenance program, resources for maintaining the university's investment in PCs did not and could not keep pace with the growing number of PCs. The IT division's overall operating budget kept up with inflation, but the installed base of PCs grew 80-100% in some early years and 20-25% a year recently. Simply keeping up with inflation meant spending fewer and fewer dollars per PC per year for repairs. Even more importantly, Loyola shares with many institutions a reluctance to add new staff. Even if more DOLLARS could be justified by an explosion in PC counts, BODIES would have to be fought for as a second hurdle, then hired and trained as a third hurdle. An external service provider, on the other hand, could hire staff in proportion to the size of its contract with the university, adjusting allocation of its trained technicians with the mixture of needs of its entire customer base. One important change Loyola made at the same time as outsourcing was to account for microcomputer repair funds separately from the IT division's operating budget. This allowed IT budget growth to be evaluated more clearly and allowed growth in repair costs to be correlated clearly to the growth in our installed base of PCs. At the very least, this allowed upper management to see the direct effect of capital outlays for new PCs on operating expenditures. Increasingly, managers are being forced to consider (and are being held accountable for) the life-cycle costs of their PC acquisitions. Loyola might go as far as to set aside funds at acquisition time to fund the repair contract over the expected life of the system. If these management options are taken, they will not have been a direct effect of the move to outsourcing, but they will have been enabled in part by the clear accountability that outsourcing fosters. LAN Design and Installation Loyola was an early adopter of Novell Netware as a standard for PC networking. An early staff LAN and student lab were networked with close cooperation between internal staff and a VAR. Soon, one of the lab managers was installing LANs throughout the university, and microcomputer staff were handling day-to-day LAN questions along with departmental LAN administrators. Because LAN support was cheaper to do in-house (and it was interesting work), Loyola staff leapt to the leading edge of this technology. However, we shifted rather abruptly to outsourcing for LAN design and installation as the bulk of our most experienced LAN technical staff left university life for more lucrative jobs in private industry. (Novell gurus may seem hot now, but they were already sought-after in the mid- and late-1980s.) Depending on VARs for LAN design and installation was troublesome. Although we trained LAN administrators in each department running a LAN, being dependent on a VAR for trouble- shooting services to keep our people productive made us painfully aware of how we were bidding for attention and priority against the VAR's other customers. We thus made it a top priority to bring LAN installation, design, and support back in-house, to re- establish consistency and ensure the institution could set its own priorities for response time. Re-creating in-house LAN expertise has had several components. LAN analyst/installer positions have been the focal point: these people are expected to be capable of passing Certified Netware Engineer (CNE) tests, and we have tried to minimize turnover in those positions. (See Appendix E for their job description.) LAN expertise has also been dispersed widely in the organization: some departmental LAN administrators have been heavily trained and are capable of installing their own servers; other IT staff have also been cross-trained in LANs. As we have moved from having 25% of our PCs connected to LANs to 50% connectedness in the past few years; as we look towards 85% connectedness in the next few years; and as we find ourselves being asked more and more often to provide infrastructure rather than data and applications, our commitment to keep LAN expertise in-house will remain strong. Training of LAN Administrators Loyola recently developed a training plan for departmental LAN administrators which calls for three tiers of training: * Basic training: This is outsourced by sending administrators to the first two courses for CNE training at Novell-authorized education centers. (This may be supplemented by computer-based courseware or videotaped courses in the future.) * Institutional training: A course is being developed in-house to provide an overview of institutional LAN standards and of enterprise-wide resources. LAN analysts will develop the curriculum and then turn regularly scheduled sessions over to the general training staff. * Specialized mentoring: The goal is to help a new LAN administrator become a LAN professional through one-on-one tutoring. The content would be centered on departmental issues but illustrate general principles: What is an appropriate backup strategy for this department's data? What security procedures and policies does this department need to promulgate? What is this department's disaster recovery plan? (It is unclear whether we can develop a relationship with a VAR to provide this mentoring, or whether this responsibility will be added to the LAN analysts' duties, or whether experienced LAN administrators will provide mentoring to new LAN administrators. All three avenues of support are still under consideration.) Resale of PCs to Individual Faculty/Staff/Students PC resale at Loyola has always been considered tangential to the mission of the institution, but has nevertheless been supported through measures such as a zero-interest faculty loan program (to improve publications and research productivity), and a companion program for full-time staff (as an employee benefit). As such, support for resale has generally been outsourced. Prospective buyers are given general information from IT, but, as much as possible, are sent to retail store showrooms to "kick the tires." (The manufacturer makes it possible for the retailer to offer a standard educational discount price and still receive a small markup or fee). In one case, another university's computer store was designated as the preferred point of sale. Telephones The opportunity to integrate data and voice services dictated both keeping this service in-house and moving it from a Purchasing function into IT. This has allowed Loyola to install a structured cabling system in virtually all university buildings to greatly reduce costs of moves/adds/changes to phones, terminals, and LAN nodes. Development of Transactional Systems Strategic planning consultants, after interviewing the institution's upper management, recommended that Loyola deal with its applications development backlog by buying more off-the shelf systems and developing fewer in-house. Loyola could then concentrate its limited in-house resources on the most critical systems. (Note the built-in assumption, once again, that there will be no substantial increase in staffing levels.) STRENGTHS AND WEAKNESSES OF THE THREE TYPES OF SUPPORT The trade press often reports on decisions to outsource a service or a reversal of such decisions back to insourcing, but central computing support organizations need to consider THREE choices for sources for support for an application or a technology: out, in, and very in. "Very In": Departmental Delivery The example of departmental delivery of support that I described earlier is the departmental LAN administrator. Such a person handles day-to-day support: fixing lost passwords, granting privileges to software, restoring a lost file from backup tapes and questions about the applications delivered through the LAN. Perhaps the LAN administrator also installs upgrades to software packages; or even upgrades to the LAN operating system. In some cases, the LAN administrator may be a key member of a department's own applications development group. Even if a department does not have a LAN, it can profit by identifying a departmental computing coordinator (DCC), by tapping the data administrator for a mainframe application or just the local power user. The advantages of departmental delivery can be substantial. To borrow the lingo of our corporate brethren (and sisters): * Profit/revenue centers like Accounts Receivable or Admissions can justify staff growth more directly than a cost center like IT. * Getting computer expertise into the department allows computer solutions to be tailored by someone who is trusted to be familiar with that line of business. Excel isn't chosen for the department over 1-2-3 because it is easier to support but because a particular statistic is used heavily and implemented more easily...or because the VP of Finance is a fanatic about color presentations. * On-site service is always preferred to phone service. * Simple problems that might otherwise flood the Help Desk can be solved once with the DCC, then solved locally (and faster) by the DCC for his or her cohorts. * Problems for which the DCC needs second-level support are presented to IT more precisely, using appropriate jargon, and the DCC can bring more resources (both software and knowledge) to bear on the problem than the average client. * Training can be invested in the DCC and leveraged back to the rest of the department. * The DCC can act as spokesperson for requesting resources and services for the department, translating both computer jargon and the jargon of the department into English. There are risks in creating DCCs and using the "very-in-sourcing" option. Tapping a power user who knows one tool well to be a department's DCC may encourage the use of inappropriate tools. (To a person who has only a hammer, everything is a nail: to a spreadsheet guru, 1-2-3 may seem to be the tool of choice for writing memos and sorting disk directories and producing mailing labels.) Someone who learned computing informally on a PC in his or her spare time may unknowingly teach the department bad computing practices: never having studied the concept of file locking, the DCC might throw a text file onto the LAN for everyone to update with non-network-aware text editors, overwriting each others' updates. And if the DCC's computing duties remain informal, the department runs the risks of the dual roles coming into conflict in unplanned ways: both the risk of the computing duties interfering with the DCC's normal duties and wasting the DCC's professional training, and the risk that a critical need for the DCC's normal non-computer skills makes the DCC unavailable to follow through on a similarly critical computer project. Thus, to be able to reap the benefits fully, you may need to lay some groundwork. * Definition: If you create well-defined sets of accountabilities for standard kinds of DCCs with Personnel, departments can then include one in a job description to define "the computer part of the job" and make it official. The department can then make a commitment to having those services performed within the department, and define the relative time demands of those duties. * Compensation: It is doubtful that any Personnel department would let itself get pinned down to saying "being a LAN administrator is worth $X per year over being just an administrative assistant" -- but having duties comparable to another LAN administrator lays the groundwork for meaningful comparisons and discussions of equity. * Accountability: DCCs generally are not formally trained as computer professionals and are not directly supervised by IT. The DCC portion of the job description can be the best avenue to define a responsibility to adhere to institutional policies and standards ("you will NOT use first names as passwords; you need to do weekly backups"). More importantly, the job description can define relationships: required attendance at group update meetings, or IT participation in annual reviews for this portion of the job. * Training: Some departments will see training as IT's contribution in return for some influence or control...or for being off the hook for providing the services directly. This is also an opportunity to build consistency across departments. It can take the form of regularly-scheduled classes; regular update meetings of all DCCs; one-one-one tutoring; a newsletter; or a combination of these. * Hierarchy: Ideally, each division or school should have a computer spokesperson for the vice-president or dean; otherwise, one department that has a DCC might be making all computer requests for the whole school...to the dismay of other departments without DCCs. A school-wide computing coordinator is also needed to prioritize requests for service from the school's departments: too often, IT responds to "ASAP" requests in First-In-First-Out fashion for lack of an authoritative voice to choose any other order. (Beware: administrators may prefer to be free of the responsibility to balance the computing needs of their departments. There was once a trend at Loyola to send all computer requests to IT and have IT dole out PCs -- if a department was unhappy, the dean was off the hook -- and out of the loop. Fortunately, that trend was reversed.) At Loyola, we have seen some departments push the envelope both technically and in terms of testing the limits of decentralization. Besides answering support questions internally and installing their own file servers and developing their own applications, they have found themselves acquiring clients from other departments. Now they face issues of juggling development timetables with support requests, and developing cross-training of support staff: "we became independent of IT and now we've BECOME IT...and we don't like it." So some of the very-in support services may swing back to the university-wide sources...even as other departments become more capable and more independent. "In": University-wide Resource Delivery If departments can go as far as form their own applications development teams, why not split up all of IT? We might prefer to avoid the whole issue, but we need to be prepared to answer those who will suggest decentralizing everything. Clearly, some services MUST be standard throughout the institution to enable sharing of information and resources across departments and divisions: sufficient infrastructure and clear interfaces to the infrastructure must be provided and defined. Obvious candidates include network backbones, universal e-mail directories and hubs, wiring, telephone service, gateways to outside services, a data dictionary, and a central data repository for basic personnel, faculty, and student data. Some services can be better or more affordable with institutional economies of scale. Negotiations for repair contracts on PCs, copiers, or fax machines might be centralized for this reason (though some institutions seem to operate fine without centralizing these). Statisticians might be a shared resource for multiple schools that might be placed with IT. Second-level LAN expertise might be affordable only if shared institutionally -- in 1991, the two computer job titles with the fastest salary-growth rates were "CASE Tool Specialist" (13.2%) and "LAN/WAN Specialist" (13%) (Robert Half, 1991). And administration of software site licenses lends itself naturally to centralization, sometimes dragging technical support of those software titles naturally with it. Economies of scale apply not only to the basic cost of a service, but also to the resilience of the service: a school may be able to afford its own LAN installer, but may flounder for months if that individual leaves; whereas if a team of university-wide LAN installers had designed that school's LANs, the school might better ride through the resignation of one installer. There are other central services that are a little harder to define. The computer trade press showcases some moderately large organizations that are run totally by PC LANs and database servers. Even if some colleges and universities reach that degree of down-sizing, to be rid of all mainframes and minis, they would be unwise to replace EVERYONE with all new PC- and LAN-oriented staff. All the hard lessons of the "data processing" days of the industry need to be retained and applied: lessons about backup, security, capacity planning, and risk management; lessons imperfectly applied thus far in the LAN/PC world. "Out": When to Use External Support Organizations Outsourcing can be a solution to a problem that shines like the light at the end of the tunnel; or it might be a tactic, chosen among several alternatives to accomplish a specific goal or side- effect. Here are some clues that outsourcing deserves serious consideration in a given situation. * Your problem is a lot like everyone else's: In analyzing the three tiers of LAN administrator training, we concluded that the basics our new LAN administrators needed to know were not unique to Loyola and could easily be outsourced. * Your internal resources are operating at capacity: At Loyola, we are confident that we could provide basic LAN administration training more cheaply internally than via outsourcing. But our only appropriate resources to provide that training are our LAN installers. If we COULD free them up enough to do basic training for LAN administrators, other unfulfilled claims on their time would take priority. * You have enough control elsewhere: Before outsourcing of PC maintenance was finalized, we had to answer objections that outsourcing could harm service by turning over too much control to an outside company unfamiliar with our standards and departmental requirements. Some of those concerns were answered by having IT continue to provide triage and software support, as well as purchase review. * You need to hire people: A PC WEEK columnist described some tactics for growing a computing organization (Currid, 1990b). One tactic was to prove the value of a new service by hiring someone to do it on a contract or consulting basis -- then point to all the dollars you would save by bringing the function in-house. If Loyola, as planned, starts replacing PCs at some point instead of continually adding to its PC count, then we can revisit the question of what PC repair services should be outsourced and which should be provided by staff. Hiring a stable number of technicians and contracting our current service vendor to provide the parts inventory and parts refurbishment may be cost-effective by that point. Our outsourcing phase will have verified the right number of technicians and the kinds of parts flow needed. * You need to be able to fire someone: Somewhat paradoxically, Loyola's PC repair program could be controlled more fully by outsourcing. By going outside, we could hold a service provider fully responsible and enforce performance requirements with dollar penalties or cancellation. In an outsourcing context, laying out such rules was simply part of establishing a clear business relationship. No analogue could exist with services provided internally, unless an institution were willing to threaten a department with broad pay cuts or mass firings for failure to meet performance goals. * You need to make a transition: VARs filled in the gap for Loyola LAN installs after our initial experience in installing our own LANs and before the new LAN staff and expertise were built up. The computer trade press also describes "transitional outsourcing" as a tool to facilitate down-sizing from a mainframe to distributed platforms (Middleton, 1992). * Your commitment to provide the service is low: By outsourcing most of Loyola's PC resale program, Loyola has minimized its investment in space, staff, and equipment for this service. If further reductions in spending on this service are required, minimal dollars are lost and minimal staff shuffling is needed. SUMMARY Clearly, no hard and fast rules exist for when to outsource, when to provide support in-house with centralized resources, and when to use in-house departmental resources. The most appropriate locus of support can change over time. Often, the decision will be based pragmatically on where the resources are available and what they cost. At other times, more strategic issues drive the choice. As computing professionals in the central support organizations, we can best approach these decisions by looking at the issues broadly and identifying opportunities to leverage expertise, to enhance accountability, and to apply creative solutions to familiar needs. APPENDIX A: ADDITIONAL READING Addelson, Roger, and Wee, Don; "Starting a University Microcomputer Maintenance Program," ACM SIGUCCS USER SERVICES CONFERENCE XIV PROCEEDINGS, 1986; pp. 419-454. Currid, Cheryl; "Creative staffing yields big returns for management," PC WEEK; March 12, 1990; v7 n10 p. 127. Currid, Cheryl; "When times are lean, beg, borrow or rent extra help," PC WEEK; March 19, 1990; v7 n11 p. 137. Half, Robert; SALARY GUIDE: 1991 --Accounting, Finance, Information Systems; Robert Half International; 1991. Middleton, Timothy; "Today's Decision: Do It Yourself," CORPORATE COMPUTING, September, 1992; I(3):17-18. Seymour, Jim; "IS outsourcing review: tough but rewarding," PC WEEK; Dec 2, 1991; v8 n48 p. 63. Seymour, Jim; "Out-sourcing revisited: when it's wrong, it's very wrong," PC WEEK; March 12, 1990; v7 n10 p. 10. Wee, Don; "On the Care and Feeding of Superusers," ACM SIGUCCS USER SERVICES CONFERENCE XV PROCEEDINGS, 1987; pp. 335-342. Weinberg, Gerald; THE SECRETS OF CONSULTING: A Guide to Giving and Getting Advice Successfully; Dorset House, New York; 1985. TLINE FOR MICROCOMPUTER REPAIR APPENDIX B: SAMPLE RFP OUTLINE FOR MICROCOMPUTER REPAIR I. Introduction to Loyola University Chicago A. General background about campuses, mission B. History of PC support 1. Exponential PC growth from 1984 to 1988 2. Steady 500-600 per year growth since then 3. Self-maintenance from 1985-1990 II. Current situation A. Approximately 4500 PCs (see inventory report) B. Some items not supported by computing division are excluded from the contract (see supported equipment list) C. Minicomputer and mainframe equipment handled under separate contracts D. Description of current repair vendor's services E. Loyola provides remaining support services internally: triage and problem referral; software problem resolution; installation of new equipment; training III. Scope of bids: all systems based on IBM-compatible CPUs on support list, plus supported external PC peripherals on support list attached to non-supported CPUs IV. Items sought in contract A. Key requirement: dedicated on-site technicians 1. Dispatched by Loyola staff 2. Report call progress at least daily to Loyola staff B. Key requirement: Performance standards (for each month) 1. Restore service, possibly via loaner, within 8 working hours for 85+% of calls 2. Restore service, possibly via loaner, within 24 working hours for 95+% of calls 3. Replace or repair original system within 15 working days for 100% of calls C. Key requirement: reliable call tracking & reporting procedures D. Key requirement: Loans and permanent swaps and substitutions 1. Required: equal or greater functionality 2. Optimal: from a pre-approved substitution list 3. Required: designated Loyola computing staff to agree to substitutions not on list E. Key requirement: Provisions for critical systems 1. Required: After-hours service for LAN file servers and other critical systems 2. Required: "hot spares" for LAN file servers 3. Approximately 90 critical systems F. Key requirement: parts availability 1. Required: on-site parts and loaner storage 2. Optimal: large corporate inventory to back up and re-fill local inventory 3. Optimal: strong manufacturer relationships for parts access G. Required: Back-ups to regular technicians 1. Required: cover absence, training, or overload 2. Optimal: from a familiar pool 3. Required: Loyola can choose to replace technicians H. Required: explicit escalation procedures I. Optimal: Penalty clause to enforce standards J. Optimal: in-warranty equipment procedures 1. Optimal: take advantage of long educational HP warranties to reduce growth of cost 2. Optimal: minimize need for Loyola paperwork K. Required: annual cap to contract costs L. Required: simple ways to add systems to contract 1. Optimal: mail serial numbers for supported brands 2. Optimal: minimal lead time for adding new brands/models V. Evaluation criteria A. Evidence of ability to handle similar accounts (references) B. Evidence of access to parts (warranty authorization, inventory listings vs systems covered), especially Zenith C. Price APPENDIX C: SAMPLE COST JUSTIFICATION ON-SITE PC REPAIR CONTRACT VS. TIME-AND-MATERIALS SUMMARY 1 Cost of contract over Time+Materials costs $26,400 2 Direct value of added services in contract $30,686 3 Indirect value of reduced downtime $79,424 4 Net value of contract over T+M $83,710 ==================================================== Costs 5 Contract costs/month $ X 6 Annual cost $ 12X 7 Time+Materials cost/mo, Vendor est $ Y 8 Time+Materials cost/yr, Vendor est $ 12Y --------- 9 Premium paid for contract $26,400 = 12X-12Y Sum for Benefits of Added Services all campuses 10 Overtime, after-hrs critical systems $720 11 Est # crit. incidents 6 12 Est hrs work/incident 3 13 Est overtime surcharge/hr $40 14 Loaners $16,026 15 Est cost/yr to provide own base 11410 (stock enough PCs/monitors/printers to cover several simultaneous loans; regularly replace to cover new models) 16 Est cost/yr to rent for peak use 4616 (based on daily rental charges) 17 Preventive maintenance performed $11,700 18 Est hours of work performed 156 19 Est hourly charge $75 20 Supplementing IT staff, slack time $2,240 (help w/installs, software calls) 21 Est hrs of work performed/yr 448 22 Est hourly wages saved $5 ---------------------------------------------------- 23 Direct value of added services $30,686 Benefits of Reduced Downtime 24 Improved response (on-site tech) $39,935 25 Est hourly downtime cost $35 (one person at 1/2 productivity, two other people at 1/4 productivity) 26 Est downtime for dispatch 1141 27 Est added dispatch time/incident 1 28 # incidents (service calls in 1 yr) 1141 29 Improved repair (on-site parts) $15,528 30 Est hourly downtime cost $35 31 Est downtime for parts dispatch 443.7 32 Est parts disp time/incident 1.2 33 Est % incidents requiring parts disp 33% 34 Est # incidents w/parts disp 380.3 35 Performance requirements/priority $23,961 36 Est hourly downtime cost $35 37 Est downtime for lack of 3 day limit 684.6 38 Est avg added time, incidents > 3 days 12.0 39 Est added % incidents exceeding 3 days 5% 40 Est added # incidents exceeding 3 days 57.1 ---------------------------------------------------- 41 Est reduced downtime vs T+M, hrs/yr 2269 42 Indirect value of reduced downtime $79,424 NOTES REGARDING INDIVIDUAL ENTRIES 5 Vendor doesn't want competitors to know what they bid. 7 Vendor reviewed all service calls in four typical months and computed what they would have charged if contract had not been in place. 10 Number of after-hours repairs were much lower than expected. 15-16 Based on number of loaners in actual simultaneous use during preceding 12 months: eg, at one campus, often used two systems and four monitors at once; only needed three systems simultaneously on two occasions, so base would be two systems -- third system for peaks would be rented as needed. More realistic than just using rental charges to estimate the value of loaners currently provided. 17,20 Top priority is given to repairs. If no service calls are outstanding, preventive maintenance is to be done. If all scheduled preventive maintenance has been performed, external technician will assist internal support staff. 22 Very conservative estimate, assuming work could be done as quickly by student staff 24 Under T+M agreement, techs would be dispatched from a western suburb and would add travel time to first call each day on each campus 25 This may be a conservative estimate; assumes non-critical systems involved 29 Under T+M, techs carry a few common parts but call to central office to have courier deliver additional parts 35 Under T+M, without performance requirement, Loyola would wait longer for equipment to return from bench repair ENTAL COMPUTING COORDINATOR PROGRAM APPENDIX D: SUMMARY OF DEPARTMMENTAL COMPUTING COORDINATOR PROGRAM The description of Departmental Computing Coordinator is an "accountability." An "accountability" is an individual component of a job description at Loyola. Usually, a particular job description will contain several accountabilities, each of which is assigned a PERCENTAGE OF TIME and a RATING OF THE IMPACT of the performance of that component on the institution. DCC was set up as an accountability, rather than as a job description in itself, to accommodate different percentages of time required to fulfill the DCC responsibilities according to department size and level of computerization. For example, in some small departments, the DCC responsibilities can be fulfilled using a small percentage of one staff member's time, while a large department might require that a full-time staff member be dedicated as a DCC. The same flexibility is required in rating the impact of the DCC responsibility. Areas of Responsibility for DCCs * Liaison: All DCCs have the responsibility to be a Liaison between IT and the DCC's department. * LAN Administrator: If a department has a LAN, at least one individual must be designated network administrator. * Departmental Data Administrator: At least one individual must be designated data administrator if the department locally maintains mission-critical electronic data owned by the institution. DCC Liaison Role DCCs represent their department's computer users to IT, and represents IT to their department. The DCC is IT's key contact in that department. Communications are directed through the DCC to provide more efficient and accurate communication. The DCC will be expected to: * Attend meetings hosted by IT for DCCs. Meetings will take place every two months, with occasional special events meetings. * Participate in the evaluation of software and hardware. Project teams including both DCCs and IT staff will jointly evaluate software for general use at Loyola. * Report IT developments to the department. * Report departmental computing activities to IT. * Serve as the department's "first contact" for computing questions, and arrange for appropriate follow-up support from IT, as necessary. DCC LAN Administrator Role All LANs need someone to be designated as network administrator. The DCC who is a LAN administrator should note this in his/her Position Description Questionnaire (PDQ), with a brief description of the functions of the LAN, the number of network workstations, and the time required to perform this role. The inclusion of "LAN administrator" under the DCC accountability in a PDQ will indicate that the DCC does the following: * Network Planning: The DCC will work with IT staff to provide specific hardware and software recommendations based on the department's requirements. Determine the preliminary needs for workstations, printers, etc. Monitor hardware usage and determine when additional storage, printers, or other equipment is needed. Determine the need for software upgrades and additional software licenses. * Setup and Installation: Although IT staff may perform much of the actual installing, the DCC will need at least to provide information about software requirements, access restrictions, and general operating procedures unique to the department. * Non-supported specialized software packages purchased from external sources should include an ongoing maintenance and support agreement. These will not be handled by regular IT support staff. * Support for day-to-day LAN operations: This includes adding and deleting users; assigning individual and group security rights; system booting/rebooting; managing printer queues; controlling gateway access; and managing and backing up network storage resources. The LAN administrator provides first-level support for the Novell operating system and trouble-shoots problems. Problems that the DCC cannot resolve are referred to IT. * Instruction: The LAN administrator trains individual new users who were not present at the initial network training. The LAN administrator will also identify other training needs and work with IT to meet those needs. * Receive training: The LAN administrator must attain appropriate proficiency in the LAN operating system, generally by attending Novell authorized courses for System Manager and Advanced System Manager training. DCC Data Administration Role The DCC/Departmental Data Administrator (DDA) will be the department's liaison with IT's Data Administration Department. The basic responsibilities of the role are: * Planning: Identify office functions or decision support areas that could be improved through automation. * Programming: Maintain familiarity with IT's standard software and the levels of support available. Follow IT's naming conventions, programming standards, and procedures. * Documentation: The DDA must know what data management systems exist, what data they contain, who uses them, and how they are used. The DDA will prepare user documentation that consists of procedures and copies of screens and sample reports. System documentation will include system requirements, design, program listing, file and field identification, copies of screens and reports, and requests for changes. * Data backup and recovery: Mainframe data management systems have daily backups (copies going back five days) and weekly backups (copies going back five weeks). Departmental microcomputer and minicomputer systems will have a DCC assigned to the task of backup and recovery. NSTALLER APPENDIX E: SAMPLE JOB DESCRIPTION FOR LAN ANALYST/INSTALLER Primary Accountabilities * Analyze needs of departments planning to install or expand local-area networks (LANs) of microcomputers and design appropriate LAN systems and procedures for departments (25% -- all percentages approximate) * Install and configure LAN operating systems, applications, and equipment (30%) * Maintain, troubleshoot, and repair malfunctioning LANs (15%) * Train departmental computing coordinators/LAN administrators and local support staff to perform day-to-day support functions and Train individuals to take advantage of LANs (15%) * Document configurations of departmental LANs, standards for installation, and backup procedures (5%) * Evaluate and recommend new technologies, standards, and procedures for connecting computers and computer applications (10%) Occasional and Infrequent tasks * Design and write LAN utilities (5/year) * Respond to after-hours emergencies (3/year) Job requirements: * BS in computer science or equivalent * 3-4 years experience supporting the use of PCs * 2 years experience in administering and installing Novell LANs * Novell "Certified Netware Engineer" certification highly desirable but not required.