Background

Experience at Newcastle has shown that communication with SAP users can be critical to the successful implementation and long term maintenance of a large scale SAP R/3 implementation in a Higher Education context. At Newcastle we have seven Faculties (Medicine, Arts, Science Engineering, Law, Environment and Social Science, Education, Agricultural and Biological Science) as well as four Spending Authorities (Estates and Student Residences, Academic Services, Central Administration and Management Information Development Services).

The diversity of the core business of the University is reflected in the numbers of SAP users in the University, we have 600+ users which is a mobile group and which has a widely varying level of IT skills. For many of these users SAP work is a small proportion of their overall workload and all communication and training needs to be dealt with in that context. In particular initial problems at go-live (1989) arose from the perception that SAP R/3 is cumbersome and difficult and those problems impacted negatively on their concurrent but unrelated work. This was most acutely, though certainly not exclusively, felt in Academic Departments, where devolution of financial responsibility to Faculties was simultaneously imposed. At that time it was essential to reassure users that things would improve with experience and that SAP R/3 could deliver useful functionality without undue time and resource burdens whilst providing the additional financial controls required by devolution.

The Role of Communication

Our mission is to treat our users as 'customers', to inform but not burden and to help them to feel that they have a role to play in the development of the system and consequently the success of the University. The University, like many others is a diverse organisation and the scope of communications reflects this - consequently it is essential that users can filter the wide range of information sent to them, avoiding information fatigue.

Methodology

Our principal method of communication is of course e-mail. All our users belong to a Faculty mailbase and these are a subset of a mailbase which includes all our users. Messages sent to the mailbase are written by one person to ensure consistency of style, and in most cases are signed off by the SAP training team and the Help desk before release.

Mailbase communications are backed up with a website. This is maintained in-house to ensure that updates are made quickly and the contents of messages sent to the user mailbase are recorder here, often in much greater depth than would be possible in an e-mail message.

Each Faculty and Spending Authority has a dedicated user group to which all users are invited. These are attended by representatives from MIDS (including Training team), the Help Desk and an Accountant. The groups deal with a range of issues, system messages, and they reinforce training and best practice.

Outcomes

Principally we foster User involvement, but within this we reinforce best-practice and help to implement policy. The notes of the meetings are circulated round the development team in order to provide feedback and information to keep them in touch with the users. The package as it stands works well and users feel comfortable with the information they receive, but we are very much aware that the pattern of user skills changes through time and the format of this communications will develop and change accordingly.