Please note: This material is no longer current and appears online for archival purposes only.
Use the search and navigation tools above to locate more up-to-date materials, if they exist.

RESTRUCTURING COMPUTING SERVICES
ACROSS PENN

CONTENTS

1. Penn's new structure for computing
   
2. Why a new model?
   
3. Effect on costs
   
4. The "social contract": Assumptions and principles
   
5. From old to new: An overview (four charts)
   
6. Next steps
   
7. Pilot projects
   
8. Challenges
   

Appendices

1. Task Force to Restructure Computing across Penn
   
2. Implementation Steering Group
   
3. Frontline support: Choices and responsibilities
   
4. Building blocks for budgeting
   
5. Selling services where markets exist
   
6. Proposal to support students where they live
   
7. Technology refreshment of public labs
   
8. Services for local providers of computing
   

Computing now touches everyone at Penn. Demand is soaring and Penn's investment is sure to expand. Those who use and those who provide computing services recognize that support can be improved. A task force has developed a new campus-wide structure to make computing easier and more cost-effective for those who use it. The new model will guide organizational change over the next several years.

The new structure clarifies a division of labor that lets the schools and the central computing group each devote more effort to the things it does best. Schools and administrative units take on full responsibility for the frontline support of their members. They also provide local systems, services, and innovations. In turn, the central computing group, Information Systems and Computing, will concentrate on infrastructure (networking, core business systems) and put more effort into services for local computing providers and into standards.

Both the central computing group and the schools are more accountable. Schools bear major responsibilities and in return get greater control over costs and level of support. Penn can't magically increase the total amount of money available for computing, but we can ensure that funding decisions are made as close as possible to the people affected by them and made along with other decisions that will determine Penn's future.

This document. This document describes the new model from the point of view of funding, always a hot issue at Penn. It outlines reasons for the new approach, describes its impact on costs, sets out principles, and describes the funding and delivery of services. It reviews next steps and challenges. Sections 1-8 serve as an overview, with detail in a series of appendices.

More information. More information about the project can be found in its Web site at http://www.upenn.edu/computing/restruct/.

RESTRUCTURING COMPUTING SERVICES
ACROSS PENN

1. Penn's new structure for computing

Penn's new structure for computing services puts the user at the center. Each person should have a local computing "home" and take all computing questions there. Beyond this circle of frontline support are expanding circles of secondary services, provided by the schools and the central group, Information Systems and Computing. But the map of services is irrelevant to recipients: the frontline support person navigates that landscape for them.

Schools and administrative units take full responsibility for the frontline support of their own members. They can provide it themselves or buy it from each other or from ISC. ISC, in turn, provides a more focused and delimited set of secondary services: networking, core administrative systems, standards, and services for local providers. New strategies promote responsiveness and give the community a stronger voice. The network, for example, will be run as a "regulated public utility," with service agreements, campus standards, and a governing board drawn from Penn's schools and units. In other areas, the model encourages ISC and others to put services to the market test, selling them where demand exists.

The model offers a potentially powerful way for Penn to take action at the University level; a few cross-cutting processes will be funded directly and managed across traditional organizational boundaries.

Section 5 contrasts the new approach to Penn's current system. An earlier document, published in Almanac, also describes the new approach in some detail. It can be seen at http://www.upenn.edu/computing/restruct/model.html.

The new approach doesn't claim to do everything. It doesn't ignore history. It's a way of doing business that gives members of the community the chance to make Penn better and exposes each of us to the costs of bad decisions and the benefits of good ones.

An evolving framework. The new structure was developed in the fall of 1995 by the campus-wide Task Force to Restructure Computing Services at Penn (Appendix A) and vetted across the University. An Implementation Steering Group (Appendix B) carries on the work of the task force. It developed the funding strategies reported here, with the help of seven pilot projects (Section 7) that are testing aspects of the new structure. The funding strategies will continue to evolve with lessons from the pilots and consultation with the community.

2. Why a new model?

Penn exists in a world fueled by information. The vitality of research and instruction have come to depend in large part on information technology. Penn's computing facilities are a competitive factor in recruiting faculty, and increasingly in recruiting students. Penn's ability to save money in administrative areas for reinvestment in the academic mission likewise depends on computing. The network, to take an example that applies to all these cases, is Penn's link to an interconnected world and key to the success of other investments across the University.

Penn's structures for computing support can be improved. Some things are needlessly complicated. People don't always know where to go for help. Gaps in service are frustrating. It's hard to tell what things cost. Changing these things won't be easy--demand will continue to soar, technology changes relentlessly, and Penn is a very complex place. But we have accepted the challenge to make computing work better at Penn.

