Department of Higher Education and Training Post-School … Planning Management Support/DHET -...

Department of Higher Education and Training

Post-School Education and Training

Central Application Service

Enterprise Architecture

Chapter 4 – Standard Operating Procedures

February 2016

Post-School Education and Training Central Application Service

Enterprise Architecture Chapter 4 - Standard Operating Procedures

February 2016

i

Contents

1 Terms of Reference ...................................................................................................................... 1

2 CAS Service Operating Model ...................................................................................................... 1

3 CAS Functional Model .................................................................................................................. 5

3.1 Business Architecture ....................................................................................................... 5

3.2 Stakeholder Map .............................................................................................................. 7

4 Standard Operating Procedures ................................................................................................... 8

4.1 Preamble .......................................................................................................................... 8

4.2 Core Application Handling ................................................................................................ 9

4.3 Central Academic Programme Data Store Process Flow .............................................. 10

4.4 Supporting Functions Process Maps .............................................................................. 11

4.5 Outreach & Promotion Protocol ...................................................................................... 11

4.6 Training Protocol ............................................................................................................ 12

4.7 Communication Protocol ................................................................................................ 13

4.8 Call Centre Scripts .......................................................................................................... 14

5 Conclusion .................................................................................................................................. 16

A. Core Application Handling Process Maps .................................................................................. 17

B. Central Academic Programme Data Store Process Flow ........................................................... 26

C. Finance Management Process Maps ......................................................................................... 27

D. Supply Chain Management Process Maps................................................................................. 36



February 2016

1

1 Terms of Reference

This Standard Operating Procedures report has been prepared by Learning Strategies as part of the assistance to the Department of Higher Education and Training for the development of an Enterprise Architecture as phase one for a National Post-School Education and Training (PSET) Central Applications Service (CAS).

This chapter completes step 4.2 of the Project Plan and presents deliverable number 4.4 as per the Terms of Reference and forms Chapter 4 of the consolidated CAS Enterprise Architecture.

The purpose of this chapter is to present the proposed service operating model for the PSET CAS, to develop this further into a functional model describing the key functions of the CAS and its interactions with stakeholders, and to develop the business processes for core and support processes.

2 CAS Service Operating Model

The CAS Service Operating Model was described in the Service Model chapter (Chapter 2) and is repeated here for completeness.

A Service Operating Model identifies the highest level of process overview for the components of the services to be delivered by the CAS. Each component of the operating model will have various sub-processes and steps. The operating model is intended to identify the comprehensive scope of services without in any way defining how or where these services should be provided or delivered.

The overall operating model contains the following main steps:

Policy & Legislation

Academic Programme Definition

Outreach &

Training

Application Handling

NSFAS Funding

Integration

Interface with

Institutions

Clearing House &

Application Closing

Reporting Monitoring

& Evaluation


Receive & Process

Application

Receive & Match

Application Fee

Receive & Process

Supporting Docs

Receive & Process

Change of Mind

Interface with Institutions

Send Data to Institutions

Receive Data from

Institutions

Online Applications

Portal

Two-way Communication with Applicants CDS/NCAP integration



February 2016

2

The Operating Model can be analysed into its main components as follows:

Operating Model Step Key Activities Outputs

Policy & Legislation

This is the function performed by DHET to define the policy and if necessary legislate the environment to support the objectives and outcomes of the CAS

The outcome of this step would be amendments to legislation to enable the CAS, policy and regulations. This ensures alignment of the CAS environment towards government and PSET objectives

Academic Programme Definition

This step defines all of the Academic Programmes which will be able to be applied for through the application service and collects the data to be used in the marketing and application process. This step includes:

What Academic Programmes are on offer (in a particular cycle and on a particular institution/campus)

What can be applied for, and the rules, criteria and entry requirements for application and the Academic Programme costs (estimates)

The Academic Programme coding and referencing

The service partners (institutions on whose behalf applications will be handled)

Education and training places available

The outcome of this step would include:

The comprehensive Academic Programme data set for a particular application cycle

The application form (online design and paper layout)

Academic Programme selection aids (including sub-sets to be provided on demand)

