Penn Computing
Computing Menu Computing A-Z
Computing Home Information Systems & Computing Penn


Services for Providers Convention - 1 October 1997

Network Operations


Value: Requirement

Local providers expect ISC to take care of the network's standards and keep up with emerging technology. They would like, however, to be kept informed via an e-mail list rather than the web, when technology changes will affect their users and their users' budgets. For major changes, they should get a head's up at least 6 months in advance, with reminders going out close to the implementation date. This includes but is not limited to when services are being phased out and obsolescence is being figured into the standards.

Along with alerting local providers of coming changes, ISC should alert them when new technologies are being considered and tested, and invite interested parties to participate in testing and in pilot groups. Better communication channels are needed so that when a local provider indicates an interest in an emerging technology, her or his interest gets forwarded to the right person.

New network technologies should be presented in SUG meetings, or in local providers' workshops (see TRAINING below).


Value: Priority and Emergency

This topic emerged out of the predominant discussion on Communication (see below). The local providers need to have direct input into the prioritizing process. Also, key areas need to be identified that have a higher priority, so that when a call comes in, ISC knows immediately that this is an area that needs immediate attention. Not all wall plates are equal: some impact more people or more critical functions. (The example given in our session was the library's circulation desk.) The person taking down the information for the problem ticket needs to know the "level" of the priority. It was agreed for most situations, the prioritizing should follow the convention:

  • Service Connection
  • Whole building
  • Whole classroom or office
  • "important desktop's"

but this can only serve as a framework and cannot replace good personal ISC-customer interaction in determining the nature of the emergency.

The more anonymous the communication between the local providers and the ISC technicians, the more likely a problem is to get mis-prioritized. The person calling in the problem to First Call will feel like she or he needs to sound urgent, in an attempt to get feedback as soon as possible. The technician responding to the call may or may not know the local issues and urgency of the problem, and if they don't talk directly to the provider, may de-escalate or escalate inappropriately.

The local provider database that is being created should contain information about the local topology and the priority of certain areas, so that when calls are logged they can be looked up in the database to determine the extent of the problem and technicians can get a better idea of the nature of the emergency. The database should also indicate level or categories of local services providers. It should be able to flag which local provider is the designated "network" person for that area. If the person making the First Call is not the designated network person, the person responding to the call should deal with the original caller, but also an effort should be made to coordinate with the designated network person for that area.


Value: Full Service (and Paid?)

When renovations and new construction happen on campus, ISC Networking needs to know far in advance. They would like to rely on local service providers to alert them. They should be involved in the planning and consultation of networking wherever building changes are happening. Better communication between ISC Networking and Building administrators (via Physical Plant?) is needed. Building administrators need to be kept aware of network issues, and they need "custom" information pre-sorted for them by ISC... building-by-building (# of 10 base T wallplates, where is the coax wiring, why daisy chaining won't work for them, etc.)


Value: both Informal and Formal

The majority of the time in this group's break-out session was spent on this topic. Again and again it was pointed out that there is a lack of a good customer service interface between the technicians and the local providers. There was a strong consensus that First Call does not meet their needs, and they will circumvent the model and go directly to someone they know whenever they can. This is because they have experienced a lack of response, or they simply are kept in the dark as to where their problem is in the queue or they were left out of the loop and the technician responding to the problem ending up dealing with someone else. Several examples were cited where closer coordination is needed: between the ISC rep taking the problem information, and the ISC technician assigned to work on the problem, and the local service provider. It was agreed that keeping the local provider informed of progress and calling back as soon as possible was a very high priority. (So high, in fact, that they felt quick feedback/updates was even more important than the time it might take to resolve the problem -- though they didn't want to see resolution time increase, still, it was more helpful to know right away that their call had been received, and approximately how long it might take to get attention.) They need a phone call to know the ticket has been created, and a call to learn when it will be worked on, and again a call before the technician actually comes out to their site, so they can be sure to be available. Too many interruptions and phone calls/e-mail was not considered a problem. More communication regarding their problem is always better.

It was also agreed that personal interaction was much preferred to more anonymous formal channels: the local provider needs to know for certain that their problem has been recorded, with their name on it, and that the responding technician will be dealing with them and no one else (unless the local provider has designated a proxy). Dealing with a designated "customer service representative" for their school or area, someone who knows them and knows the specific issues related to their area, would be much preferred to leaving information with a student worker or filling out a job ticket on a web form.

In some cases it might make sense to given some of the local providers access to the A PRIORI database, for them to enter their own problem tickets. But this would not eliminate the need for better customer relations with those providers.

Both the local providers and the ISC network people need to have a clearer understanding of the procedures, and know what is expected of them. Once a local provider is "trained" in network troubleshooting procedures, they should be considered the key network contact for that area (see comments above regarding the local provider database in "PROBLEM SOLVING").

A listserv list of local services providers should be developed, and perhaps split into sub-groups, so that network issues go to designated local network support people.


Value: Full Service

In general, local providers find the network to be well maintained. See the section above on COMMUNICATION for discussion re: when local problems occur.

There was interest around the table in the modem pool maintenance, and also in the faster ethernet that's currently under evaluation and what that will mean to daily operations.

After-hours coverage: perhaps Penn could have a different fee scale for those centers or areas that desire more than the standard office-hours coverage for network problems -- a sort-of "extended contract". The local provider to be contacted after-hours would have to be identified, and there would have to be ISC staff on-call for people with such extended contracts.


Value: Mostly In-house delivery, some Coordination and perhaps some Resource Library

Service providers feel relatively comfortable with supporting desktop, but, as one participant put it, "my knowledge ceases when it gets to the wallplate." They would like to be given access to any resources that might assist them to better understand networking, and periodic ISC-held workshops in specific networking aspects. (Several times the presentation by Deke to SUG was held up as a model for what we need to do more.) Suggested topics: "How does TCP/IP work?"

Local providers would like access to the A PRIORI knowledge base. A list of the "top questions and answers" regarding networking (for example, "TOP 10 Dial-in problems") could be published on the web or distributed to a mailing list.


Value: Tech Notes and Finished Documents

FAQs on the web would be helpful. Local topology maps are needed for each building.


Value: Finished Documents

Site-specific documentation is needed: local topology information and answers to local questions: "What do *our* plates connect to?" "Where are the ports located in this building, and what information do I need to get off of the wall plate before I make a service call?"


Not discussed


Value: Services Provider and Designated Provider

When a person is hired into an IT local support position at Penn, part of their Human Resources training should be to identify them, and let know that they are a local service provider and part of ISC's network of LSPs. They need to be made aware of SUG and other resources available to them, and what their coordination responsibilities with ISC Networking are.

To some extent, schools can identify who the local providers are, but this information has been found to be incomplete. The database of local service providers needs to be kept up to date, needs to categorize providers, and needs to be on the web so everyone in the Penn community can be aware of who is who and alert ISC when it needs updating.


Value: Facilitation, Coordination, and Owner

Some schools and centers do all their own internal networking in their buildings, and some rely completely on ISC.


Value: Information Source

For non-ISC network maintenance and operations, local providers could use information shared from ISC, such as "who of our users still use SlIP?" "Whose PAS ID doesn't work?" and "Here are the people who have many multiple simultaneous logons."

Information collected in the A PRIORI database could be analyzed and disseminated to pre-specified local network services providers.


Value: Deliver

Perhaps instead of having a document on ISC Networking's service role at Penn, there should be a document that functions more like a contract between the ISC and the schools, with specified offerings for specified prices and guaranteed services. Schools and centers could decide if they could afford extended services, and both sides would be aware of what was expected of them.


Value: Deliver

The local providers role was discussed in the context of the topics above. In addition:

There was an interest expressed in secure shell encryption for online information. Online wiring requests (via a web form) would be nice.


Value: None


Value: Immediate

Local Services Pilot   Principles   Approaches   Overview   Members   

Information Systems and Computing
University of Pennsylvania
Comments & Questions

University of Pennsylvania Penn Computing University of Pennsylvania Information Systems & Computing (ISC)
Information Systems and Computing, University of Pennsylvania