Each of Penn's twelve schools supports the computing needs of its faculty and students in different ways--and the principle of Responsibility Center Management requires us to expect the schools to pay their own way. Some, but not all, of Penn's administrative divisions have their own computing staffs. Over time the central computing group has come to provide a catchbasin of services ranging from infrastructure to frontline user support. Central/peripheral tensions are played out at several levels, from ISC and the schools to the schools and their departments. The Library is caught in the middle. And everywhere people need more and better support. In short, we have had Responsibility Center Management in principle, but a messy situation in practice.

3. Effect on costs

Computing is an area of growth and leverage at Penn, one that helps the University save money elsewhere. Penn's campaign to restructure all core administrative activities over the next few years, for example--and apply the savings to the academic mission--is largely predicated on the capabilities of modern information systems.

From a financial perspective, Penn's new structure for computing has three aims: targeted investment, cost-effectiveness, and greater control for schools and units. The model promotes a more rational division of labor--and makes both ISC and the schools more accountable. Overall costs in this expanding area will not decline, but the new structure should help Penn spend its computing dollars in the right places and help Penn get more for each dollar it spends. Money saved in some areas of computing can be reinvested in others.

The new structure does not bring a reduction in the allocated costs that schools pay ISC, but it brings savings for reinvestment in campus initiatives. ISC will post savings as it stops providing general frontline support (except on a contract or other special basis), as it retires debt service on the original network infrastructure and mainframe, and as it consolidates activities and streamlines practices. These savings can be returned to the Provost's budget for investment in strategic computing initiatives across Penn.

The new model clarifies and delimits the services ISC will provide under allocated costs, as later sections will show. And it gives the Penn community a stronger voice. The network, for example, will be run as a regulated public utility, with service agreements, campus standards, and a "public utility commission," or campus governing board. Made up of school computing directors, faculty, and other customers, the board will set priorities, approve rates and service levels, and help make decisions about technology direction.

The chart below outlines ISC's current allocated-cost budget, with expected trends. The model neither proposes nor assumes changes in the formulas for calculating allocated costs.

Expected trends in ISC's allocated-cost budget under new model
Current ISC Service	Current Allocated- Cost Budget	Expected Trend
Core admin. systems and data	$8,200,000 (62% of allocated- cost budget)		Penn will invest heavily in new systems. Allocated costs for new systems are expected to be budgeted largely through the central business units whose functions are at stake (as with FinMIS). Funds would flow to ISC on a direct-charge basis, increasing the accountability of both ISC and the central unit. ISC's allocated-cost budget would continue to be devoted largely to Penn's installed base of systems.
Networking	$2,100,000 (16%)	topic of study	Designing a fair and strategic funding model for the network will be a first task of the soon-to-be-launched network "public utility commission" or campus governing board.
Standards, emerging technology	$400,000 (3%)		ISC will devote more effort here, reallocating from other areas.
Services for local providers of computing	$1,000,000 (7.5%)		ISC will devote more effort here, reallocating from other areas.
Frontline support to end-users in schools and units	$680,000 (5%)		ISC will no longer provide general frontline support to the Penn community except on a contract or other special basis.
ISC-wide admin, planning	$890,000 (6.5%)		ISC will seek efficiencies in this and other areas.

The model puts services to the market test where possible. It encourages ISC (or entrepreneurial schools or units) to sell services where markets exist. The intent is to establish, over time, enough of a marketplace to help control costs and create a focus on the customer. Two services, for example, that ISC will offer on a contract basis are frontline support-on-site and facilities management of computer systems. Appendix E contains guidelines for small businesses such as these, which the task force has been calling "service bureaus."

Schools and units will have greater choice and control in other areas as well. They take on full responsibility for the frontline support of their members. This is good for their members, who get help from people who know their needs and histories. And it's the fairest place in the institution to make tradeoffs between service and cost; local providers can do a good job of telling users what things really cost and helping them make responsible decisions. It also ends current incentives to perceive allocated-cost support as unlimited. (Schools can provide frontline support themselves or buy it from another unit. Several schools and the President's and Provost's offices, for example, already buy support-on-site from ISC. Many departments buy support-on-site from their school's central computing group.)

The model's new cross-University "process teams" offer a way for individual units to contribute a little and get back a lot. Process teams are an invitation to confederation at its best. The model encourages confederation in more everyday ways as well. In one approach to services targeted to local providers of computing, for example, the model builds on one of Penn's great strengths, a flourishing informal network of campus experts who help each other solve problems and work together on campus projects. From ISC, the model calls for more explicit and sustained coordination of these confederated efforts. And from all participants, the model calls for more explicit definition of roles and responsibilities.

The new model promotes incentives (financial where possible) for standards that contain support costs and help people work together. Such efficiencies, in a climate of exploding demand, can help contain the growth in computing costs at Penn.

All in all, the new structure tries to unite responsibility and authority where they've grown apart, to reveal real costs where they've become obscured, and to return choice to purchasers where it has been eroded.

4. The "social contract": Assumptions and principles