The handbook information

Change requests to process and/or system to accommodate new requirements

Outreach This step includes the entire marketing and outreach process which is aimed at ensuring appropriately completed and submitted applications from various sources.

The outreach activities include:

School visits

Career fairs

Sending handbooks and application forms directly to schools, universities and directly on request (note the handbook will be a “how to” guide on applications, not a list of Academic Programmes)

Handling walk-ins

Identifying access points such as libraries and municipalities

Dealing with social media

Dealing with call centre queries

The outcome of this step are guidelines and understanding on the application process, and completed and submitted applications by applicants

Training The training component includes the training of institutions to engage directly with the applications service as well as the training of access points to receive applications and support the application process

The outcome of the training process is appropriately trained access points and institutions to support the application process



February 2016

3

Operating Model Step Key Activities Outputs A

pp

lic

ati

on

Han

dlin

g

- Receive and process applications

Pre-printed, numbered application forms so as to ensure that forms can be tracked to their source

Receive and capture forms which are hand delivered or received by post

Evaluate online forms for completeness

Process, validate and quality assure

Respond to applicant confirming receipt of applications

The output of the application handling process is a received, payment confirmed, validated, and processed application ready for submission to the institutions to which applications have been submitted

- Receive and match application fee

Receive application fee via EasyPay and other channels such as payment to banks and other service providers

Receive payment by credit card or online

Matching of payment to application

Respond to application noting receipt of applications

- Receive and process supporting documents

Receive supporting documents, scan and link them to the application form

Provide a response to applicant noting receipt of supporting documents

Update document management solution and quality assure

(Opportunity exists to get information directly from National ID database as well as results databases potentially avoiding the requirement for certified copies)

The outcome of this step is supporting documents associated with applications

- Receive and process change of mind

This is effectively a sub-set of the application process which revises the application process. Each person is allowed a single change of mind where after additional change of mind documents need to be accompanied by a further payment. It is treated largely as the process above

The outcome of this step is Change of Mind for applications

NSFAS Funding integration

The CAS service proposition requires the establishment of funding eligibility during the application, as well as integration with the NSFAS processes to enable applicants to apply to institutions and to NSFAS at the same time. This will support NSFAS’s strategy for an applicant-centric model and will also assist institutions in admissions decisions (if they are aware that students are funding eligible) ), noting however that

The output of this step is updating applications with funding status including eligibility for funding, confirmed funding and funding awarded



February 2016

4

Operating Model Step Key Activities Outputs

funding eligibility is not intended to be a determinant of admissions

Inte

rfac

e w

ith

In

sti

tuti

on

s

- Send data to institutions

This process covers the data engagement with the institutions. The engagement is a two-way process whereby complete applications which have been received are first analysed to identify those which have met requirements and this information is then made available to the institutions for it to be accessed either via the online portal or for them to use data which is downloaded to an FTP site for them to use as required. That is then sent back by the institutions which is updated into the CAS database.

Key questions to consider for the future are:

Who will be responsible for communications with applicants after data is handed over to institutions? Proposal that CAS should be responsible for confirming that a firm offer has been made where after the institution will be interacting directly with the student.

How will the obligation on the institution to send back information be ensured?

The output of this step in the value chain is the interchange of data between the CAS and the various institutions. The data interchange is two-way - both sending applications to the institutions and then receiving updates to the status of the applications from the institutions

- Receive data from institutions

- Online applications portal

Clearing house and application closing

This process requires a number of steps aimed at supporting applicants to find a place in the PSET system. It may involve recommending (or counselling) to applicants where alternative options may be available. It may also involve the institutions making direct application offers of places for training or education where students have not been accepted in their preferred courses. This will require pro-active identification of Applicants who should be referred for career guidance. Applicants will also have to Opt-In to participate in the Clearing House.

This step aims to ensure all applicants get access to appropriate opportunities. The output is therefore the maximum number of closed opportunities with students being accepted for appropriate education and training

Reporting, monitoring and evaluation

This process requires extensive business intelligence capability to ensure value add to the institutions. There will also be value add to schools and provincial education departments as well as to the DHET as a whole

