constituent owner and

CONSTITUENT OWNER AND Data Sharing Policy

1

CCONSTITUENT ONSTITUENT OOWNER AND WNER AND

DDATA ATA SSHARING HARING PPOLICYOLICY

Version 1.0 FINAL

14 July 2009

C O N S T I T U E N T O W N E R A N D D A T A S H A R I N G P O L I C Y

Constituent Owner and Data Sharing Policy (Version 1.0) – University of the Witwatersrand, Johannesburg 2

Document History

This document is valid as the most current version until a revision to it is generated and/ or the final

version has been approved.

Document Location

The source of the document will be found in the Project file.

Revision History

Version Revision

Date

Previous Revision

Date

Summary of Changes Changes

Marked

0.3 11 June 2009 7 June 2009 Throughout document based on 10 June 09

stakeholder meeting and subsequent

comments/contributions.

Changes

are

marked

using

tracked

changes

Approvals

A signed approval form is required only when the document is approved and finalised. Signed approval

forms, appended to documents, are filed in the project files.

Name Division/Department

Caroline Fairbrother Academic Information Systems Unit

Prof Rob Moore Advancement

Peter Maher Alumni Office

Tessa Murray Business School

Nhlanhla Mabaso Computer Network Services

Charmaine Pretorius Development Office

Patrick Fitzgerald Finance

Elke Gevers Human Resources

Prof Derek Keats Knowledge & Information Management

Senteni Nsibande Wits Language School

Ferna Clarkson Marketing

Dr Derek Swemmer Registrars Division

Carol Crosley Student Enrolment Centre

Fazela Haniff Wits International Office

Distribution

This document has in addition distributed to the following individuals for comment.

Name Division/Department

Lorraine Purkey Academic Information Systems Unit

Ivor van der Bijl Advancement

Anita Vallabh Computer Network Services

Luci Carosin Computer Network Services

Yogini Govind Computer Network Services

Lesley Salter Engineering & Built Environment

Kevin Mcloughlin Management Information Unit



Contents

1 PURPOSE OF THIS DOCUMENT..................................................................... 5

2 BACKGROUND: CRM PROJECT/S ................................................................. 5

3 RATIONALE FOR A CRM POLICY................................................................. 6

4 POLICY CONCEPTS........................................................................................... 6

4.1 CONSTITUENT (CONSTITUENCY) ......................................................................... 6

4.2 CONSTITUENT OWNER ......................................................................................... 7

4.3 DATA SHARING ..................................................................................................... 7

4.4 DATA OWNERSHIP ................................................................................................ 7

5 SYSTEMS AFFECTED BY A CRM POLICY .................................................. 8

6 DIFFERING STANCES ON DATA SHARING ................................................ 9

7 MULTIPLE CLAIMS TO CONSTITUENT OWNERSHIP .......................... 10

8 CONSTITUENTS AND CONSTITUENT OWNERS ..................................... 12

9 POLICY AND GUIDELINES............................................................................ 13

9.1 DUPLICATE RECORDS (A.K.A. UNIQUE RECORDS)............................................ 13

9.1.1 Description ....................................................................................13

9.1.2 Resolution .....................................................................................13

9.1.3 Issues............................................................................................14

9.2 DATA INTEGRITY (A.K.A. DATA CURRENCY AND DATA ACCURACY) .............. 15

9.2.1 Description ....................................................................................15

9.2.2 Resolution .....................................................................................15

9.3 DATA SECURITY ................................................................................................. 16

9.3.1 Description ....................................................................................16



9.3.2 Resolution .....................................................................................16

9.4 MULTIPLE CAPTURE.......................................................................................... 16

9.4.1 Description ....................................................................................16

9.4.2 Resolution .....................................................................................17

9.5 DATA PRIVACY................................................................................................... 17

9.5.1 Description ....................................................................................17

9.5.2 Resolution .....................................................................................17

9.6 BUSINESS GOALS................................................................................................ 17

9.6.1 Description ....................................................................................17

9.6.2 Resolution .....................................................................................17

9.7 COMMUNICATION .............................................................................................. 18

9.7.1 Description ....................................................................................18

9.7.2 Resolution .....................................................................................18

9.8 SEGMENTATION.................................................................................................. 18

9.8.1 Description ....................................................................................18