The flow of funds makes concrete the relations between people and organizations. Those relationships can be thought of as a "social contract." The terms of the social contract inherent in the new structure for computing are set forth below, followed by principles and guidelines for the funding of services within the contract. Applying the principles and operating guidelines to a collection of pilot cases has yielded the funding strategies described in this document.

Assumptions. The funding framework, like the entire model, rests on two assumptions about computing. First, computing isn't something that happens "somewhere else." It's inseparable from Penn's mission and touches every member of the University community. Second, funding for computing is everyone's business. The computing infrastructure is part of the campus infrastructure and should be factored into budgetary and fundraising strategies. The model affirms Penn's structure of Responsibility Center Management and tries to unite responsibility and authority where they have drifted apart.

Terms of the contract. Each party has a role in making Penn's new structure for computing work:

• Providers will offer services at agreed-upon levels and make sure users know what support is available and how best to use it.

• Users of services will fund those services at agreed-upon levels, through direct charge, allocated cost, or other arrangements.

• Users and providers will use shared principles, such as those below, to decide when and how to fund computing services. Each decision will strengthen or weaken the social contract.

Funding principles. The framework is guided by five funding principles.

Link choice and responsibility.

Schools and units should be able to make choices about how to meet their own computing needs. With this choice comes responsibility for the consequences on finances, customer satisfaction, productivity, and learning--and for the effect on others in the Penn community.

Reserve central funds for the benefit of the enterprise as a whole.

The new computing structure draws on allocated costs (taxes) for services that are strategic to the institution as a whole, that sustain the infrastructure and standards that make Penn a single enterprise, or that offer clear economies of scale.

Put services to the market test where it makes sense.

The computing framework calls for direct charges where markets exist for custom or specialized services or where the institution has an interest in exposing services to the discipline of the market.

Fund processes directly.

To overcome barriers and boundaries, fund where possible the process or activity itself, not the traditional organizational unit.

Seek leverage.

Take advantage of existing resources and larger campus initiatives. Add value by funding targeted expertise. Apply seed money and matching funds.

Operating guidelines. Funding guidelines also inform the framework:

• Make costs visible. Identify tradeoffs.
• Clarify expectations.
• Take life-cycle costs into account.
• Encourage standards.
• Recognize economies of scale.
• Keep it simple.

5. From old to new--An overview

Four charts below contrast the new framework to Penn's current system. The first chart describes frontline support. The next two charts outline secondary support. A fourth chart describes cross-University process teams that focus action at the University level. This section is an overview, with details and open issues in a series of appendices.

Secondary support complements and enables frontline support. The next chart describes secondary support provided by schools and units. The chart after that focuses on secondary support provided by the central computing group.

The third chart, below, outlines secondary support provided by the central computing group, Information Systems and Computing.

In practice, of course, the above distinction of "frontline" and "secondary" support is not a dichotomy, but a continuum of services appropriately sited. For example, an individual laboratory might support its own local area network (LAN), the academic department that sponsors the laboratory might handle LAN upgrades, a set of departments might share a LAN expert, and the central computing group might make available a network engineer. In our model, the frontline support person--not the user--navigates these complexities.

The fourth chart, below, describes a new force in the overall structure, cross-University process teams.

6. Next steps

Transition to Penn's new computing structure is well underway. Seven pilots, described in the next section, are testing the new model and creating reality on the ground. Progress, in brief:

• "Service bureaus," or small businesses, already exist at Penn; two pilots focused on frontline support-for-hire and facilities management-for-hire are investigating the market, writing formal business plans, and seeking business opportunities.
• The pilot to support undergraduates in residence has proven successful in Van Pelt College House and is exploring ways to scale up to all first-year and college houses by Sept. of 1997.
• As a first step toward running the network as a regulated utility, a proto "public utility commission" is rationalizing the PennNet central services fee, which covers network infrastructure.
• ISC is in the midst of a major internal restructuring that includes increased attention to services for local providers of computing, increased attention to standards and emerging technology, selling services where it makes sense, transitioning away from general frontline support except on a contract basis, laying operational groundwork for running the network as a public utility, and serving as catalyst for process teams.
• Penn is putting in place infrastructure to link participating help desks across campus. With this software, called "Apriori," dispersed help desks can share problems and solutions.
• Residential Living, the Library, and four schools have each replaced at least a quarter of their public lab machines, taking advantage of the matching-fund program launched in June of 1996.
• Process teams are becoming a new way of doing things at Penn; the Provost and others welcome the funding guidelines proposed here.
  

The Steering Group is consulting broadly to see if the funding model presented here is workable at Penn. Visits to Deans, for example, and to Penn's senior advisory groups are underway. Pilot teams and the Steering Group continue to work out the implications of the new framework. Benchmarking (begun in the fall of 1995 and now an ongoing, though less intense, program) is a key source of ideas and contacts.