The output of this step is reports which assist in the management of the entire sector and the improvement of the entire service



February 2016

5

It must be noted that the following key assumptions have been made in the Operating Model

• The existence of a National Academic Programme Data Store (or Stores) to house all Academic Programme data; and

• The ability of NSFAS, Home Affairs, NLRD and other online data service providers to provide data with acceptable response times.

3 CAS Functional Model

The Operating Model is used to define the Functional Model of the PSET CAS. The Functional Model consists of two views of the CAS, namely

1. A Business Architecture view that defines how the CAS should be operated and structured; and

2. A Stakeholder Map view that defines the stakeholders with whom the CAS interacts.

In both cases, the views represent and “applicant facing” side and an “institution facing” side, which allows for logical grouping of functions and stakeholders.

The Business Architecture will then be used to define the business processes while the Stakeholder Map will be used in the Stakeholder deliverable to define the stakeholder strategy.

3.1 Business Architecture

The PSET CAS Business Architecture is presented in the diagram below. It consists of core functions that relate to the application handling service and related activities and support functions that relate to the activities that support the core service and/or administer the CAS entity.

The Business Architecture represents “applicant facing” components at the top of the diagram and “institution facing” components at the bottom of the diagram, with components that face both applicants and institutions going from top to bottom.

The core functions represented in the diagram are also arranged in such a way that earlier activities are to the left of the diagram and later activities are more to the right of the diagram, aiming to provide a perspective on the application lifecycle.

It must be noted that while the diagram aims to present a visual image of structure, it is high level representation in which complex aspects are simplified.



February 2016

6

A brief description of the components in the Business Architecture is provided in the table below.

Component Description

Core

Functions

Outreach & Promotion The function through which the CAS markets itself to key stakeholders, especially applicants

Training The function through which Institutions and other service partners understand the CAS processes and systems

Academic Programme Information

The function through which the National Academic Programme is maintained and made available to applicants

Online Applications The (systems) function through which online applications are entered and submitted by applicants

Application QA The function through which applications are validated (and where appropriate are referred)

Payment Processing & Reconciliation

The function through which payments are processed and allocated (largely systems function) and are reconciled

Institution Front End The (systems) function through which Institutions can perform their portion of the application process (i.e. select and regret applicants)

Institution Integration The (systems) function through which integration between the CAS and Institutions is executed

Offline Application The function through which offline applications are received, scanned and filled

Application Handling The function through which offline applications are captured on behalf of applicants (using the Online Application function)

Outreach &

Promotion

Training

Call Centre

Co

mm

un

icat

ion

Online Applications

Institution Front End



Application QAApplication Referrals &

Clearing House

Fin

ance

Man

agem

ent

Hu

man

Res

ou

rce

Man

agem

ent

Sup

ply

Ch

ain

Man

agem

ent

IT S

up

po

rt &

Bu

sin

ess

Inte

llige

nce

Pla

nn

ing

and

Mo

nit

ori

ng

& E

valu

atio

n

Offline Applications

Institution Integration

Core functions Support functions

Applicant Facing

Institution Facing

Aca

dem

ic P

rogr

amm

e In

form

atio

n


Support



February 2016

7

Component Description

Communication The function through which communication with applicants is managed

Call Centre The function through which inbound and outbound calls from stakeholders (predominantly applicants) are managed

Referral & Clearing House The function through which applicants and/or applications (with poor chance of success or that are regretted) are referred for guidance and possible alternative selection and/or are placed in a clearing house where Institutions may approach applicants with offers

Institution Integration Support The function through which support is provided (predominantly via a call centre) to Institution to assist in integration and other issues relating to the application processes between CAS and Institutions

Sup

port

Fu

nctio

ns

Finance Management The function through which the financial management of the CAS is executed

Human Resource Management The function through which the human resource management of the CAS is executed

Supply Chain Management The function through which the supply chain management of the CAS is executed

IT Support & Business Intelligence

The function through which the IT support is provided to the CAS and through which Business Intelligence information is provided

Planning and Monitoring & Evaluation

The function through which the planning and M&E of the CAS is executed