9.8.2 Resolution .....................................................................................18

9.9 OVER COMMUNICATION.................................................................................... 19

9.9.1 Description ....................................................................................19

9.9.2 Resolution .....................................................................................19

9.10 DATA CLEANSING ............................................................................................ 19

9.10.1 Description ..................................................................................19

9.10.2 Resolution ...................................................................................19

9.11 CONFLICT RESOLUTION .................................................................................. 20

9.11.1 Description ..................................................................................20

9.11.2 Resolution ...................................................................................20

ACCEPTANCE FORM ............................................................................................ 21



1 PURPOSE OF THIS DOCUMENT This document outlines the policies and guidelines governing the University’s

management of constituent relationships and concomitant constituent data.

2 BACKGROUND: CRM PROJECT/S The University has approved the rollout of a CRM solution across multiple

areas that include the Student Enrolment Centre (SENC), Alumni Office and

Marketing scheduled for 2009 and the Business School, Language School

and Development Office scheduled for 2010. This after a detailed exercise in

defining requirements; identifying, evaluating and selecting a solution;

addressing risks and concerns; and, successfully implementing a pilot1.

During this process, CRM was defined as follows:

“CRM is both a business strategy and a set of discrete software tools and technologies, with the

goal of reducing costs, increasing revenue, identifying new opportunities and channels for expansion,

and improving customer value, satisfaction, profitability, and retention… CRM focuses on automating and improving the institutional processes associated with managing customer relationships in the

areas of recruitment, marketing, communication management, service and support” (Grant &

Anderson, 2002: 24).

The key advantage of implementing a CRM solution is to bring into view the

full range of the various constituents the University has a relationship with. It

allows for the coordination of multiple relationships by various University

areas.

Many University areas have differing claims on specific constituencies. These

claims may at times be at odds with each other. For example, the Alumni

Office after receiving a telephonic request may want to update a graduate’s

maiden name but this contravenes the Registrar’s statutory responsibility for

ensuring valid supporting documentation. Another challenge is the claim by

various University areas to raise funds from the same alumni pool.

A lengthy and detailed process was embarked to understand the issues and

concerns raised by University stakeholders. Meetings and workshops were

held culminating in the drafting, debating, reviewing and refining of this policy

1 See WITS CRM Executive Summary, V2.0, 12th March 2009.



document. It establishes the landscape of constituents and data owners,

acknowledges primary ownership and provides a mechanism for resolving

future conflicts.

A Project Board that reports to the Senior Executive Team (SET) on a regular

basis guided this process as part of its role in overseeing the project. The

Executive Sponsor for the project is the Deputy Vice-Chancellor for

Advancement, Prof. Rob Moore, as the overall CRM strategy is located within

the Advancement Office.

3 RATIONALE FOR A CRM POLICY A CRM policy is required to protect the University and its constituents’

information while enabling the same information to be used by the University’s

departments in line with its strategic objectives.

By developing a policy the University is able to determine roles,

responsibilities and accountability for the management of its CRM information

as an integral asset for maintaining, enhancing and building new

relationships.

Establishing a CRM policy makes it possible for the University to benefit from

enhanced information management while facilitating a collaborative work

environment. This would require the policy to include operational guidelines

on the use of information that will reside within the CRM system in terms of

access, accuracy and updating.

The CRM Policy also assists in identifying and highlighting risks to the

University.

4 POLICY CONCEPTS The following are concepts used in the definition of this policy.

4.1 Constituent (Constituency)

Constituent refers to all parties with whom the University has some form of a

relationship. This includes applicants, parents, educators (teachers, career

counsellors, and principals), students, alumni, donors (individuals,



organisations), government departments, companies, universities, statutory

bodies, non-governmental organisations, among others. For effectiveness and

ease of management constituencies may be split. For example, the top 20

companies (using whatever measure), MBA alumnus, etc.

4.2 Constituent owner

When an internal University stakeholder has developed and promoted a

relationship with a constituency (whether internal or external or part thereof)

this internal stakeholder claims ownership of the constituent relationship. This

includes the responsibility for regular communication as well as gatekeeper

for all other University communication to that constituent or part thereof.

The constituent owner cultivates specific relationships and therefore asserts

overall responsibility for the data in terms of determining the availability and