7. Pilot projects--nutshell descriptions

Seven pilots are testing aspects of Penn's new model for computing services. The Implementation Steering Group (Appendix B) guides and integrates the pilots.

1. New kinds of learning spaces (process team): Begin creating at Penn a range of technology-based "learning spaces" such as classroom/lab hybrids. Build on the success of the Provost's Classroom Committee; seek outside funds.

Team leaders:
James O'Donnell (ISC/Arts & Sciences)
John Smolen (University Life)
Donna Milici (ISC)

2. Support-in-residence for students (process team; frontline support): Pilot the viability of moving to residence-based frontline computing support for undergraduates; lay groundwork for transition. Begin with one or two residential units and closely coordinate with broader efforts to restructure student services across the University.

Team leaders:
Al Filreis (Arts & Sciences)
Larry Moneta (University Life)

3. Network as a public utility (service-level agreements; public utility commission): As a first step toward running Penn's network as a regulated public utility, rationalize the "central services fee," which covers network infrastructure. Determine the appropriate services, service levels, and fee and explore more strategic approaches to billing. Establish a pilot "public utility commission," or governing board, to make these decisions in consultation with the Penn community.

Team leaders:
Ira Winston (Arts & Sciences/Engineering)
Gerry McCartney (Wharton)
Mike Palladino (ISC)

4. Link help desks across campus (process team; frontline support): Link help desks across campus by sharing software that tracks problems and solutions. Set common standards and practices for using the software. Arts and Sciences and ISC will initially deploy the software; The Library and the Engineering and Medical Schools will help shape the implementation.

Team leaders:
Katie McGee (Arts & Sciences)
Mike Kearney (ISC)

5. Frontline support-for-hire (service bureau; frontline support): Review and adapt for broader implementation ISC's distributed staffing program, in which local units contract with ISC to locate computing support staff on-site. Explore market needs and develop a formal business plan.

Team leaders:
Mike Provost (Veterinary Medicine)
Don Montabana (ISC)

6. Services for local providers of computing (secondary services): Begin putting in place a coherent and effective set of services directed to local providers of computing. Determine organizational structures to deliver those services. Define performance measures, service-level agreements, and formal ways to get customer feedback.

Team leaders:
Mark Aseltine (Fine Arts)
Mike Kearney (ISC)

7. Facilities management-for-hire (service bureau): Improve, expand, and formalize ISC's program of facilities management, in which ISC provides technical and operational support for computer systems that belong to clients. Treat the recent contract with the School of Dental Medicine as a pilot to learn more about running this service as a business.

Team leader:
James Galbally (Dental Medicine)

8. Challenges

The restructuring of computing at Penn has not provided naive solutions to complex problems nor has it wished them away. It has created instead a framework in which rights and responsibilities can be negotiated rationally, openly, and fairly.

For consumers of computing services, the new model's great strength is frontline support at the local level. Frontline support close to users of computing also exemplifies the challenges that face the model. It will take hard work to make help easy for users. And frontline support implies secondary services that can be drawn on by local providers when needed. The level of those secondary services will, in part, determine the resources required to provide frontline support. Tensions will result. Units that apply greater than average resources will feel they are paying through allocated costs for central services they don't need. Those that dedicate fewer resources will find that ISC is no longer a provider of last resort and users may suffer.

Success depends especially on two aspects of Penn's social contract for computing. The first is the ready acceptance of responsibility by individual units for providing or purchasing frontline support for their members. The second is the close coordination of services across the University so that secondary support from the central group meshes well with support provided by schools and units and represents a reasonable allocated cost to Penn.

Creating a workable structure will not be easy. By establishing the terms of a social contract for computing, however, Penn has begun to put the hardest task behind it. It will now be possible to negotiate funding with a new clarity and devote our energies to designing the most responsive--and responsible--support structure for the people who use it.

Appendix A: Task Force to Restructure Computing Services across Penn

In the fall of 1995, Penn's Provost and Executive Vice President appointed a University-wide task force to make computing easier and more cost-effective for those who use it. Our charge was to design a new structure for organizing, staffing, and funding computing services across Penn.