3.2 Stakeholder Map

The PSET CAS Stakeholder Map is presented in the diagram below. It consists of a number of stakeholder groups, presented in the bubbles with further categories and/or stakeholder entities surrounding the bubbles.

The Stakeholder Map represents “applicant facing” stakeholders on the left of the diagram, including both the applicants themselves, but also CAS stakeholders that themselves faces applicants.

In the middle section are service partners that assist the CAS in delivering the services, in the form of points of presence at which applicants may access the service and information providers that provide additional information used in the application handling process.

Finally on the right hand side are institution facing stakeholders, comprising the institutions to which academic applications are made and funding institutions to which funding applications are made.



February 2016

8

The strategy to manage stakeholders throughout the implementation and business as usual of the PSET CAS is described in detail in the Stakeholder Management deliverable and the reader is referred to that document.

4 Standard Operating Procedures

4.1 Preamble

The Standard Operating Procedures are based on and aligned with the Business Architecture described in an earlier section in this document. In order to provide a pragmatic approach to documenting the Standard Operating Procedures in this Enterprise Architecture, the method used to document the Standard Operating Procedures is different for, and appropriate to, the component in the Business Architecture.

This is illustrated in the Business Architecture diagram below where colour-coding is used to indicate the method used:

The Core Application Handling and Referral / Clearing House processes are document in detailed process maps to Level 2 activities;

The Academic Programme Information component is documented in a process flow, but it must be noted that this process flow includes components to a national academic programme data store that are beyond the scope of this project, and are therefore included for illustration;

The Outreach & Promotion, Training and Communication functions are documented in protocols that indicated the service expectations of these functions;

The Call Centre and Institution Integration Support functions are documented in scripts that indicate the expected response to specific call centre requests;

Applicants

Schools

Career Guidance

Points of Presence

PSET Institutions

Funding Institutions

Information Providers

Central Application Service

Public Private

Inschool

Out ofschool

CDS/NCAP Private DoL

Univs

TVETs

Community

SETAs

NSFAS

NSF

DBE

IEBHome Affairs

SARS

NLRD

Career Fairs

Applicant Facing “Service Providers” Institution Facing

Libraries NYDA

Private

CIE

Government

DHET Regional Offices

DBE

PSET Institutions



February 2016

9

The Finance Management and Supply Chain Management functions are documented in generic process maps for the key processes in these functions; and

The HR Management, IT Support & Business Intelligence and Planning and M&E functions are documented in policies that are included in the respective deliverables for these aspects of the PSET CAS.

4.2 Core Application Handling

The Core Application Handling process maps are included in Appendix A, and are documented in Microsoft Visio following IDEF0 methodology principles which describes the:

Triggers / Inputs to an activity

Controls for an activity

Actors/Resources involved in the activity

Goals / Outputs of the activity

The application handling process are presented at a number of levels, as follows:

Level 0 to represent the Application Handling process model

Level 1 to represent the overall Application Handling process flow

Levels 1.1 to Level 1.7 to represent the next level of Application Handling process steps (including Referrals and Clearing House processes).

Outreach &

Promotion

Training

Call Centre

Co

mm

un

icat

ion

Online Applications

Institution Front End



Application QAApplication Referrals &

Clearing House

Fin

ance

Man

agem

ent

Hu

man

Res

ou

rce

Man

agem

ent

Sup

ply

Ch

ain

Man

agem

ent

IT S

up

po

rt &

Bu

sin

ess

Inte

llige

nce

Pla

nn

ing

and

Mo

nit

ori

ng

& E

valu

atio

n

Offline Applications


Core functions Support functions

Applicant Facing

Institution Facing

Aca

dem

ic P

rogr

amm

e In

form

atio

n


Support

ProtocolsProcess Maps ScriptsGeneric Process

MapsPolicies Process Flow



February 2016

10

The Level 1 process flow is included for reference in the text below, but the reader is referred to Appendix A for further detail.

It is important to note that in the process maps, the process to handle Offline Applications is described as notes in order to ensure that the process for handling online and offline applications is consistent.

