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


Services for Providers Convention - 1 October 1997

General Ledger

Standards, Compatibility, and Emerging Technology

Value: Requirement

One reason for problems with FinMIS is that the Oracle Government Financials (OGF) product lacks many features, such as a GUI, the ability to set preferences, and so on. However, the product was the best we could do at the time, and we could not delay implementation because we needed to meet new federal regulations. The uniform client is tedious to use, but helped lessen support call volume. We will evaluate the next OGF release in December, 1997. We want better EDI, and a better way to meet our security specifications (which changed after we had decided to use OGF). We will also re-evaluate the reporting strategy. We anticipate the new approach will be browser-based, but security is an issue.

Printer standards were hard to meet. It was hard to get the printers out there due to logistics, testing, cost, and late timing. We need a standard method (such as a standard terminal emulator) to access central systems. For example, a user may find that once he has changed his desktop set up and accessed FinMIS successfully, he's unable to access Payroll.

On the application level, users should *not* be able to continue to use funds that have expired. Transactions using expired funds are usually entered via feeder files (such as from the mailing system), or involve mapping old to new accounts (as is done for Payroll transactions).

Payroll will be retro-fitted in fiscal year 1998 to use FinMIS accounts.

Consulting and Planning Services

Value: Not applicable

Problem Solving (Escalation)

Value: Referral