security of data, as well as in some instances the rules governing the use of

data.

The constituent owner, in this context, claims responsibility for establishing

the data requirements in terms of validity and accuracy of data types, rules

governing the data including those that impede data duplication.

4.3 Data sharing

The CRM system can facilitate information sharing among University

departments by providing access to information that can be used for the

varying purposes across the University.

For data sharing to take place effectively it requires the system to merge input

from several distinct sources that have an interest in reusing the information.

Each department would in effect be agreeing to store and share information in

a collective repository, albeit with specific rules or guidelines regarding

efficiency, accuracy, information security and privacy.

4.4 Data ownership

This refers to a need to control data most often by emphasising the value of

the information to a department’s core process or function. In such cases the

‘owner’ may be inclined to regard the information as being most secure and



reliable if it remains solely within the sphere of influence of that specific

department. On the other hand there may be concerns such as privacy and

legal requirements which make it necessary to protect the data.

Ownership also addresses the responsibility for determining the:

• quality of the data

• security and privacy of the data

• availability of the data

• performance requirements of the data.

Those who originate data take on board authority, responsibility and

accountability in terms of creating and effecting the policies and rules relating

to data. This suggests that data stewardship is of great significance

particularly as data quality is somewhat dependent on individuals who are

most knowledgeable about the nature and purpose of the data.

5 SYSTEMS AFFECTED BY A CRM POLICY The following systems interface or may interface with the CRM system. These

systems therefore must be considered in terms of impacts in relations to a

CRM policy.

CRM system (CRM) - status: RightNow to be implemented

Student system - status: existing Oracle Student System (OSS) that will be

replaced by 2012

Human Resource system (HRS) – status: existing Oracle system

Short Course system – status: existing Short Course system (SCS)

Alumni Office system – status: existing Profiler system to be replaced by

the RightNow CRM Solution and an Event Management System (new) in

the medium term

Development Office system – status: existing DevMan system

Enterprise Data Warehouse – status: abstracted repository for staff,

student and finance information, updated regularly, to support

management decision making



6 DIFFERING STANCES ON DATA SHARING The parameters framing the debate on data sharing, with specific regards to

data ownership, rights to change data, and the privacy of constituent data, is

illustrated below:

Figure 1: Two competing agendas

A compliance-oriented stance implies ownership of the data rather than the

relationship; therefore the right to access and/ or change data is somewhat

inflexible. For example, access to data may be denied in terms of privacy

concerns, yet even if access to data is allowed, there may be restrictions in

terms of how the data is to be used and whether the data can be amended or

extended.

A relationship-driven stance implies that the quality of the interaction and

communication with the constituency is determined by the currency of the

information, and to ignore this may undermine the value of the constituent

relationship. For example, information must be updated in order to connect

with a constituent whether through personalising communication, building a

robust profile or encouraging feedback – all of which may be somewhat

dependent on being able to promptly capture and respond to new and

changing information requirements.

Taking into account the differing nature of the work of the various University

departments, some stakeholders appear to have a vested interest in one of

the two competing agendas on data ownership and sharing.

A compliance‐oriented agenda that concerns itself with issues pertaining to

privacy, accuracy and change process integrity

A relationship‐driven agenda that concerns itself primarily with currency of information



RELATIONSHIP-DRIVEN COMPLIANCE-ORIENTED

Alumni Office Registrar’s Office

Student Enrolment Centre

WITS Business School

WITS Language School

Foundation

Wits International Office

Marketing

Advancement

Student Affairs

Figure 2: Stakeholder preferences on data sharing

Given the above, this policy attempts to address the following:

The read and write rights various stakeholders have to common data in

various systems

Rules and procedures pertaining to the use of data in general (e.g. the

use of a field to indicate the validity of a particular contact record)

Privacy of certain information

7 MULTIPLE CLAIMS TO CONSTITUENT OWNERSHIP This policy also attempts to define a framework and concomitant guidelines

on constituent ownership, with specific regards to more than one internal

stakeholder asserting a critical relationship with the same constituency is

illustrated below:



Figure 3: Multiple areas target the same constituency

Various University areas currently and potentially target the same

constituency or part thereof. Wits Alumni are targeted in the marketing

campaigns of WBS, WLS and Wits Enterprise, among others. In addition,