It is also important to note that while Appendix A contains the process maps as at the date of submitting this deliverable, should any detailed work or review be done on these process maps after this date, the reader should obtain the latest digital version of the process maps from the DHET project manager.

4.3 Central Academic Programme Data Store Process Flow

The Central Academic Programme Data Store represents a critical aspect of the PSET CAS. However, the scope and impact of such a central academic programme data store spans well beyond the PSET CAS. A position paper has been prepared as part of the Enterprise Architecture phase of the project, and the reader is referred to this document.

This document then contains in Appendix B (and copied below) a process flow that could be adopted as a starting point in the design of such a central academic programme data store.



February 2016

11

4.4 Supporting Functions Process Maps

Generic process maps down to Level 2, following IDEF0 mapping principles, are attached as Appendix C and D. These are for support functions:

Finance Management (Appendix C)

Supply Chain Management (Appendix D)

These generic process maps indicate core support process functionality that should be considered in the selection of support function application systems.

4.5 Outreach & Promotion Protocol

The objectives of the Outreach and Promotion Protocol is to ensure that awareness of the CAS in created, maintained and enhanced. The mechanisms and strategies for this are described in some detail in the Advocacy & Communication Deliverable and the reader is referred to this document for further insight.

In short however,

• Outreach and Promotion Managers are responsible to plan and forecast outreach visits and handbook printing once a year and monitor and manage adherence on an ongoing basis

• Outreach and Promotion Managers are expected to achieve an Outreach and Promotion Schedule as indicated in the table below, indicating the initiative and the frequency that is expected to be achieved:



February 2016

12

Initiative Frequency

Handbook distribution to all schools January every year

Handbook distribution to all participating institutions January every year

Handbook distribution to points of presence January every year

Institution Open Days 100% of all

Career Fair attendance 50% off all (rotate)

School visits 25% off schools not covered above (rotate)

Radio interviews Once a month

Promotion pamphlets All school notice boards

Social Media Ongoing

4.6 Training Protocol

The objectives of the Training Protocol is to ensure that individuals responsible for supporting the CAS Operations and institutions using the CAS application are adequately skilled, as follows:

• The training areas covered by the Training Protocol include the CAS System and all supporting processes, policies and protocols

• Training will be conducted at a regional central training venue

• All training interventions will be evaluated through knowledge testing and reviewed by Training Supervisors

• The audience, type and frequency of expected training is as follows, indicating the frequency of induction, of refresher training and the frequency of training of super users:

Training Population Induction Refresher Super Users

CAS Employees Quarterly (seasonal) Every 2nd year Every year

Institutional Users Half yearly Every 2nd year Every year

Call Centre Agents Monthly (seasonal) Every year Half yearly

Outreach and Promotion Quarterly (seasonal) Every year Every year

Clearing House Agents Yearly (seasonal) Every year Every year



February 2016

13

4.7 Communication Protocol

The objective of the Communication Protocol is to ensure that all applicants in the CAS system is always aware of the status of his/her application.

• Methods of communication utilised include:

– Online access to the CAS system

– IVR (Interactive Voice Response)

– Push SMS

– Call Centre

– Walk-in Centres

– Post

• Communication is triggered by changes in the process flow;

• The key principle is to use communication methods with the least cost for the purpose of the communication;

• The communication responsibility of the CAS is limited to CAS operations, e.g. receiving applications to release to institutions as well as referral and clearing house activities;

• All communication between the institutions and the applicant from when released to the institution till notification of final acceptance or rejection is the responsibility of the institution (institutions can opt to delegate this responsibility to the CAS on a Service Level Agreement); and

• Typical communication message types are outlined below, indicated the timeframe in which such message is initially expected to be sent to the recipient (using least cost routing and using contact data as provided by the applicant) and starting from the point at which the status change triggering the communication occurs in the CAS system. The table also provides the timeframe at which follow-up communications are sent to applicants if no response is received to the request contained in the communication.

Communication Message – CAS Responsibility Initial comms Follow-up

comms

Application submission < 1 Bus Day N/A

Application payment < 1 Bus Day N/A

Application submitted but not paid < 1 Bus Day Weekly