Under the current FinMIS Support model, local providers of support are expected to report technical problems to their school/center contacts. If those contacts cannot resolve the technical problem, they call the University Support Hotline (staffed by personnel from the Comptroller's and Acquisition Services offices). If the Hotline staff cannot resolve the technical problem, they forward it to ISC FinMIS Escalation staff.

(Business problems are routed from the end user, to the school/center contact, to the Hotline, to the Division of Finance.)

What really happens is that local providers of IT support call their school/center contact (who calls the Division of Finance) when business problems are at issue. (This is difficult because the school/center contact is often not available when hot questions arise. There are no back-ups for the school/center contacts.)

Local providers of IT support often call other local IT support providers, or FirstCall, when technical problems are at issue. (However, at SAS, if the desktop equipment is working, so that it appears that the problem is with the FinMIS server or application, the problem is referred to the school/center contact). One local IT support provider called FirstCall, and the FirstCall staff member was "clueless" about support for FinMIS printers. Now this provider knows to call Steve Fausey. (This appears to be a broken ISC communication link.) FirstCall staff need to be more aware of central administrative systems.

We greatly under-estimated the load on the school/center contacts and the load on the hotline staff. We need to recognize their service, given in addition to their performance of the tasks in their job descriptions. We plan to bring in a consultant at the end of October, 1997 to look at the load on the school/center contacts and the load on the hotline staff, and to make recommendations on how best to handle the load.

The support hotline needs to point people to the right contacts in the schools and centers. Perhaps there could be local school/center experts on a given service who would be part of the escalation chain.


Value: Formal

The IT SIG at roll out time (6 to 8 weeks ahead) was useful (though, due to intra-school communication problems, not all local IT support providers knew about the SIG). Next time, we should start earlier, and involve the local IT support providers in testing. An earlier warning of desktop and printer requirements would have helped, especially for big schools. Also, an earlier warning of training would have helped the local providers of IT support who had to prepare the training lab equipment.

The SIG should meet *throughout* the roll out, to deal with ongoing or new problems.

There needed to be clearer communication of training (train-the-trainer) so trainers could plan better.

There was too much work for these people--they had their real jobs, plus their work as school/center contacts, plus their work as trainers.

We need to be sensitive to timing roll-outs. The roll-out of Pillar on top of FinMIS was very stressful.

The SAS listserv for FinMIS worked well.

However, in some cases (such as the Med. School), intra-school/center communication does not work well.

Different schools and centers have different levels of centralization of IT support. There are two audiences: local providers for a few end users, and local providers supporting more end users with other local providers under them. We need to make sure both audiences are kept informed. We need a better list of local IT support providers so people don't fall through the cracks--we should not rely o n school/center trickle-down of information. Could we use the school/center lists of local IT support providers? What if there is more than one local IT support provider per department? There is a problem with identifying such people at the Med. School.

Communicating known problems to local IT support providers is vital. For example, when security issues with printers were discovered by one local provider, other local providers needed to be warned. Listservs are good, but VoiceMail trees are better if router or network problems arise. Beeper numbers should be included in the tree.

It's important to communicate to both the business support and the local IT support providers. Beware of school/center reorganizations and staff changes!

Isobel, David, and Pam did not attend the live FAQ sessions, but they got the sense that they turned into gripe sessions.

We need a generic place to call if we run into problems with the Web.

Currently, if FinMIS is down, E-mail is sent to users, a message appears on the menu, and other means are used to spread the word, as well. However, the users must check their E-mail, etc., to see these alerts. People don't read the screens. Would it help to have the desktop machine beep when an alert is sent? Voice Mail might get through to users better, even if Voice Mail is sent only to local providers of IT support, because they are the ones the end users will call.

When new things (such as telnet clients) are tested, it's important that the information be disseminated.

Documentation or reports on calls to the hotline would be useful.


Value: ISC provides in full

Someone asked whether the print queue problem will ease?

The problem will be addressed as we review the reporting strategy in December. For now, users can use the extracts as a work-around.

Users should be warned of big extracts that may blow out on time or space when downloaded.

We need to keep remote users in mind. Some users (such as those in Penn Tower) still use modems, because they have no PennNet connections. The one hour limit on the modem pool is a problem, and the ISP cannot now get people to secure applications. A Web-based system would make remote users' lives easier.

It can be a surprisingly long process to add a new FinMIS departmental printer. This can take 3 to 5 months for the Med. School, but only 3 to 5 days for others. The printer set up is great, and Steve Fausey is very responsive.

Things to think about for next time: what equipment will the users need? What browser--any on the Penn InTouch bounded list? What *version* of the browser? What about speed issues (response times and performance)? There are complaints about this now--won't a Web-based system be even slower? More than 5 seconds is considered too slow a response time. A browser is more platform independent.

But is a thin client speedier than a browser-based system? The server side may be the slow poke in a browser-based system. And would a thin client's requirement for middleware (e.g., SQL*Net, not to mention the OpenTransport problem) make a thin client more complex and therefore more breakable? Another trade-off is that Netscape may crash, but telnet doesn't. How much memory will the users need? What about graphics memory? Will the system be supported on older equipment, or will the users need to upgrade? What about Macintoshes? Does the navigation between screens work well (especially going back to earlier screens)? We should avoid using frames--they slow things down. We should keep it simple (no Penn shields in the background!). Helper apps (such as one to download straight into Excel) would make the system more complex, easier to break, and harder to support. Also, the users would require more training.


Value: In-House Delivery

When planning end user training, it was originally assumed that people knew how to do their jobs, so all they had to be told was how the new business methods and systems differed from the old ones. However, we found that some people may have been doing their jobs by rote, and needed more comprehensive support than most end users.

Business process training was done by Human Resources (not ISC), using a train-the-trainer model. Some units taught their staff better than others. Wharton's bi-weekly brown-bag lunches on FinMIS are an example of good ongoing training (though those who *really* need to attend do not). People who don't use FinMIS often have the most problems. Re-learning is an issue. A simpler system would help--the business process is very complex. Also, we should simplify end user training so they are taught only what they need to know. For example, some people only do PO's; some only do approvals.

End-user training for temporary staff?

Different schools and centers feel differently about whether temps or work/study students should have access to secure data. If temps do have access, they should use their own id's rather than borrowing id's from others.

However, people cannot get id's today until they have been trained. If temps are given id's, they should be given temporary id's with many constraints, such as security limitations, an expiration date, and limits on access to features. The school or center using the temps is responsible for training the temps.

FinMIS training *was* useful to local IT support providers. However, it would be better to have orientation training for them, rather than full FinMIS training. It may not be realistic to train all the front-line support people--perhaps a train-the-trainer approach should be used.

End user training involved local IT support providers, because they were called upon to set up the training rooms. Timing of training was an issue--FinMIS training needed to be done at the same time as other training, and there were not enough labs. It would be wonderful to have standing, big labs that departments could rent. The departments should also be able to install software on the lab equipment. Someone pointed out that the labs at the CRC meet this description. Someone else pointed out that this information should be posted on the Web so users know about it.

We *must* allow enough time for training. We cannot hold people accountable for doing something if they are not trained to do it. Boundaries need to be made more clearly defined for local IT support providers--they cannot be expected to be FinMIS trainers when school/center contacts are not available.

Though a training database was created as part of end user training, no one used it. We must allow people time after training to practice.

Technical Documentation

Keep documentation on the Web.

Web instructions for installing things were good, but the Mac instructions could be simplified to "copy this preferences file." The instructions should be made available on the Web in a timely manner--the installation instructions were needed earlier than they were available.

FAQ lists on the Web were useful. So were Paul Weidner's daily updates.

It was hard to track down who was responsible for the Web page when problems with the Web page developed.

The Web page should be re-organized, but the URL should *not* be changed--end users have bookmarked it. (The re-organization of the Web page is in process.)

A knowledge database search for the Web documentation would be helpful.

Someone said a printed newsletter would be helpful.

Others pointed out that the BottomLine already exists and meets this need--but the person who suggested having a printed newsletter did not know about the BottomLine. The newsletter should be mentioned in the Web documentation, and information on how to subscribe should be included.

End-User Documentation

Value: Finished Documents

Keep documentation on the Web.

Existing documentation includes the Cornerstone homepage and the training manual.

There is no end user manual, only the training documentation. End users need real documentation. We need to distribute the chapters that do exist and make sure all the users get them.

The Web documentation should include examples of what the reports look like. And users need a review of FTP. (An FTP review may not be needed if the report strategy becomes browser based.)

What do we do about people with poor or no local support?

Product Licensing

Value: Site License

Product Distribution

Value: Network

Support Provider Identification/Certification

Value: None

ISC Management Role

Value: Coordination

No Pillar training was provided. ISC was not involved in the Pillar roll out. ISC should have had a larger role in rolling out this University-wide administrative system.

Non-ISC Management Role

Value: Coordination/Owner

ISC Service Role

Value: Contribute

People love the Data Warehouse and the Data Marts. (The Data Marts offer canned reports.) However, they need access to detail data so they can drill down to investigate problems.

Support Provider Service Role

Value: Contribute

One problem with the current FinMIS Support model is that sometimes the BA would be buildings away from the end user, and the local provider of IT support would be called into the breach. Often, the IT support person would have to determine whether the problem was a technical problem or a business process problem.

Different schools/centers rolled out FinMIS differently. We need a key IT person in each school (like the school/center contact person who handles business issues), and we should have the key people decide how best to roll out for their school or center.

Vendor Service Role

Value: provide the product (which we customize)

Time Frame

Value: Immediate (FinMIS is in production)

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