several areas within the University have their own alumni data.

Other common target ‘markets’ are donors, companies, government

departments and various institutions. Many University departments, faculties

and schools target these constituencies for funding, research, bursaries,

prizes, donations, course offerings and wide-ranging community engagement

undertakings.

Furthermore, alumni working for companies and government departments

also are the focus of various marketing campaigns.

Other University stakeholders that may target these constituencies include:

Marketing

SEnC

Registrar’s Office

Vice-Chancellor’s Office (VCO)

Senior Executive Team (SET)



Therefore this policy provides a starting point together with guidelines on the

future resolution of conflicts where they arise.

8 CONSTITUENTS AND CONSTITUENT OWNERS This section outlines all the University constituents with the appropriate

primary relationship and secondary relationship (alternate and/or competing)

owners.

CONSTITUENT OWNER ALTERNATE OWNER Applicant Registrar’s Office

Under-graduate SENC Post-graduate Faculty Schools Short-course Schools Wits Enterprise Donor One of above Development Office

Student Registrar’s Office

Under graduate Faculty Postgraduate Schools Faculty Short-course2 Schools Faculty Donor One of above Development Office International One of above International Office Disabled One of above Disabled Students Unit Sick One of above Campus Health Job seeker One of above CCDU

Alumni Alumni Office Graduates Alumni Office Schools

Development Office Post-graduates Alumni Office Schools Short course (non-degree) Alumni Office Schools Diplomate Alumni Office Schools Non-graduates3 Alumni Office Friends of the University Alumni Office Donor Alumni Office Development Office International Office Alumni Office International Office Disabled Alumni Office Disabled Students Unit

Company Advancement Division

Top 20 SET Advancement Division Donor Development Office Bursaries/Scholarships Financial Aid Office Development Office

Prizes/awards Faculties Development Office

Short courses/bespoke training Schools WITS Enterprise

2 Including certificates of attendance and of competence i.e. credit and non-credit bearing certificates 3 Non-graduates are defined as students that have registered but have not completed a qualification prior to leaving

the University. This includes students that have cancelled, de-registered or allowed their registration to lapse. This

grouping requires further discussion and debate and so has been included on the parking lot for the CRM User Group

to deliberate on.



Externally funded work Research Entities WITS Enterprise

Research Research Office Schools WITS Enterprise Research Entities

Potential Employer Advancement Division CCDU Staff Human Resources Division

Consultant Human Resources Division

Parts of certain constituencies require further elaboration and specific

ownership allocation. For example:

• It may be more prudent to manually allocate ownership of the top 20 (or

whatever cut-off makes sense) companies that the University engages.

This allocation can be based on which department currently has the

primary relationship, or which department based on its strategy should

have the primary relationship or even which SET executive enjoys the

confidence of a particular company. The determination of the top 20

companies can based on various specific current or future strategic

measures such as total funds contributed, total revenue generated, total

number of staff trained, total value of research funding etc.

9 POLICY AND GUIDELINES This section outlines the policy and guidelines where appropriate for each of

the identified areas.

9.1 Duplicate Records (a.k.a. Unique Records)

9.1.1 Description

The creation of new constituents in any University system should not result in

duplicate records. Constituents that are new to the University, such as

potential applicants or donors captured on the CRM system, must not exist on

base systems such as OSS/ SCS and DevMan respectively.

9.1.2 Resolution

To ensure duplicate records are not created the following actions shall be

taken:



a. Each system must check for unique keys e.g., name, surname, title, id

no on OSS

b. If the record exists than the current constituent details should be

uploaded from the respective system

c. Otherwise the constituent details must be captured

d. Include “unique record identification/resolution guidelines” in CRM and

other systems user training

9.1.3 Issues

a. The lack of a “life-time” e-mail address could cause duplicates on the

CRM system. The generation of a unique identifier associated with

some rules could address this challenge. The student number is

unique.

b. Donors in some cases are duplicated on the Student system since they

also provide awards/prizes directly to faculties and schools. A unique

record on the CRM system would assist Schools and the Development

Office in resolving this issue.

c. Companies that have multiple divisions may also be duplicated. The

organisation functionality in the CRM solution that links companies with

divisions would assist in resolving this issue.

d. Company names are sometimes abbreviated or misspelt resulting in