Application submitted with missing supporting docs < 1 Bus Day Weekly

Application released to institution < 1 Bus Day N/A

Feedback on application from Institution (if done by CAS) < 1 Bus Day N/A

Referral for counseling < 1 Bus Day N/A

Opt-In for Submission to Clearing House < 1 Bus Day Weekly



February 2016

14

Communication Message – CAS Responsibility Initial comms Follow-up

comms

Feedback on Clearing House Submission < 1 Bus Day N/A

Application closed < 1 Bus Day N/A

Note that follow-up communications will stop after a pre-defined timeframe if no response from applicant recorded. Furthermore, if a communication is sent and a response of no-delivery is received, the communication will be re-sent using the next level in least cost routing, until no further viable communication options are available.

4.8 Call Centre Scripts

Call Centre will be used to manage incoming calls from applicants and other parties (including institutions requiring integration support), and Outgoing Calls to applicants when no other communication mechanism is available.

IVR technology will be used to handle routine calls for information requests, with options to talk to an agent.

The overall process used to handle inbound calls is illustrated below, to establish the identity and then requirement of a caller, to resolve the requirement, or refer to another entity should they be responsible for resolving the requirement, and then close the call:

Call centre agents will try to manage all calls using predetermined scripts aligned with the most appropriate way to resolve a type of requirement. It is important to note that as new requirement types are identified, additional scripts may be required.

The typical anticipated scripts for inbound calls are listed in the table below, indicating the nature of the call (or the requirement), the potential outcome (or the script used to resolve the requirement), and whether the call could be resolved through IVR.

Nature of Call Potential Outcome IVR

Application query Answer query

Application completion assistance Talk applicant through completion

Application completion Complete application form

Application status follow-up Status look-up and feedback Yes

Career guidance Refer to on to CDS

Payment query Status look-up and feedback Yes

Call taking Establish identity

Establish requirement

Resolution/Refer

Close call



February 2016

15

Nature of Call Potential Outcome IVR

Funding query Refer to NSFAS/other funding institution

Selection query Refer to Institution Yes

Accommodation query Refer to Institution

Change of mind request Process change of mind request

Cancellation request Process cancellation request

Application form request Mail application form

Access or technical query Transfer to technical department

Academic Programme Catalogue request

Email or post Academic Programme Catalogue

The overall process used to handle outbound calls is illustrated below, to introduce the call agent to the person answering the call and establish that the correct party is reached, explain the purpose of the call, confirm understanding by the person taking the call and then close the call.

The typical anticipated scripts for outbound calls are listed in the table below, indicating the purpose of the call and the key message of the call. It is important to note that where possible other communication mechanisms will be used in preference to outbound calls.

Purpose of Call Key message

Status feedback Latest status change

Outstanding payment follow-up Request proof of payment

Selection feedback Inform of selection

Close-out feedback Inform applicant of close-out

Outstanding documentation follow-up Request outstanding documentation

Application status change Inform applicant of status change

Referral for counseling Provide counseling contact info

IntroductionPurpose

explanationConfirm

understandingClose call



February 2016

16

5 Conclusion

The Standard Operating Procedures presents the expected operating procedures that will be used in the operation of the PSET CAS. It must be noted however that the detailed business requirements and functional specifications that will be developed during the Detailed Design phase may cause amendments to these proposals.



February 2016

17

A. Core Application Handling Process Maps



February 2016

18



February 2016

19



February 2016

20



February 2016

21



February 2016

22



February 2016

23



February 2016

24



February 2016

25



February 2016

26

B. Central Academic Programme Data Store Process Flow



February 2016

27

C. Finance Management Process Maps



February 2016

28



February 2016

29



February 2016

30



February 2016

31



February 2016

32



February 2016

33



February 2016

34



February 2016

35



February 2016

36

D. Supply Chain Management Process Maps



February 2016

37



February 2016

38



February 2016

39



February 2016

40



February 2016

41

Department of Higher Education and Training Post-School … Planning Management Support/DHET -...

Documents

Transcript of Department of Higher Education and Training Post-School … Planning Management Support/DHET -...