Sponsors:	Stanley Chodorow (Provost) John Fry (Executive Vice President)
Chairs:	Peter C. Patton (ISC) James O'Donnell (ISC/Arts & Sciences)
Project Mgr:	Linda May (ISC)
Task force:	Noam Arzt (ISC) Carl Abramson (ISC) Noam Arzt (ISC) Mark Aseltine (Fine Arts) Robin Beck (ISC) Eric Clemons (Wharton) Wilson Dillaway (Library) Mike Eleey (ISC) Al Filreis (Arts & Sciences) Jim Galbally (Dental) Ben Goldstein (Arts & Sciences) Janet Gordon (EVP) Pat Harker (Engineering) Bob Hollebeek (Arts & Sciences) Liz Kelly (Law) Michael Klein (Arts & Sciences) Mark Liberman (Arts & Sciences) Linda May (ISC) Donna Milici (ISC) Steve Murray (EVP) Gerry McCartney (Wharton) Katie McGee (Arts & Sciences) Bob Pallone (Development) Warren Seider (Engineering) Susan Shaman (Provost's Office) Al Shar (Medicine) John Smolen (University Life) Lyle Ungar (Engineering) Dan Updegrove (ISC) Frank Warner (Arts & Sciences) Ira Winston (Engineering)
Models Workgroup:	Mike Eleey (ISC), captain Gerry McCartney (Wharton), captain Noam Arzt (ISC) Wilson Dillaway (Library) Jim Galbally (Dental) Bonnie Gibson (ISC) Liz Kelly (Law) Mark Liberman (Arts & Sciences) George McKenna (ISC) Bob Pallone (Development) Al Shar (Medicine)
Communication Workgroup:	Al Filreis (Arts & Sciences), captain Katie McGee (Arts & Sciences), captain Ira Winston (Engineering), captain Helen Anderson (Engineering) Mark Aseltine (Fine Arts) Kristine Briggs (EVP) Randall Couch (ISC) Edda Katz (ISC) Teresa Leo (ISC) Jill Maser (EVP) Don Montabana (ISC)
Benchmarking Workgroup:	Donna Milici (ISC), captain Ben Goldstein (Arts & Sciences), captain Pat Adams (ISC) Chris Cieri (Law) Mike Guilfoyle (ISC) Joe Harris (ISC) Mike Palladino (ISC) Nancy Rauch (ISC) Susan Shaman (Provost's Office) Debbie Sokalczuk (Arts & Sciences) John Yates (Arts & Sciences)
Center for Applied Research:	Lynn Oppenheim Mario Moussa

Appendix B: Implementation Steering Group

In the spring of 1996, Penn's Provost and Executive Vice President named an Implementation Steering Group to guide pilot testing of Penn's new model for organizing, staffing and funding computing services across the University.

Sponsors:	Stanley Chodorow (Provost) John Fry (Executive Vice President)
Chair:	James O'Donnell (ISC/Arts & Sciences)
Project Mgr:	Linda May (ISC)
Members:	Noam Arzt (ISC) Robin Beck (ISC) Wilson Dillaway (Library) Mike Eleey (ISC) Al Filreis (Arts & Sciences) James Galbally (Dental Medicine) Bonnie Gibson (Provost's Office) Elizabeth Kelly (Law) Mark Liberman (Arts & Sciences) Gerry McCartney (Wharton) Susan Shaman (Provost's Office) Barry Stupine (Veterinary Medicine) Al Shar (Medicine) Ira Winston (Arts & Sciences/Engineering) Ira Schwartz, "of counsel" (Social Work)
Funding Workgroup:	Bonnie Gibson, chair (Provost's Office) Fran Seidita (Budget Office) James Galbally (Dental Medicine) Patrick Burke (Engineering) Carolynne Martin (University Life)
Benchmarking Workgroup:	Donna Milici, chair (ISC) Mike Palladino (ISC) Mike Guilfoyle (ISC) John Yates (Arts & Sciencess) Pat Adams (ISC) Nancy Rauch (ISC)
Center for Applied Research:	Lynn Oppenheim Mario Moussa

Appendix C: Frontline support: Choices and responsibilities

This appendix organizes information published earlier or found elsewhere in the document. The appendix is for the convenience of deans and others who wish to understand their choices and responsibilities for frontline support within the new model.

Local computing "home." The computer user--faculty, student, or staff--is at the center of Penn's new model for computing services. Each user has a local computing "home" and takes all computing questions there. All frontline computing support takes place at the local level, as close to the user as possible. (This includes first-line support of the desktop computer and its relationship to the network, of mainstream productivity software, and of specialized software commonly used by that group.) Beyond this circle of frontline support are expanding circles of secondary support, at both the local and central levels. But the map of services is irrelevant to recipients; the frontline support person navigates that landscape for them.

For faculty and students, the local computing "home" is designated and supported by their school. For staff, this home is designated and supported by the school or administrative division in which they work.

Different homes have different resources. Level and type of resources are decided by the school or unit with which the user is affiliated. (Schools or units that delegate budget responsibilities to departments may, of course, delegate decisions about computing services as well.) At the same time, the task force urges that guidelines for basic frontline support levels be set and that Penn institutionalize ways to keep these levels moving up.

Funding. Schools and administrative units are responsible for funding frontline support for their communities. As with other budgeting decisions, Deans, department heads, or unit managers can decide how to trade off computing against other needs. To help evaluate options, Appendix D documents three "building blocks" of funding: support ratios, median salaries for different kinds of computing staff, and costs of equipping a staff member.

Staffing. Schools or units can provide frontline support themselves, buy it elsewhere, or join with others to provide it more efficiently. A unit can buy on-site support from ISC, for example; Appendix E describes small businesses such as this one at Penn. And the residential pilot (Appendix F), for example, is testing what may be a more efficient way to deliver frontline support to undergraduates.

Training. Schools or units may choose to train their frontline providers and end-users to different levels of competence, and they may choose to provide this training themselves or buy it inside or outside the University.

Secondary support. Secondary services, as described in Section 5, complement and back up frontline support. Many secondary services are provided by the school or administrative division. The central computing group concentrates on core administrative systems, data administration and security, network infrastructure, standards, site licensing, and services targeted specifically to providers of frontline computing support. For the computer user, the frontline support provider is the link to these services.

In practice, the distinction of frontline and secondary support is not a dichotomy, but a continuum of services appropriately sited. For example, an individual laboratory might support its own local area network (LAN), the academic department that sponsors the laboratory might handle LAN upgrades, a set of departments might share a LAN expert, and the central computing group might make available a network engineer. In our model, the frontline support person--not the user--navigates these complexities.

Principles. Because frontline support is key to our model, we have described the ideal, our target, in some detail below.

Frontline support is accessible.

The computer user knows the frontline support provider and has easy access. Frontline providers are physically located with their clients if possible. If clients are remote or scattered, the frontline provider is accessible by email, telephone, or pager.

Frontline support owns its problems.

Frontline providers "own" the problems encountered by their users (for supported products and within the support limits set by the unit). A working principle is that a provider never says, "I can't help you, " but says instead, "I'll find the answer or find someone who can."

Problems are documented and structured.

The frontline provider works with users to structure their problems. This helps the provider understand the problem, and allows problems referred elsewhere to move more effectively through the support system.

Frontline providers have content knowledge.

Frontline providers know the operating systems of their users' desktop computers and how to link the desktop systems to the network. They know mainstream productivity software, as well as the specialized software commonly used by their clients. (Special arrangements might be needed to support clients who are more technically sophisticated than their frontline provider.)

The client base is well defined.

Frontline providers are not only empowered, but required, to tell those who fall outside their client base to go elsewhere for support. To the extent possible, providers know where to direct those people.

Campus units that choose not to provide frontline support to their members should expect to pay a premium for their members' access to second- and third-tier support elsewhere in the institution. This is fair because the unsupported user is likely to bring small problems to expensive places and may not have exhausted cheaper remedies.

Problem escalation and referrals are handled smoothly.

Clients have paths to management when their problems are not well handled. Clients are, directed, however, back to the frontline provider if they attempt to work around their immediate support structure and access second- or third-tier support without prior arrangement.

Mechanisms are in place to refer problems that a frontline provider alone cannot solve. Sources of second- and third-tier support are clear, and means of access are well defined.

Frontline providers share information with each other.

Frontline providers know the activities and problems of their clients--and often learn of things outside their own domain. Both kinds of information are systematically shared across the broader support system.

Appendix D: Building blocks for budgeting

In keeping with the model's emphasis on local control, three "building blocks" for budgeting are documented here: support ratios, salaries for different kinds of computing staff, and costs of equipping a staff member. Penn's schools and units can combine these building blocks in ways that make sense for the unit.

Building block: Support ratios. What is the appropriate number of end users per support staffer? The Gartner Group, a technology consulting firm, recommends 75/1. Penn, however, might be able to get by with a general ratio of more users per staff member, since student support can help reduce the need for professionals. Faculty, with their specialized research and teaching needs, will need more support than administrators, who will need more support than students.

Building block: Staff salaries. The table below lists mid-point salaries for different types of computing staff at Penn. These figures can be used to help estimate the costs of support.

Median salaries for computing staff at Penn (FY'97)
Title	Job Grade	Median Salary for Grade	Median Salary & Benefits for Grade
Work-Study Student @35% Work-Study Supplement		$2.22/hr. $2-6/hr.	$2.22/hr. $2-6/hr.
Part-Time Student		$6-12/hr.	$6-12/hr.
Drexel Co-op		$9-13/hr.	$10-14/hr.
Office Systems Asst.	G10	$25,713	$33,710
Office Systems Coordinator	G11	$27,866	$36,530
Office Systems Administrator	P02	$29,098	$38,150
Information Systems Specialist	P03	$31,982	$41,930
Office Systems Administrator II	"	"	"
Help Desk Analyst	P04	$35,123	$46,050
Info. Mgmt. Specialist I	"	"	"
Info Systems Specialist II	P05	$38,677	$50,700
Info Management Specialist II	P06	$42,591	$55,840
Senior Help Desk Analyst	"	"	"
Help Desk Coordinator	"	"	"
Computer Technology Spec. II	"	"	"
Info. Systems Specialist III	P07	$46,814	$61,375
LAN Specialist	"	"	"
Computer Technology Spec. III	"	"	"
Info Systems Specialist IV	P08	$52,015	$68,200
Managers/directors	P09	$57,217	$75,000

Building block: Equipping a staff member. The table below estimates the annual cost of equipping a staff member.

Equipping a staff member
Type of expense	Annual $	Source
Computer (3-year amortization)	$1,000 Mac or $833 Windows	Campus standard
Software	$700	Current supported packages (estimated)
Ethernet connection (10-base T)	$267
One conference or training course/year	$1,800- $3,000	Local courses could reduce costs
Telephone, supplies, space	varies by setup and location	.

Appendix E: Selling services where markets exist

Penn's new model encourages selling services where markets exist. The task force has been calling these small businesses "service bureaus." Service bureaus can help defray the cost of a unit's strategic investments, make special expertise more widely available, and expose services to the discipline of the market. Service bureaus are already found at Penn; Wharton Reprographics, ISC's contract support-on-site, and ISC's contract facilities management are three examples.

PROVIDERS AND CUSTOMERS

Providers. Any school or unit may set up a service bureau in Penn's evolving economy. The most likely providers are units that make large capital investments that produce excess capacity. For example, a school might buy expensive multimedia equipment to meet its teaching needs and then hire out related expertise and support to other units.

Customers. Customers will range from schools and units to workgroups and individual faculty members. The ability to pay for services will depend on unit operating budgets, individual grants, and any available special funds. Explicit contracts--service-level agreements--are key to clarifying customers' expectations for service and support.

The voice of the customer. From the customer's point of view, service bureaus are worth using only if they are better, cheaper, or easier than the alternatives. A service bureau will know it is successful if customers show up and continue to show up. An open question is how much time and marketing to give a start-up service bureau before deciding to pull the plug. Successful service bureaus will put effort into market research to anticipate needs and trends.

PRICING

Full cost. Pricing is a business and policy decision that service bureaus will face. Service bureaus might opt to charge fully burdened costs that recover management, marketing, billing, and other overhead expenses, including future-oriented costs such as investments in new technology. Unlike a free-standing business, they would add no profit margin to the cost.

Subsidized cost. Depending on market demand and other constraints, service bureaus might choose to recover through direct charges less than the full cost of doing business. A school might charge below full cost, for example, to get customers that defray the cost of an underused capital asset. Or ISC might charge customers only marginal costs where Penn has an interest in encouraging the use of a service; this partially subsidizes the operation through allocated funds. (With ISC's contract support-on-site, for example, Penn's interest lies in offering schools alternatives to ramping up their own computing support staffs.) The Steering Group notes, however, that such subsidies should not be used as a way of transferring funds from one school to another--that is, they may be applied only to services of general interest and use--not to services with narrow appeal.

LIMITS AND CONSTRAINTS

Legal guidelines. Service bureaus ("service centers" in Penn's chart of accounts) are subject to Federal A-21 guidelines for reporting time and effort. A very specific justification of all charges must be approved by the Federal compliance unit of the Comptroller's Office. The most informal service bureau (say, a department selling expertise on the margin) might operate outside these guidelines. Formal service bureaus with many customers and with both direct and indirect costs, on the other hand, will need to meet the Federal guidelines--particularly if Federal grants are to be charged.

Problems of scale. Like any small business, service bureaus that succeed in growing may run into problems of scale. A particular resource may be the limiting factor. For example, ISC's contract facilities management service could run out of floor space in the machine room. Or a service bureau might be limited by its ability to hire and train additional staff in time to meet demand. Similarly, adding staff may require additional management strength that is either unavailable or too expensive.

What business are we in? The comparison with small businesses goes only so far. Units are committed to their core mission and are unlikely to invest in ventures in hopes of generating new revenue sources or whole new lines of business. Service bureaus are likely to remain a fairly small part of Penn's overall economy. They are an important Trojan horse, however, exposing the institution to the discipline of the market and the pressure to please the customer.

Appendix F: Proposal to support students where they live

The framework seeks innovative ways to deliver computing support as close to the recipient as possible. One pilot, for example, is testing the idea of supporting undergraduates in residence, drawing substantially on students themselves:

It just makes good intellectual sense at a residential university. It empowers students to help students, and to see themselves formally in the business of teaching and advising in an area where they have largely untapped expertise. It strengthens the self-sufficiency of a collegiate community.

The proposal is in the early pilot stage, testing the concept at Van Pelt College House. The proposal calls at minimum for students living in residence to get their computing support in residence. (Currently almost all first- and second-year students and a fair number of upperclass students live in the dorms.) As Penn's emerging collegiate system takes shape, support might extend to all undergraduates, through their affiliation with a residential college (the Provost's 21st Century Project).

With such a moving target, the pilot team is seeking an interim strategy at the same time it takes concrete steps toward a long-term solution.

Support for students today. Most undergraduates are not directly supported by their schools today. They get help with computing, inconsistently, by virtue of their association with some courses, some special projects, and some computer labs (in the schools, Library, and residences). Many undergraduates use ISC's Computing Resource Center and First Call hotline, which, under Penn's new model, are being transitioned away from general frontline support to the Penn community.

Leverage. The proposal makes leverage a funding strategy. It makes use of work/study students, graduate fellows, and faculty masters already in the residences. It organizes them to respond to most requests for help and refer a few problems up the line to computing professionals. If the work/study students are "electronic paramedics," the graduate fellows are "nurse practitioners," and the computing professionals are "doctors."

Most of the staff and most of the funding are already in place. The proposal adds a few computing professionals to the local ecology (an estimated four FTE professionals to serve an eventual eight collegiate clusters). Funding for the professional staff will be at a level set in consultation with the Council of Undergraduate Deans and provided by allocated cost or subvention (TBD).

Links to larger efforts. The pilot is linked to larger efforts such as the current restructuring of student services across Penn; many kinds of services (counseling, academic advising, etc.) are likely to be delivered in residence. It also builds on the evolving residential college system of the Provost's 21st Century Project. In some ways, the pilot is shaping both those efforts, with computing as the perfect "late night" activity to help people think concretely about the benefits and possibilities of delivering services in residence.

Details. Details of the pilot can be found in its Web site (http://dept.english.upenn.edu/Rescomp/). Schools such as Stanford and Northwestern have active programs of support in residence.

Appendix G: Technology refreshment of public labs:
A matching-grant program

Standards help Penn save money and make it easier for people to work together. Financial incentives for standards are often the most effective ones. The matching-fund program described here helps public labs replace their desktop computers on a four-year cycle. The program, designed by the "New Learning Spaces" pilot, was launched in June of 1996.

Terms. The program offers a 1:2 match ($1 of ISC funds for each $2 of school, Library, or residence hall funds). Labs that accept matching funds agree to:

• Remain public.
• Adhere to Penn's desktop hardware standards for new purchases. Commit to a four-year replacement cycle.
• Help develop annual recommendations for productivity and communications software (eg, ResNet suite) and support of software for large undergraduate initiatives (eg, Maple)--and comply with those recommendations as a minimum standard.
• Install virus protection software and hardware security.
• Enforce University policies and federal laws (eg, ethical behavior and copyright).
• Participate in the Lab Administrator Special Interest Group.
• Describe how funds were spent in an annual report to ISC.

The matching component is funded for the next four years. Penn has about 540 public desktop computers. A quarter of them can be replaced each year for an annual investment of about $340,000 ($113,000 of which is ISC's matching portion). Each school or group can expect that a quarter of its public computers will be eligible for matching funds in each of the next four years. If need exceeds the pool, a priority scheme will be developed.

The current situation. Organizations vary in their current approach. Some groups budget for a two-year replacement cycle, while others have no budget for equipment replacement. ISC has played no role before now in funding for public labs. Commonwealth and vendor equipment grant programs ended several years ago.

Appendix H: Services for local providers: Strategies for funding

Services specifically for local providers of computing add strength to the campus-wide system of computing support. These services are aimed at creating infrastructure for support provided locally. The emphasis is on helping solve problems locally, or, better yet, keeping problems from happening in the first place. The services are meant to complement and enable frontline support, not to substitute for it. The services encourage standards; the availability of good second-tier support for campus-standard products should serve as an incentive for units to adopt those standards.

Clients. The clients of these services are local providers, campus-wide process teams, and other information technology professionals. End users are not generally direct clients.

Links. The people who provide these services will almost always have other operational duties as well. They are experts because of those other responsibilities. Synergy with campus-wide development of standards is particularly strong.

Status. As local providers take on full responsibility for frontline support, they themselves will need more support. ISC, in turn, will devote more effort to services for local providers as it moves away from frontline support. A pilot team is working with the Penn community to reconceive ISC's portfolio of services for local providers. The team will inventory existing services, assess client needs and priorities, identify best practices elsewhere, and recommend organizational and funding strategies. Implementation is expected in the spring of 1997.

A framing typology. The pilot team is looking for the right mix of approaches from among those outlined below.

Principles. The team is guided by two sets of principles, below.

Service delivery

Funding

Support local providers. Map what's there. Link authority and responsibility. Avoid referral and escalation. Keep it simple. Encourage the informal structure. Track usage. Promote standards. Identify tradeoffs. Expertise arises from actions. Communication is critical.

Leverage existing resources. Allocated funds for central group that coordinates, but is not sole provider. Fund and staff support for local providers as part of the base process or service. Fund services and teams (not units) where possible. Allocated funds where integrity of University data and systems is at stake, standards are encouraged, or for the good of the whole. Service bureaus where markets exist for custom or specialized. OK to mix allocated and direct charges.