duplicate records. A data cleanup exercise of all company records by

the constituent owner needs to be initiated.

e. The CRM system must ensure that constituents are not duplicated on

the CRM system by using the unique key on base systems such as the

student number, staff number etc.

f. The existing alumni number generated within the existing Profiler

system is not required in future.

g. The CRM is not intended to solve data problems experienced in the

underlying base systems. Initiatives are continually underway to

address data issues in base systems (see 9.10).



9.2 Data Integrity (a.k.a. Data Currency and Data Accuracy)

9.2.1 Description

The CRM and related base systems (OSS, SCS, Devman and HR) must

ensure currency of constituent data (contact details) and maintain inter-

constituent relationships (parent/child, employer/employee,

company/division).

9.2.2 Resolution

a. For “surname” changes a user-defined “preferred surname name” field

on the CRM system for recording the change would be created.

However, upon any change to the “preferred surname” the constituent

would be notified of the change and be encouraged to submit

supporting documentation to the constituent owner should a permanent

change that would be ‘officially’ recognised by the University be

required. An incident would not be sent to the primary Constituent

Owner for optional follow-up. Changes to the legal surname on base

systems must be sent to the CRM system.

b. Changes to contact details on the CRM system would be sent to base

systems with the application of the requisite rules e.g., primary/active

on OSS. The Alumni Office, Development Office and other University

departments other than SENC, faculties and schools would NOT be

able to update registered student information. This does NOT include

those who are already alumni and/or donors. Changes to contact

details on base systems should also filter automatically to the CRM

solution based on the defined Interface Specifications. The Interface

Specifications must be signed-off by all key stakeholders.

c. Inter-constituent relationships would only be maintained on the CRM

system and developed on a gradual basis. For example, employers

listed on applicant or student records may not necessarily exist as an

organisation on the CRM system.

d. Data integrity should be included in CRM System User training as well

as Base System User Training.



9.3 Data Security

9.3.1 Description

Constituent data shall be restricted to authorised users based on their

designated role, which would assign specific data view and/or change

privileges. Rights to certain functions shall also be restricted based on roles

and or appropriate approvals. For example, obtaining a list of constituents

would be restricted to certain roles within certain departments. In some cases

appropriate approvals such as constituent owner or ethics approval shall be

required.

9.3.2 Resolution

a. Roles and security levels shall defined for all CRM users with

adherence to the University’s password and computer usage policies

b. Constituent segmentation functionality shall be restricted to Marketing,

SENC, Foundation and Alumni Office only. Schools must work through

Marketing or Alumni Office subject to constituent owner and/or ethics

approval. A copy of the approval must be copied to the CRM Manager.

c. Section 8 lists constituent or part thereof and accompanying

constituent owners. Grey areas and future changes shall be resolved

as outlined in 9.11.

d. All registered students shall also exist on the CRM system.

e. Regular reports alerting the CRM Manager to all segmentation

activities shall be published and noted at the CRM User Group

meeting.

9.4 Multiple Capture

9.4.1 Description

The aim of the CRM solution is to improve constituent service, improve

efficiencies and reduce costs with the eventual elimination of multiple-capture

and multiple maintenance of constituent information.



9.4.2 Resolution

a. Bi-directional interfaces with base systems e.g., OSS, SCS & HR

(Person file) shall be developed based on agreed Interface

Specifications so that changes (see 9.2) to contact information occurs

once on any one of these systems.

9.5 Data Privacy

9.5.1 Description

Constituent information is private and confidential to the University and its

employees and consultants.

9.5.2 Resolution

a. Each CRM and base system user shall be provided with a copy of the

University’s employment contract that deals with confidentiality, non-

disclosure and protection of University data.

b. The CRM system shall be configured to limit access to functionality and

data based on specific roles required to complete defined tasks e.g.,

only designated Foundation CRM users can view donations, UG/PG

applicant information not generally available etc.

c. Applicants shall not be targeted for marketing purposes without the

prior permission of the Registrar’s Office.

9.6 Business Goals

9.6.1 Description

Policies, processes and systems shall primarily be implemented so that

departments are able to satisfactorily achieve the defined CRM goals.

Conversely policies, processes and systems shall not unduly limited

constituent relationships due to highly restrictive and debilitating compliance

requirements.

9.6.2 Resolution

a. The CRM training shall outline the purpose of the CRM solution, the

University’s strategy and specific department’s goals in this regard.



b. The CRM User Group shall regularly deliberate on achieving balance

between constituent relationship and compliance requirements. This

policy shall be modified accordingly.

c. The Constituent Owner and Data Sharing policy shall be reviewed on a

regular basis by the CRM User Group.

d. The CRM Manager shall provide regular reports to senior management

on the success of the University’s CRM strategy and also raise key

debilitating challenges.

9.7 Communication

9.7.1 Description

This issue refers to the use and protection of the University’s brand as

depicted using the name, logo, by-line etc.

9.7.2 Resolution

a. The Marketing department will, where required, review and approve

brand usage.

9.8 Segmentation

9.8.1 Description

The list of contacts can be extracted using any combination of criteria. This

provides a powerful marketing tool to segment constituents. However, there is

concern that such lists can be made available to unauthorised parties

compromising the University.

9.8.2 Resolution

a. All staff employed by the University either as full-time or in a contract

capacity are governed by their Conditions of Service and the

Acceptable Use policy.

b. The Constituent Owner’s signed approval is required for required

extractions. This is particularly important where the Ethics Committee

approval is required.



c. This facility will be limited to key individuals in the Marketing, SenC and

Alumni Office. The CRM Manager will provide overall guidance.

9.9 Over Communication

9.9.1 Description

The CRM solution will now provide stakeholders with enormous tools to

communicate with constituents. There is a concern that constituents that are

part of multiple target markets would receive increasing number of e-mails

and SMSs. This may be counter productive as constituents may be

overwhelmed by so much communication.

9.9.2 Resolution

a. Communication with various target groups would require the approval

of the constituent owner.

b. The system would be configured so that no constituent receives more

than a set limit of communication per period.

c. Constituents would have the facility to register/de-register for various

University communications.

9.10 Data Cleansing

9.10.1 Description

The CRM and base systems data shall be kept up to date, duplicate records

shall be resolved and correct information maintained so that the objectives of

an effective CRM system can be achieved.

9.10.2 Resolution

a. Constituent owners shall be responsible for data cleaning on both CRM

and, if applicable, their base systems

b. The CRM Manager shall initiate regular independent review of base

system data being uploaded to the CRM system and to produce

findings/recommendations to the CRM User Group

c. Constituent owners shall be responsible for adhering to agreed data

quality and validation processes.



9.11 Conflict Resolution

9.11.1 Description

From time to time new issues may arise or constituent owners may not agree

on the resolution of data sharing and constituent ownership issues. This may

hinder some CRM objectives and compromise affected departments.

9.11.2 Resolution

a. A CRM User Group comprising of all University stakeholders shall be

created as a forum to discuss/debate/resolve ongoing issues. The

CRM Manager shall be responsible for initiating this Group, which shall

be formed after the CRM is successfully implemented.

b. The CRM Manager shall where appropriate escalate irresolvable

issues to SET for further deliberation.

c. The CRM User Group shall be responsible for reviewing and revising

this policy document, which shall be submitted to appropriate

University Committee for adoption.



ACCEPTANCE FORM The decision-maker/s and representatives of various stakeholders

acknowledge that they have read, understood and accept the policies and

guidelines outlined in this document. It also is agreed that any decisions

affecting this document will be valid only if minuted and agreed upon by the

respective parties.

Name :

Position :

Signature :

Date :

Name :

Position :

Signature :

Date :

Name :

Position :

Signature :

Date :

Name :

Position :

Signature :

Date :

Name :

Position :

Signature :

Date :

Name :

Position :

Signature :

Date :

Name :

Position :

Signature :

Date :

Name :

Position :

Signature :

Date :



Name :

Position :

Signature :

Date :

Name :

Position :

Signature :

Date :

Name :

Position :

Signature :

Date :

Name :

Position :

Signature :

Date :

Name :

Position :

Signature :

Date :

Name :

Position :

Signature :

Date :

Name :

Position :

Signature :

Date :

Name :

Position :

Signature :

Date :

Name :

Position :

Signature :

Date :

Name :

Position :

Signature :

Date :

Name :

Position :

Signature :

Date :

Name :

Position :

Signature :

Date :

constituent owner and

Documents