D0_100 Academic Structure Design Document v3.5
Ref #
Description
Subject Area
I-AS-001
Currently there is no standardisation to the Academic Structure
naming of various academic units.
Subdivisions within faculties are referred to
as departments, divisions and schools. There
is some consensus that having a
standardised approach to the naming of
various organisations within the University
would have some benefit, however additional
discussions need to be held to determine
what those names might be.
I-AS-002
There is also a general consensus that Academic Structure
faculties could be categorised into two or
three structures. This would facilitate more
consistent reporting for UOG. However, the
detail of the “template” structures still needs
to be determined.
I-AS-003
Although it has been agreed the basic level Academic Structure
of detail required for the Subject value is
approximately at the department level a
complete list of subjects will still need to be
developed prior to beginning the
implementation. Account needs to be taken
of departments with multiple subjects.
Subjects may also cross Faculty boundaries
and when they do so UOG/ATOS need to
determine how one department will be
defined as the lead department
I-AS-004
A final decision on whether to have one Off Academic Structure
Site Campus with several locations or have
an individual Campus for each offsite
validated programme or collaborative
relationship is required.
I-AS-005 The system(s) out of which additional Academic Structure
physical location elements, those not already
in the estates system, need to be identified.
I-AS-006 There is a need to determine which Academic Structure
Academic Organisation “owns” a student in
each year he/she is studying at UoG.
Although the student is admitted against a
specific UCAS course code, they can change
their direction of study one or more times
during the first two years of their programme.
In some Faculties these changes of study are
not currently recorded in the system until the
student makes a final declaration of their
chosen course of study in their third year.
Because of the delay in reporting this change
in the student’s academic interest, they may
be reported against a subject that has little to
Page 1 of 53
Appendix
A.doc
Ref #
Description
Subject Area
do with courses a student is actually
undertaking. Examine how subjects are tied
to department in the enrolment process
workshops.
I-AS-007
UoG needs to consider where the Science Academic Structure
Support Unit will fit into the Academic
Structure given its significance for UG
Admission
I-AS-008
A formal title for the DACE/CPD career could Academic Structures
be Continuing Education or Life Long
Learning.
Formal title Life Long Learning agreed
(13/11/2008)
It is recognised that the DACE/CPD career
crosses both UG and PG levels of study.
However the specific levels of study could be
separated at academic programme level.
I-AS-009
Feedback indicates that there are concerns Academic Structures
over the potential for confusion between
fundamental elements of terminology used by
both UoG and CS e.g. definition of UoG
Programme versus a CS Plan as well as
UoG Session versus a CS Term. Clarification
is needed as to how much visible re-naming
can occur within standard configuration.
I-AS-010
There are concerns that CS does not offer Academic Structures
flexibility to allow different access
permissions to the same screen depending
on type of student. Clarification required from
ATOS
I-AS-011
What are the implications of having two Academic Structures
Academic Organisation Structures from an
on-going maintenance point of view?
I-AS-012
There may also be a need to ensure that Academic Structures
Campus Solutions can map to other faculty-
based systems where relevant and where the
need for such systems has been clearly
established. These systems however must
have been clearly identified during the Due
Diligence phase.
I-AS-013
Examine how the values for Calendar Academic Structures
Structure have a direct effect on enrolment
and student financials workshops.
I-AS-014
Clarification as to whether or not year of
Academic Structures
programme can be calculated in a future
release of CS and if this is the case in what
will the timescale be.
I-AS-015
How would SFC funding subject group be
Academic Structures
derived for a plan
Page 2 of 53
Appendix
A.doc
Ref #
Description
Subject Area
I-AS-016
Subject change can have implications for
Academic Structures
SLC (Student Loan Company) payments.
Whenever the code held by UoG and the one
returned by the student vary there may be a
delay in the provision of a student’s load at
the start of term.
I-AS-017
Processes need to be developed to capture
Academic Structures
information for collaborative degrees,
particularly with overseas partners.
Page 3 of 53
Appendix
A.doc
D0_122 Postgraduate and Direct Admissions Document v4.5
Ref #
Description
Subject Area
I-PG-
The level of ‘automated validation’ Postgraduate Admissions
001
required in the evaluation of
applications may require a level of
customisation as it is not a delivered
part of standard CS product.
Depending on the criteria to be
applied this may be achievable
through reporting.
I-PG-
Valid reject reasons to be coded to Postgraduate Admissions
002
allow for accurate reporting and
feedback to applicants. UoG will be
free to define its own set of pre-
defined ‘reasons’ which can then be
selected during the evaluation
process.
I-PG-
A move towards the central receipt Postgraduate Admissions
003
and full processing of all
PG
applications will require structural
change within UoG to ensure
appropriate re-allocation of resources.
This will also require change
management within
Faculties/Departments of the
University that currently receive and
process all aspects of admissions
locally.
I-PG-
There are variations in practice within Postgraduate Admissions
004
Graduate Schools regarding the
process for evaluation of applications.
There was some concern over the
number times an application is
handled, which may lead to
inefficiencies and difficulties in
meeting benchmark response times.
Can a common policy be developed
and agreed across all graduate
school admissions in terms of
selection and response protocols?
I-PG-
The ability to record academic staff Postgraduate Admissions
005
against applicants is not covered by
standard functionality – this is only
available for admitted students in CS.
This will require a minor
customisation if UoG decides that the
functionality is required.
Oracle to confirm if this requirement is
likely to be addressed in a future
release of Research functionality
changes.
I-PG-
There is a potential that the increased Postgraduate
Admissions
Page 4 of 53
Appendix
A.doc
Ref #
Description
Subject Area
006
speed and ease of generating
communications to applicants could
lead to a ‘communication overload’. A
policy may be required to establish
key communication points and limits
on the level of mail generated. This
should be guided by UoG’s
communication strategy.
I-PG-
It is recognised that the introduction Postgraduate Admissions
007
of the new Points Based Admissions
system will have have an impact on
this process design. This will have to
be revisited by both Campus
Solutions and UoG.
I-PG-
The process for managing and Postgraduate Admissions
008
actioning fee waivers needs to be
defined within the admissions process
– this will be an output of the Student
Financials workshops so will need to
be reviewed in conjunction with that
document.
I-PG-
There needs to be sufficient flexibility Postgraduate Admissions
009
for role security to accommodate the
differing subject norms required to
evaluate applications. E.g. Arts
(individual PGR project) vs Science
(research group) and to support the
development of research in a
particular area.
I-PG-
UoG to clarify legal requirement of Postgraduate Admissions
010
hand-written signature for PGR letters
I-PG-
UoG is planning to establish an Agent Postgraduate Admissions
011
‘portal’ where a specific Agent (or
other external partner) can submit
applications directly and view the
progress on an individual basis.
I-PG-
Study Abroad applicants are currently Postgraduate Admissions
012
able to select their preferred course
choices as part of the admissions
process. There is no delivered
functionality to achieve this in
Campus Solutions. This may need to
be addressed through the
development of additional tables and
fields as part of the online application
process.
I-PG-
A user-friendly applicant portal is Postgraduate Admissions
013
crucial in the development of the new
system. It is not referred to in this
design document
I-PG-
Reporting – An essential requirement Postgraduate Admissions
Page 5 of 53
Appendix
A.doc
Ref #
Description
Subject Area
014
of the new system will be to allow
departments to generate their own
easily accessible admissions
statistics. This should be considered
when developing standard reports.
I-PG-
How will the interface between CS
015
and Residential Services interact and
at what stage in the admissions
process will applicants be able to
apply or secure accommodation?
I-PG-
Reference is made to the
Postgraduate Admissions
16
requirements being specified in the
ITPD, but it is not clear whether this
statement means that all those
requirements will be met (and if so is
this without customisation) or whether
the processes and requirements
detailed in the workshop output in
effect supersede the ITPD.
I-PG-
Issue added in error – same wording
017
as I-PG-011
I-PG-
Issue added in error – same wording
018
as I-PG-014
I-PG-
Issue added in error – same wording
019
as I-PG-015
I-PG-
Criminal Conviction data collection
Postgraduate Admissions
020
should mirror the UCAS application
advice with only a ‘yes’ option.
I-PG-
Issue added in error – same wording
021
as I-PG-016
I-PG-
Identification of Fee Status: Identify
Postgraduate Admissions
022
applicant’s who’s fee status
(residency) is unclear or potentially
does not correlate to other
information supplied by the applicant.
I-PG-
Development of an online applicant
Postgraduate Admissions
023
for candidates not admitted through
UCAS. This includes Undergraduate
part-time, Undergraduate overseas,
and all Postgraduate applicants. The
applications for each type student
may vary slightly.
I-PG-
Workflow notification for local
Postgraduate Admissions
024
admissions processes. Throughout
this process of ‘local evaluation’ the
Central Admissions Office will use the
dates and statuses recorded in the
system (application stack or
checklists) to track and monitor
progress and ensure that benchmark
Page 6 of 53
Appendix
A.doc
Ref #
Description
Subject Area
dates are being met. The system will
automatically identify applications
where deadline dates for activity have
not been met and automatically
generate an alert to inform the
Central Admissions Office of this
delay.
I-PG-
"PGR Offer Pack: When an offer is
Postgraduate Admissions
025
made to a Research student, there
are two key pieces to the offer. The
first is the offer of a place, the second
a financial offer. These two aspects
are sometimes condensed into one
offer letter. However, some faculties
chose to send these two offers under
separate letters.
The key issue is that the system does
not contain any fee information at the
point of admission that can be used to
create these offers.
On a related issue, there is also no
delivered component for tracking
proof of funding in Campus Solutions
Admissions. Although this is not a
requirement for the majority of
departments, there are still some
departments requesting this
information. If this functionality is
required, the scope of this
modification may need to be
extended."
Page 7 of 53
Appendix
A.doc
D0_123 Short Course Admissions Document v3.5
Ref #
Description
Subject Area
I-SC-
CS offers a powerful ‘Quick Admit’ Short Course Admissions
001
function to allow rapid
admission/enrolment in a single point of
contact. Use of this has benefits for
streamlined processing at key points, but
also has an impact on the collection of
reportable data. UoG needs to understand
the impact of using this functionality and
identify appropriate usage.
I-SC-
CS functionality does not include Short Course Admissions
002
provision to attach applicants to specific
courses or to manage ‘waiting lists’ for
courses at the application stage.
This may be achieved through custom
development of the system or through
change in business process as detailed in
section 2.1 (point 7)
I-SC-
Impact of holding data for
all registered Short Course Admissions
003
students (credit and non-credit bearing)
on the main student records system. This
will be a change in policy that will need to
be managed through correct configuration
of the system and identification of key
reporting requirements.
Note: This is seen as a benefit since it
would provide an easy way of compiling
the non credit bearing (NCB) return to
HESA. See specific comments
I-SC-
Standardisation of practice across a Short Course Admissions
004
number of areas, including management
of transition to a single system for the
admission of students.
I-SC-
Financial reporting may need to be Short Course Admissions
005
reviewed if all student activity is to be
reported and costed through a single
system. E.g. where students from different
areas are enrolled on a single course it
will be important to ensure that accurate
revenue stream management can be
achieved.
I-SC-
Should external agents, who may be a Short Course Admissions
006
regular and significant input of applicants
to CS, require a ‘data load’ process
directly into CS to be built.
This will require a level of custom activity
(although not directly a customisation to
the CS system itself) but will have the
benefit of increased efficiency and
improved service to the external
Page 8 of 53
Appendix
A.doc
Ref #
Description
Subject Area
customer.
I-SC-
There is no delivered CS functionality to Short Course Admissions
007
check course availability at the point of
admission. This is due to the fact that in
CS students are not admitted to specific
courses (modules) so the information is
not available to the system to perform this
validation.
To record specific course choices for
applicants would require the creation of a
new table within CS and screens to allow
the data entry. This would be a
customisation to the system.
I-SC-
There is no delivered CS functionality to Short Course Admissions
008
deal with debit cards or direct debits as
forms of payment.
I-SC-
Some departments/schools require
Admissions
009
information regarding criminal
convictions to be recorded.
I-SC-
Input error: issue already logged.
010
I-SC-
Input error: issue already logged.
011
I-SC-
Input error: issue already logged.
012
I-SC-
Online Application for Short
Admissions
013
Courses*. An online application
form / CRM process to capture
application, registration and
enrolment data. This data will be
loaded into standard CS
Application Data tables using
standard batch processing,
including Search/Match
processing. A member of UoG staff
will be responsible for identifying
and resolving search match
suspensions.
Page 9 of 53
Appendix
A.doc
D0-103 Undergraduate Admissions Document v3.5
Ref #
Description
Subject Area
I-UG-
Much of the interview ranking data is Undergraduate Admissions
001
captured on paper documents and
transcribed to spreadsheet manually.
UoG would like to use elements of
interview data to produce letters to
applicants to inform them why they were
not admitted. This would require either
significant (4,500 items for medics) data
entry in Campus Solutions, or
development of a standard component
interface spreadsheet.
I-UG-
Though the desire is to remove the Undergraduate Admissions
002
UCAS form entirely, there is still a
requirement, especially where
applicants are interviewed, to produce a
printed report for academic interviewers
to review.
I-UG-
The potential introduction of Post-
Undergraduate Admissions
003
Qualification Application (PQA) may
have an impact on the future design of
the Oracle UCAS localisation. Any
proposal for custom design work must
take into consideration that it might have
a limited shelf life because of this
significant change to operation
(expected in the next five years)
I-UG-
UCAS design is likely to change so that Undergraduate Admissions
004
applicants write a personal statement
per application rather than one to cover
all applications. The localisation and
any proposed development should be
robust enough to cope with this.
I-UG-
UCAS *J Data (information passed by Undergraduate Admissions
005
UCAS to institutions after applicants
have been admitted, and to be passed
to the institutions to HESA as part of the
HESA return) needs to be validated by
the Planning Office before submission to
HESA, so that only the appropriate
qualifications are returned. This does
not happen in the existing system and
consequently UoG’s qualification on
entry profile in the league tables is not
as high as it could be.
I-UG-
If paper forms are to be removed Undergraduate Admissions
006
entirely it will be necessary to provide an
enhanced screen design that will allow
(especially academic) staff to view as
much of the application as possible on a
Page 10 of 53
Appendix
A.doc
Ref #
Description
Subject Area
single screen. This will require a
customisation to the standard product.
I-UG-
Process speed is currently very good. Undergraduate Admissions
007
The UCAS cycle starts on 15
September, and at this stage, decisions
are normally returned to UCAS for the
main group (i.e. not special cases: 80%
of apps) within 24 hours of receipt. The
peak loading coincides with the general
UCAS application closing date of 15
January. All decisions for the main
group are returned by the end of the
third week in February.
This efficiency needs to be maintained
in Campus Solutions operation.
Additionally the University is targeting a
significant increase in applications (up to
50%) which will have an impact on the
processing of applications as the
University moves towards being a more
selecting institution. The need to avoid
over-recruitment must be taken into
account when considering efficiency of
the process.
I-UG-
A decision is required on whether UoG Undergraduate Admissions
008
wishes to add a custom algorithm to
maintain the speed of turnaround of
applicants.
There is a trade-off between
implementing a system with no
algorithm and the attendant cost of fully
manual activity, and the benefit that
might be obtained in speed of
turnaround by having a level of
automation in this part of the UCAS
application process.
The customisation should not be
undertaken just because it matches or
exceeds what the University currently
does, but that might become a key
consideration.
Additionally, this is a complex
customisation that it may not be possible
to develop and test in time for the 2009
Admissions process.
A full cost-benefit evaluation would be
required to determine whether there is
advantage in one approach or the other.
Page 11 of 53
Appendix
A.doc
Ref #
Description
Subject Area
I-UG-
If UoG decides to proceed with a custom Undergraduate Admissions
009
algorithm for offer making, consideration
should be given as to whether there is
any means to simplify the types of offer
made, as well as the variety of types,
without sacrificing any of the benefits
achieved from making more complex
offers.
Where complex conditional offers are
deemed necessary the offer making
process should facilitate this.
I-UG-
UoG requires confirmation that
Undergraduate Admissions
010
automated offer to results matching
based on Assessment Board Linkage
will be delivered as part of the standard
product in time for the 2009 Admissions
process. If not, an alternative process
for confirming offers will need to be
established.
I-UG-
Confirmation is required that near-miss Undergraduate Admissions
011
management (one grade down
processing) will be delivered as part of
the standard product in time for the 2009
Admissions process. If not, an
alternative process will need to be
identified.
Also, the process of near-miss
management needs to be investigated
further. For example, should criteria
other than ‘one point down’ be
considered or should applicants from
clearing be considered before near-miss
applicants?
I-UG-
There is a requirement to track whom a Undergraduate Admissions
012
Disclosure Scotland form has been sent
to. The UoG has to establish whether to
continue to record this information
manually against the applicant’s record
or to use a bar-code reader to scan the
number from the form and store it.
Using a bar-code reader would require
an interface to scanner software and
some customisation to ensure the data
is captured correctly.
Page 12 of 53
Appendix
A.doc
Ref #
Description
Subject Area
The number of forms distributed by all
interested parties in the institution is a
key consideration, as is the extent to
which Disclosure Scotland intends to
audit its processes
I-UG-
If the Disclosure Scotland process Undergraduate Admissions
013
determines that the applicant has a
disbarring criminal record, then the
application, including any outstanding
offer, will be withdrawn. UoG needs to
establish if this is holds true for all
faculties concerned.
I-UG-
Standard Campus Solutions does not Undergraduate Admissions
014
have the means to allocate applicants to
interview slots in bulk. Whether this
could be addressed by use of the
standard population update tools or a
custom process is required needs to be
established.
I-UG-
UoG should consider whether do Undergraduate Admissions
015
manage the uploading of UKCAT/LNAT
scores centrally or locally.
I-UG-
It should be established that the Undergraduate Admissions
016
Campus Solutions reporting functionality
will adequately satisfy the UoG
requirement of alerting admissions
officers to their UCAS transaction errors
when they log on to the system.
I-UG-
UG admissions policy needs to be Undergraduate Admissions
017
developed in line with goal to be a
selecting university including moving to
a gathered field of all applicants before
making decisions; the role academic
expertise/ vs professional admissions
staff in reviewing personal statements;
transparency in using additional tests
and how to make decisions between
competing students who have achieved
over the minimum tariff in “general”
faculties.
Page 13 of 53
Appendix
A.doc
D0_114 - W20 Alumni Process v3.3
Ref # Description
Subject Area
I-AL-
There is no table seating functionality in Alumni
001
Contributor Relations.
I-AL-
There is no Gift Aid functionality in Alumni
002
Contributor Relations. It is important that
any developed functionality includes the
ability to process tax claims following
HMRC rules as well as the processing of
tax refunds where tax has been claimed
in error.
I-AL-
Contributor Relations does not seem to
Alumni
003
have been adopted by any other UK
universities. Examples from other
institutions - whether in the UK or the
USA - would provide a better
understanding of the application.
I-AL-
There is a requirement to record
Alumni
004
information on fund-raising prospects –
ie. individuals identified as potential
donors, whether for legacies or for major
gifts. For instance, the application
should have the facility to record the
prospect’s area of interest, the fields
they are likely to support and the
approximate level of gift we expect. This
would apply also to potential legators.
Information is required on how the
system would do this.
I-AL-
Confirmation is needed that the
Alumni
005
functionality will exist to manually assign
a specific donor’s gift level with each
contribution or pledge made to a given
campaign as well as automatically do it.
Page 14 of 53
Appendix
A.doc
D0-108 Assessment Document v3.3
Ref #
Description
Subject Area
IS-A-
(25/2/09 - revised wording para 2)
Assessments
001
UoG to agree CS as being sole system
for storage and publication of final
grades.
Depends on decision on 003 there will
be a need for initial calculation and
evaluation to be done in departments
outside Campus Solutions.
(original )
should local systems (e.g.
spreadsheets) still be used for initial
calculation and evaluation?
IS-A-
The University should investigate to
Assessments
002
what extent Moodle is being used to
record detailed assessment
information and whether departments
using it in this way are using other
local systems at the same time.
IS-A-
UoG needs to agree policy on level at Assessments
003
which grades should be recorded in
CS and/or published to students.
IS-A-
Maintenance of assignment details Assessments
004
(due dates etc) requires resourcing –
departments need to identify where
responsibility for this task lies.
IS-A-
Interfaces to existing assignment Assessments
005
submission systems may be required
in order to transfer submission details
to CS.
IS-A-
University to establish which level of Assessments
006
staff should have access to a student’s
full academic records.
IS-A-
The University should agree what level Assessments
007
it is prepared to allow the use of local
systems for capturing complicated
information that Campus Solutions
cannot accommodate Does this
matter? Is it not more important that
the University takes a view on what
information needs to be entered into
CS across the institution? Is this
already captured in Issue 002?
IS-A-
It is not proposed to record external Assessments
008
examiner details on CS. UoG should
agree if recording specific details of
which externals had moderated scripts
is required.
Page 15 of 53
Appendix
A.doc
Ref #
Description
Subject Area
IS-A-
Gradebook is intended to be used Assessments
009
primarily by academic staff. UoG to
consider if there is merit in developing
policy to encourage/enforce academic
entry of marks. Some development of
system may be required to facilitate
administrative marks entry (which may
be required regardless).
IS-A-
CS does not have delivered ‘mark Assessments
010
history’ records so development may
be required. UoG to confirm the level
of history required (e.g. all mark
changes or just ‘last’ mark).
IS-A-
UoG to determine need for consistent Assessments
011
format for examination board papers or
screens to display details during board
meetings – should variations be
required and developed? Adoption of a
consistent approach will help UoG to
avoid excess maintenance costs,
replication of effort by staff etc.
IS-A-
UoG policy needed on the recording of Assessments
012
‘notes’ against course grades. What
type of information should be
recorded? Is it advisable to record
information that is not intended to be
seen by students?
IS-A-
UoG to decide if students should have Assessment
013
access to all weighted component
marks before the ratified course grade
is published.
IS-A-
Customisation of the Gradebook Assessments
014
calculation algorithms will be required
in order to facilitate the various
aggregation methods in use. It will also
be necessary to clarify the aggregation
method to be used for each course –
justifying where a course differs from
the Code of Assessment.
IS-A-
UoG to consider whether it wishes to Assessment
015
establish a policy for recording
changes to overall grades.
IS-A-
There is no delivered functionality for Assessments
016
resit assessments in CS. This will
require a substantial amount of new
development and customisation to
achieve. UoG will also need to clarify
the regulations applying to resit
assessments to ensure that rules and
systems can be developed and applied
consistently by the system.
Page 16 of 53
Appendix
A.doc
Ref #
Description
Subject Area
IS-A-
The delivered rules and processing for
Assessments
017
determining final awards will not meet
UoG requirements. It will require the
development of new custom rules
engines and processes to enable the
system to calculate results using UoG
regulations.
IS-A-
Campus Solutions has no delivered
Assessments
018
functionality to upload marks in the
form of spreadsheets. Other
institutions have designed methods of
uploading marks into CS so this is
technically possible. This facility is
available currently in GU and is a
requirement of the new system –
Oracle to take this on board.
IS-A-
Need to simplify the resit process
Assessments
019
described in the document (2.9)
IS-A-
Gradebook - Grade Format Changes:
Assessments
020
Vanilla Gradebook will not accept
marks to be entered using the current
UoG Code of Assessment –
Gradebook will accept only numeric
grades and the UOD Code of
Assessment requires assignment to be
marked using the alphanumeric grades
(A1, B2, C3 etc).
In order to allow Gradebook to accept
this marking scheme it will be
necessary to customise the marks
entry pages and records, and for
Gradebook to convert the grade
entered into the appropriate
‘aggregation score equivalents’
numeric mark for the purpose of
calculating an overall cumulative mark
for the assessment.
IS-A-
Student Centre View of Final Degree
Assessments
021
Results. Students should ideally be
able to access final degree results
through Student Centre however this
information is not currently displayed in
Student Centre.
Page 17 of 53
Appendix
A.doc
D0_104 Course and Prog Mgmt Document v4 .4
Ref #
Description
Subject Area
I-CP-001
University to review the extent to which Student Records
further development of the generic
degree regulations is possible, and the
requirement for additional regulations
to be allowed.
I-CP-002
UoG to consider how:
Student Records
• the process of creating a
framework for advisement rules
pertaining to each Plan
• extraction and transfer of existing
data on the rules for pre and co-
requisites
are undertaken, whether by an
interface or manually, and where the
responsibility is to be located for doing
so.
I-CP-003
More detailed analysis of the precise Student Records
nature and configuration of the
academic advisement rules for UoG
programmes is required. UoG to
identify who will be responsible for this.
I-CP-004
The creation and maintenance of the Student Records
complex advisement rules is an
additional system task that does not
have a similar parallel in current UoG
processes. This needs to be
recognised as a new administrative
task (unless significant customisation
work is undertaken).
UoG needs to take a number of related
decisions on the following aspects of
rules for academic advisement:
• to determine levels of access and
security
• to identify the appropriate staff
who will have responsibility for the
creation and maintenance of rules.
• to identify the specialist training
requirements.
• to manage this information in a
systematic way to preserve the
integrity of the system.
I-CP-005 DACE
course
approval process for Student
Records
Page 18 of 53
Appendix
A.doc
Ref #
Description
Subject Area
non-accredited and low credit courses
to be investigated against proposed
design to determine whether special
requirements will continue to be
required.
I-CP-006
UoG to evaluate the best option for the Student Records
management of the programme and
course approval process, either within
CS or to customise an interface with
PIP.
• Initial cost, long-term cost of
ownership, resources and risk all
require investigation in order that a
full assessment can be made and
an appropriate decision made.
• UoG to consider the point at which
continued development of PIP
should cease, in order to establish
a stable system to which an
interface can be built.
• UoG and ATOS to identify the
extent of development and
customisation to create this
interface and ensure transfer of all
relevant data between systems.
• UoG to evaluate the implications of
continuing with an in-house
solution in this area yet seeking to
replace others.
I-CP-007
Although academic staff can be Student Records
associated with a ‘Plan’ (i.e. a specific
award title) within the delivered
Campus Solutions functionality, a
customisation may be necessary to
link particular years of study with
members of staff. UoG to investigate
extent of demand in support of such
customisation.
The issue of how to assign staff to
programmes in undergraduate
Medicine also requires consideration.
I-CP-008
UoG to consider the extent to which Student Records
external examiner information should Senate Office
be recorded on the system and
whether external examiner
management should continue to take
place out with the central system,
given that CS cannot deliver full
functionality.
UoG to investigate the extent of
Page 19 of 53
Appendix
A.doc
Ref #
Description
Subject Area
interfaces between CS, the bespoke
external examiner system and HR
which are required, to improve the
overall management of external
examiner activity.
I-CP-009
The level of course scheduling Student Records
information required on Campus
Solutions is significantly greater than is
currently recorded centrally. This
needs to be reviewed to identify
responsibility for ‘ownership’ of this
data and for how the maintenance of
the data is to be resourced.
I-CP-010
UoG to consider:
Student Records
• the amount of class scheduling
information to be recorded and
displayed
• the time lines for allocation of
teaching responsibilities in relation
to scheduling of classes
• the resource implications required
for the transfer of teaching space
data into CS, whether by manual
entry or by an interface.
•
I-CP-011
ATOS to investigate the capabilities of Student Records
the version of CMIS currently used and
the options for developing an interface.
(It is noted that the CMIS supplier is in
the process of developing APIs to
enable interfaces to be built, although
timescales are unknown at present).
I-CP-012
UoG to review the management and Student Records
systems used for allocation of teaching
space and course scheduling.
I-CP-013
The ‘ownership’ of the Schedule of
Student Records
Classes within Campus Solutions will
need to be determined as the
maintenance of this data is key to all
enrolment activity.
I-CP-014
UoG to consider the extent to which Student Records
specialised class allocations are Student Experience
required, as the CS way of managing
these is complicated. It cannot support
certain discipline-specific methods of
class allocation currently in use, which
will necessitate continued manual*
intervention if required. UoG to
consider how class allocation can be
undertaken in such cases. *UoG to
Page 20 of 53
Appendix
A.doc
Ref #
Description
Subject Area
investigate whether CMIS has
functionality to allocate students to
groups using departmental criteria.
I-CP-015
UoG and ATOS need to explore the Student Records
detailed customisation that would be
required to automate the transfer of
assessment information and
weightings from PIP to CS, both when
courses are created and amended.
UoG to identify the resource which
would handle this process if it is to be
undertaken manually.
Limited access to data that requires
approval will also be necessary.
I-CP-016
UoG to review course code structure:
Student Records
• to develop a logical coding scheme
that will fit the Campus Solutions
field requirements and which will
enable degree regulations to be
adhered to.
• to enable accurate searching by
SCQF level, given that CS does
not record ‘level’ as a standard
searchable attribute.
• to be more user-orientated.
• Recoding should take account of
best practice to develop a structure
which is robust in the long term
(e.g. by evaluating the risks and
precedents associated with
embedding the ‘level’ within the
course code)
UoG to consider whether
customisation to make ‘level’ a
searchable attribute, in a separate field
is required.
I-CP-017
Issue no not used
I-CP-018
Issue no not used
I-CP-019
UoG to consider the extent to which Assessments
specialised class allocations are
required. The CS way of managing
this is complicated.
I-CP-020
DACE course approval process for Assessments
non-accredited and low credit courses
to be investigated against proposed
design to determine whether special
requirements will continue to be
required
I-CP-021 "Auto-Creation of Assessment
Information. To provide automated
Page 21 of 53
Appendix
A.doc
Ref #
Description
Subject Area
(17/2/09) process for creating course
assignment information or building the
components of assessment in Campus
Solutions.
Campus Solutions will require
assessment types and weightings to
be recorded in order to allow
assessment marks to be input directly
into the system and reported to
students (if required by UoG).
As this information is collected at the
point of an initial course proposal it
should be available to be created in
Campus Solutions at that point
however there is no delivered
automated process for creating the
course assignment information or
building the components of
assessment in Campus Solutions.
If this information is currently created
and held in PIP, then could it not be
part of the interface between CS and
PIP (assuming this is the preferred
option for managing all course and
programme information)
We need to also consider the role of
Moodle for creating assignment info."
Page 22 of 53
Appendix
A.doc
D0_111 Exam Management Document v4.4
Ref #
Description
Subject Area
I-EM-001
ATOS to confirm whether CS has functionality to Exam Management
handle the requirements of all disciplines with
regard to creation and updating of course
examination data.
I-EM-002
University to confirm grade which will signify that
Exam Management
amended
students have been offered the resit opportunity
as a first attempt.
I-EM-003
University to review processes for audit of student Exam Management
amended
enrolment data on central system and consider a
range of developments to encourage proactive
checking of data by students and staff. Policy
change on the time period during which course
changes can be effected, may be necessary.
I-EM-004
A two way interface to CMIS exam timetabling Exam Management
system is required, to support CS functionality
regarding storage of exam scheduling data.
I-EM-005
ATOS to confirm the need for, and extent of, Exam Management
amended
customisation to create a page which will enable
students to view details of their personal
examinations online through their Student Centre,
along with a range of specific supporting
information about the University’s examinations.
I-EM-006
University to review of the role of VALE in the light Exam Management
of the implementation of Campus Solutions, given
the highly specific requirements of the Medical
School.
I-EM-007
ATOS to provide a more detailed analysis of the Exam Management
amended
different configuration options and recommend the
optimum solution so that UoG has a clearer
understanding of the extent of development
required for detailed tracking and recording of
exam paper submissions, for which Registry is
responsible.
I-EM-008
As there is no CS functionality for secure Exam Management
amended
circulation or submission of exam papers,
University should investigate the use of
Documentum for these purposes so that if
possible, it becomes part of the process design.
I-EM-009
Functionality for recording or managing invigilation Exam Management
amended
recording is limited in CS, but may be possible
through configuration and/or modification. As an
alternative, University may consider that using
CMIS to centrally record this data is more
advantageous, depending on future use of
externally appointed invigilators.
ATOS to provide a more detailed analysis of the
different configuration options and recommend the
optimum solution so that UoG has a clearer
Page 23 of 53
Appendix
A.doc
Ref #
Description
Subject Area
understanding of the extent of development
required.
I-EM-010
As more detailed candidate lists can be produced Exam Management
through CS, University to consider whether the
use of such lists should become mandatory for all
exams in future.
I-EM-011
University to consider:
Exam Management
• whether the ‘double’ approval arrangement
(SDS and Clerk of Senate) should continue;
• Whether the standardised list of valid
arrangements for students with special
examination requirements should be reviewed
to ensure there is not an unnecessary
proliferation of arrangements;
• A standardised coding system is required,
which will streamline the use of free text
phrases as these currently contribute to over-
complications for departments in the setting
up of special arrangements.
I-EM-012
University of Glasgow to consider the role of Exam Management
Registry in special examination arrangements,
given the extent of change management in this
area.
I-EM-013
ATOS to provide a more detailed analysis of the Exam Management
new
extent of development required to take account of
linked exams/simultaneous scheduling
requirements.
Noted that there are a number of ‘Course
Attribute’ fields that could be configured to
achieve this, as well as to allow reporting and
interfaces to the timetabling system, to take
account of this data.
I-EM-014
UoG to identify the point at which the credit value Exam Management
new
being undertaken by visiting students is known (if
less than the 'full' credit value) and who will be
responsible for updating the system.
I-EM-015
Training requirements for departments to be Exam Management
new
defined so that the complexities in exam
arrangements (such as linked or ordered paper
exams) can be successfully achieved.
The Registry role in offering guidance to
departments in relation to exam data is significant
and should not be lost.
Page 24 of 53
Appendix
A.doc
D0_110 Graduation Document v4.5
Ref #
Description
Subject Area
I-GR-001
The current version of Campus Graduation
Solutions (v9) does not include
bespoke functionality for ‘Graduation
Ceremony Management’. It is
possible to use the delivered ‘Events
Management’ functionality but this
will require a level of customisation
and does not provide automated
processes to transfer students into
‘Events’ lists.
Oracle has ‘targeted’ functionality in
this area for a future release but
details of the timing of this, or the
scope of functionality to be included,
are not yet known.
I-GR-002
UoG to consider a consistent policy Graduation
for registration of students with
outstanding assessments.
If students need to be assessed
within an academic session should
they be required to register for that
session?
I-GR-003
Delivered ‘apply for graduation’ Graduation
functionality allows all students to
apply – a customisation may be
required to ensure that only eligible
students can do this.
Alternatively, it may be possible to
manage this through security roles.
I-GR-004
UoG to determine the implications of Graduation
students ‘missing’ the deadline to
apply for graduation (e.g. reducing
ticket allocations or making a ‘late’
charge).
The system would need to know how
to process these applications.
I-GR-005
Does the University require a Graduation
physical, signed record of attendance
at the graduation ceremony for
archiving purposes? Could
registration at the ceremony be
recorded electronically?
I-GR-006
UoG may wish to review the format Graduation
and content of formal graduation
documents and stationery –
particularly with regard to improved
security measures and production
methods.
Page 25 of 53
Appendix
A.doc
Ref #
Description
Subject Area
I-GR-007
UoG to review recording of University Graduation
Prizes & Awards.
I-GR-008
UoG to decide if allocation of Graduation
students to graduation ceremonies
should be an automated process.
Customisation of Campus Solutions
may be required.
I-GR-009
Do additional tables need to be Graduation
created in order to cope with the
requirement for dates on parchments
to be in Latin?
I-GR-010
UoG to decide on a policy for dealing Graduation
with records of students who are
sitting on the Student Records
System (SRS), as ‘qualified to
graduate’, but have not paid the fee
to become a member of the General
Council, and have therefore never
graduated, either in person or in
absentia.
I-GR-011
No mention is made of the Graduation
hierarchies of presentation of
degrees within a ceremony. There is
a prescribed order for faculties with
the oldest faculties being presented
first. There is also a hierarchy of
programmes
I-GR-012
Intended profession has been
Graduation
recorded in the General Council
Register for years. Did someone
take a decision not to record this or
has it been accidentally missed?
I-GR-013
Diploma Supplements: There is no
delivered functionality to support the
production of Diploma Supplements
– this is a UK requirement for all
students.
The Diploma Supplement is an
expanded transcript that includes
details on the institution and the
programme in addition to the
student’s own record
Page 26 of 53
Appendix
A.doc
D0_121 - W13b Placements Process Document v4.5
Ref #
Description
Subject Area
I-PL-001
Educational placements are Placements
managed through a external,
system known as Practicum.
This is a national requirement.
UoG to consider the costs and
benefits of an interface between
CS and Practicum to minimise
the effort of maintaining
placement information in two
systems.
I-PL-002
UoG requires a self service Placements
mechanism to collect key data
for self-proposed placements.
Currently there is electronic
functionality for MBChB students
to provide details regarding
these placements.
However, there is no
mechanism in CS self service to
collect this information. Using
the system as delivered, staff
would have to key in data
regarding the self proposed
topic, as well as all contact
details pertaining to the
placement.
It was suggested at the
workshop that a future delivery
of CS may offer functionality to
allow the configuration of data
collection pages and UoG needs
clarification/confirmation on
whether this will be available in
V9.1.
Current CS functionality will
require manual processing of
data by staff which is currently
undertaken by students; which
does not deliver any business
benefit.
I-PL-003
UoG requires a mechanism to Placements
enable placement organisations
to key in an evaluation
document. Currently there is
electronic functionality for
MBChB students to provide
details regarding these
placements. There is a need to
extend this for other subjects
Page 27 of 53
Appendix
A.doc
Ref #
Description
Subject Area
(e.g. Education).
CS advises that this requirement
can be fulfilled by configuring
security in the system for key
members of placement location
staff. However, there may be
training implications with this
approach due to the high
number of placement providers.
It was suggested at the
workshop that a future delivery
of CS may offer functionality to
allow the configuration of data
collection pages and UoG needs
clarification/confirmation on
whether this will be available in
V9.1.
Current CS functionality will
require manual processing of
data by staff, which does not
deliver any business benefit.
I-PL-004
Currently, very little information Placements
on previous placements can be
provided to Veterinary students
because of data protection in
relation to placement locations.
Currently, these are requested
to check a box if their
information can be released.
It was suggested that an ‘opt-
out’ box to decline the release of
information may legitimately
generate more information for
current students.
UoG to pursue this option with
the Data Protection office to
ensure the approach is legal.
I-PL-005
The means by which the
Placements
full list of school
placements undertaken
can be captured on the
University transcript
requires investigation by
ATOS, as this activity is
currently very labour
intensive and
independently produced.
I-PL-006
CS should include
Placements
functionality to produce an
Page 28 of 53
Appendix
A.doc
Ref #
Description
Subject Area
electronic report which
shows the full history of
student placements, as
this activity is currently
very labour intensive.
I-PL-007
A link will be required
Placements
between CS and VALE to
take account of the
extensive amount of data
which is held in VALE’s
document management
system.
I-PL-008
UoG to evaluate how the
Placements
Nursing Placements,
which are administered by
Glasgow Caledonian
University, can be
managed in a more
electronic means than at
present.
I-PL-009
UoG to identify the types
Placements
of placement activity
which should be recorded
in the University
Transcript, recognising
that PDP recording is
appropriate in some, but
not all cases;
I-PL-010
ATOS to provide a means
Placements
of recording the location
of different student
placements, to ascertain
the spread of
geographical location for
insurance and strategic
objective purposes.
I-PL-011
UoG to consider how the
Placements
appropriate levels of risk
assessment, duty of care,
insurance cover and
quality assurance in
regard to different types of
placements can be
managed electronically.
I-PL-012
ATOS to identify a means
Placements
by which CS can manage
the many locations which
apply within each of the
multiple cohorts of the
MBChB programme.
Page 29 of 53
Appendix
A.doc
Ref #
Description
Subject Area
I-PL-013
ATOS to advise whether
Placements
the process for recording
other types of placements
(e.g. European and
international exchanges)
requires further
discussion.
I-PL-014
A regular feed of data is
Placements
required to keep student
details up to date in
systems such as VALE
and Practicum.
I-PL-015
UoG to compare the
Placements
document management
systems of VALE and
Documentum for
assurance that MBChB
requirements can be
managed through
Documentum.
Page 30 of 53
Appendix
A.doc
D0_109 Student Progression v4.3
Ref #
Description
Subject Area
I-PR-001
Campus Solutions does not contain Progression
delivered functionality to process student
progression. This will require the
development of a significant custom built
process by the University in order to
automatically process student
progression.
I-PR-002 Investigation
will
be required to confirm if Progression
all UoG assessment / progression rules
can be created in academic advisement
rules.
I-PR-003
There are differences in progression rules Progression
/ requirements between faculties/ depts.
even for the same degrees. This causes
lack of clarity for students and will
complicate the configuration of automated
processing. The University may wish to
review the needs for increased
standardisation.
Note: There is variation in
faculties/departments as to whether
grades need to be attained at a first sitting
or whether a re-sit grade is acceptable.
I-PR-004
Individual subjects currently have very Progression
varied and different progression
requirements (not just the courses that
are pre-requisite). The ownership of, and
responsibility for, maintaining these rules
on CS will need addressing.
Note: A lot of the information about course
pre-requisites already exists in PIP but if
there is not an interface between PIP and
CS, would this mean entering information
twice in two systems? This could lead to
errors in data and consequently
inaccuracies in progression rules.
I-PR-005
Development of a system to manage the Progression
UoG specific honours progression
process will require a significant custom
development on CS.
I-PR-006
Adding the facility for students to make Progression
provisional choices of honours options as
part of the honours progression may
require further customisation.
I-PR-007
The practice of allowing students to Progression
transfer back to honours after Level 3 is
limited to specific subjects. To manage
this is CS will require an additional level of
customisation – the University may wish
Page 31 of 53
Appendix
A.doc
Ref #
Description
Subject Area
to decide if this is justifiable for a small
number of subjects. Alternative ways of
managing this process could be found –
with the outcome still being recorded on
CS.
I-PR-008
If such a system is introduced it will have Progression
to be able to take account of the fact that
some students will not have third year
honours results until midway in their fourth
year when grades obtained overseas are
converted (e.g. approximately 50% of LLB
students).
I-PR-009
A decision is required on whether the Progression
functionality provided by the CRM module
or ‘comment codes’ is sufficient for UoG’s
needs in terms of logging, monitoring and
reporting on formal appeals and
complaints, or is a customisation
required?
Page 32 of 53
Appendix
A.doc
D0_105 Registration and Enrolment Document v3.3
Ref #
Description
Subject Area
I-RE-001
A decision is required on whether to Registration and
use the portal provided by Campus Enrolment
Solutions or whether to develop a
UoG portal in line with other
University portal developments.
The use of a portal is key to some of
this proposed design. Although these
parts of the design could be removed
without affecting the later process it
would potentially reduce benefits to
be gained.
I-RE-002
UoG will need to agree at which Registration and
stage in the admissions process Enrolment
prospective students should be given
access, and where the responsibility
lies for the issuing and auditing of
accounts.
I-RE-003
The ‘Registration’ process is not Registration and
delivered as part of Campus Enrolment
Solutions v9.0, it is proposed
functionality for a future release and
it is not currently known whether this
will be available in time
implementation of this project
. If it is
not delivered by Oracle in UoG
timescales, it will be necessary for
UoG to develop a custom version.
I-RE-004 The production of a single, Registration and
centralised Class Schedule to Enrolment
support enrolment will require a full
review of UoG policy and processes
for the ownership and timetabling of
academic teaching space.
I-RE-005
An online payment provider is Registration and
required to support payment of fees Enrolment
through Campus Solutions
I-RE-006
It is possible for much of the basic Registration and
course selection guidance and audit Enrolment
currently undertaken by advisers to
be automated through Campus
Solutions. UoG may wish to discuss
the precise role of the adviser and of
the ‘Faculty Approval’ process.
I-RE-007
The nature of the interface between Registration and
Campus Solutions and the
Enrolment
University’s ID card system needs to
be reviewed to ensure that data can
be passed to support this process.
Page 33 of 53
Appendix
A.doc
Ref #
Description
Subject Area
I-RE-008
A customisation will be required to Registration and
allow recording of the ‘Faculty Enrolment
Approval’ and ‘Registered’ status on
Campus Solutions. This will require
the creation of new tables and
screens to hold and maintain this
data.
I-RE-009
There is no delivered process for the Registration and
automated allocation of advisers to Enrolment
students.
If this is a requirement for
UoG it will require a customisation.
I-RE-010
There appears to be a lack of clarity Registration and
or consistency over the
Enrolment
handling/application of sanctions for
students with outstanding debts or
other issues. If UoG wishes the
system to apply sanctions
automatically there will need to be
agreement on standard policy,
I-RE-011
There is no delivered functionality in Registration and
Campus Solutions to enable students Enrolment
to make appointments directly with
advisers. If this is a requirement for
UoG it will require a significant level
of customisation.
I-RE-012
Currently a student wishing to Registration and
change course requires approval Enrolment
before it can be confirmed on the
system. However, in Campus
Solutions a change of course is
effective as soon as the student
makes the change via the Student
Centre. If the approval process is to
be maintained, it may be necessary
to build a customised process to
allow the student to make a change
but to delay full processing until an
adviser gives final approval.
I-RE-013
UoG to consider whether the Registration and
‘Planner’ functionality should be Enrolment
made available to new students
I-RE-014
There is no delivered functionality Registration and
within Campus Solutions to mark a Enrolment
group of students as ‘Faculty
Approved’ in bulk. This process
requires a customisation to the
system.
I-RE-015
UoG to consider the setting of a Registration and
deadline date after which students Enrolment
will be unable to make any course
changes.
Page 34 of 53
Appendix
A.doc
Ref #
Description
Subject Area
I-RE-016 The current registration and
Registration and
enrolment process is used to confirm Enrolment
the student is physically at the
University as this is a statutory
requirement of the institution. UoG
should consider if it is still practical to
use the process for this purpose and
if so, agree on which stage
constitutes the student as being
physically at the University. If the
process is not deemed suitable, the
University needs to identify an
alternative means to meet the
statutory requirement.
I-RE-017
A decision is required on the Registration and
terminology to be used for each of Enrolment
the Registration stages, namely pre-
registration, faculty approval,
registration and class enrolment.
I-RE-018
Once the Registry has decided that a Registration and
student has not met the conditions Enrolment
for full enrolment, and is no longer
entitled to be provisionally registered
a decision needs to be made on what
to do with their record. A suggestion
is to remove the pre-registration flag.
This can be done by using the
delivered ’Cancel Enrolment’
functionality in Campus Solutions
which cancels all programme and
course information for the student for
a specified academic session.
However, if a student subsequently
finds themselves in a position to fully
register would they be expected to
complete the stages of pre-
registration and faculty approval
again?
I-RE-019
UoG needs to establish how other Registration and
information / materials are to be Enrolment
disseminated to students if
attendance at class enrolment
sessions is to be removed from the
process.
I-RE-020
Although Campus Solutions can Registration and
auto-allocate students to groups it Enrolment
cannot assign students to
courses/classes based on very
specific criteria e.g. Medicine
organise groups of students into
separate 5 week blocks and wish to
ensure that students are allocated
with a different selection of students
Page 35 of 53
Appendix
A.doc
Ref #
Description
Subject Area
in their subsequent 5 week blocks.
I-RE-021 Enabling students to enrol
Registration and
themselves on
Enrolment
labs/tutorials/seminars etc as part of
the pre-registration process gives
rise to the problem of certain
students, who require taking a certain
instance of a class due to other
timetable commitments, being unable
to take a class because the instance
they require is full. Similarly,
students who are perhaps delayed in
making their class selections,
through no fault of their own, may
find themselves unable to take the
subjects they wish because the
classes are full.
A decision is needed on when to
open class enrolments so the above
problems are minimised.
I-RE-022 Uploading
Student
Photographs.
Registration and
Create page to allow students to Enrolment
upload photograph for use on
Page 36 of 53
Appendix
A.doc
D0_120 Reporting v3.3
Ref #
Description
Subject Area
I-RP-001 Reporting
Strategy - Although there are Reporting Strategy
many individual issues that will be
highlighted in the course of the
document, the overarching requirement
that came out from the workshop was
need for UoG to develop a
comprehensive reporting strategy.
ACTION – further session to be
scheduled at senior management level
to determine UoG Reporting Strategy.
I-RP-002 Operational
Measures - UoG requires to Management Reporting
identify internal KPIs to evaluate
efficiency and effectiveness of the
business and related processes. and
their support of the strategic plan. It is
recommended this be conducted as part
of the implementation of any Business
Intelligence Solution.ACTION – further
session to be scheduled following I-RP-
001 to determine requirements.
I-RP-003
UoG to identify tools & architecture Reporting – All Levels
required to support Reporting activity at
all levels
Currently, there is a significant amount
of ad-hoc querying and reporting done
at UoG using the Bi-Query tool. It was
agreed that it is a requirement for the
project to provide a new tool to deliver
as a minimum existing functionality while
supporting a standardised framework
However, it was not agreed the best
approach for delivering this functionality
nor the deployment across UoG.
I-RP-004
UoG will need to make a number of Transactional Reporting
decisions regarding how existing
transactional reports will be created
during the implementation.
Is the existing transactional report still
required in the system and who will be
responsible for re-developing it?
I-RP-005
How will transactional reports be
developed post implementation?
This decision will also impact on those
made regarding ad hoc reporting and
should be incorporated into the
University’s overall post implementation
support strategy.
I-RP-006
UoG to establish security requirements
Reporting – All Levels
for reporting and user groups to be
Page 37 of 53
Appendix
A.doc
Ref #
Description
Subject Area
identified following I-RP-001 & 002
Page 38 of 53
Appendix
A.doc
DO_112 Research Document v3.4
Ref #
Description
Subject Area
I-RS-001
There is no standard policy regarding Research
the tracking of attendance for Research
Students. Currently, each department
has its own policy and procedures for
this activity.
UoG needs to determine if a central
policy is required and, if so, what that
policy is.
I-RS-002
In cases where a student is taking a Research
taught course elsewhere, the UoG
owning department may not know
details about the course until transcripts
from the other university are produced.
Transfer of information between
institutions is currently poor. UoG should
be better at providing other universities
(e.g Heriot Watt) with details of students
that are registered and better
information on results and confirmation
of successful completion is required in
return.
This situation should benefit from the
use of improved reporting and self
service functionality. However the exact
details of the data exchange will need to
be determined during the detailed
design phase.
I-RS-003
The level at which communication with Research
students is tracked was raised as a
workshop issue. Currently the amount of
detail varies from department to
department and supervisor to
supervisor.
It was suggested that as the input and
maintenance of the data will be easier in
the new student system, that a policy
and procedure regarding this activity be
developed by UoG.
I-RS-004 The approval processes vary
Research
significantly from faculty to faculty. In
order to automate this process and take
full advantage of the possibilities
provided by workflow, a level of
standardisation, at least at high-level,
will need to be achieved.
I-RS-005
Will Oracle be delivering an online Research
application form for Research
Scholarships in a future release of the
product or will UoG build an online
application or will paper application be
Page 39 of 53
Appendix
A.doc
Ref #
Description
Subject Area
used and entered into the system by
UoG staff?
I-RS-006
The consensus of workshop participants Research
was that it was a good idea to require all
Writing Up Students to register.
This, however, will be a change in UoG
policy.
I-RS-07 Processes
rely heavily on ‘future’ Research
functionality not yet confirmed by
Oracle. If this functionality is not
available, how does ATOS envisage the
handling of these processes?
Can ATOS confirm whether CRM can
be used to support any of the required
processes?
I-RS-08
The new process proposes that certain Research
responsibilities for scholarship awards
are centralised through a ‘financial aid’
office. It will be necessary for UoG to
assess the benefits and practicalities of
this change and consider any
subsequent resourcing issues.
I-RS-009
The proposed process assumes that
applications and scholarships are
submitted at the same time. This may be
the case in some areas but is highly
unusual in others. Will the system be
able to link these but allow for them to
be processed simultaneously and/or
independently?
I-RS-010
It is essential that the facility to track the
dialogue/communication with students
from the point of application is provided.
The output suggests this facility is fully
catered for in ‘future functionality’ but it
is a must for any future development.
UoG needs clarification of whether this
will be available in version 9.1
I-RS-011
There are ‘research specific’
Research
requirements of the new system which
are currently recorded by UoG. In
particular:
• Research
Furth
• Research Academic Sponsor
• Research
Speciality
• Details of collaborations with other
students
• Attendance at induction
• Intellectual property rights to thesis
• Ethical approval of research
Page 40 of 53
Appendix
A.doc
Ref #
Description
Subject Area
• Skills training needs analysis
• Viva
details
• Extensions granted without LOA
UoG to investigate all the requirements
which are necessary and how well all
the above are used.
ATOS to confirm how these are to be
/recorded handled in CS once more
information is available.
I-RS-012
UoG to consider the extent to which the
Research
processes for evaluation of admissions
and scholarships can be standardised.
I-RS-013
Reports will need to be created to
Research
identify students that are nearing the
end of their research and need to begin
writing up.
I-RS-014
UoG to consider practicalities of storing
Research
all documents/reports relating to a
student’s study electronically. i.e.
examining committee comments and
progress reports.
I-RS-015
UoG to clarify procedure on whether to
Research
refund students on agreed LOA’s or
retain credit until student returns.
I-RS-016
Tracking Consumption: In 9.0 there is no Research
delivered functionality for tracking the
amount of time the student has “utilised”
so far in obtaining their qualification
I-RS-017
Monitor and evaluating research
Research
progress: In 9.0 there is no delivered
functionality for collaborating with the
student at progression points or
automatically track when an evaluation
is required.
I-RS-018
Thesis Management. In 9.0 there is no
Research
delivered functionality for tracking
Thesis progress.
I-RS-019
Thesis Evaluation and Examination. In
Research
9.0 there is no delivered functionality for
the assessment and evaluation of a
Student’s Thesis ad connecting that
process to the final awarding of the
degree and graduation
Page 41 of 53
Appendix
A.doc
D0_115 Self-Service Process Document v3.4
Ref #
Description
Subject Area
I-SS-001
The analysis of Campus Solutions self-
Self Service
service functionality can only really be done
as part of a holistic approach to all self-
service provision that will be available to
staff and students. CS should provide an
element of this functionality but it is unlikely
that it will be the sole system used to
deliver this and a coordinated development
strategy needs to be established.
There should also be clearly defined and
consistent use of self-service functionality
to ensure that the student experience is
constant across all areas of provision.
I-SS-002
The delivered ‘class schedule’ and Self Service
‘teaching schedule’ functions were seen as
having limited use since they do not allow
for the addition of other information by the
user.
To allow this would be a significant
development to the system, but it may be
desirable to investigate the facility to
synchronise these schedules with personal
calendars in other systems.
It is noted that the development of calendar
functionality within MS Sharepoint may
resolve this issue.
I-SS-003
Relationship between Campus Solutions Self Service
and Moodle needs to be considered and
agreement reached on how the two
systems will be used alongside each other
and be synchronised.
Some requirements, e.g. course
evaluations and the flexibility for academics
to create new assignments as required, are
already catered for by Moodle where this is
used.
I-SS-004
If students are to be able to request to pay Self Service
‘other’ charges (such as buying print
credits) this will require a link to the
departments or systems providing these
services.
I-SS-005
The effectiveness of Faculty Centre will be Self Service
determined by the quality of data that
underpins it – particularly the maintenance
of data attaching academic staff to classes.
This will require resource in departments to
be responsible for maintaining this data.
I-SS-006
Should advisors be able to amend student’s Self Service
records on the system, or should students
Page 42 of 53
Appendix
A.doc
Ref #
Description
Subject Area
be responsible for updating their own
information?
I-SS-007
Exam Timetable information in Student Self Service
Centre will not reflect individual
arrangements made for students. Need to
consider how to address this – through a
customisation to the functionality or through
ensuring effective communication to
students who have separate arrangements
to ensure they are aware of their individual
details and they know to ignore the details
shown online?
I-SS-008
Some pages in self-service may need to be Self Service
customised to make them relevant and
useable to UoG students/staff. Functionally
this may not be necessary but there is
advantage to be gained from looking at
ways to engage users by making the self-
service screens as relevant as possible.
I-SS-009
Clarification is required on the ‘ownership’ Self Service
of data items and on who is able to create,
update and view specific items/records.
I-SS-010
Emails sent from the Class Roster page are Self Service
blind copied to all recipients and copied to
the academic generating the mailing. This
means that a record of those to whom the
email has been sent is not maintained.
Other communications functionality within
CS do maintain a history and should be
used for communications where a record is
required,
User training will need to address this
issue.
I-SS-011
Display of Student Photos on Pages. Self Service
WebSurf displays the student photo on all
pages of the system – this is regarded as a
useful tool (particularly for academic staff)
and there was a desire for student photos
to appear more widely within CS.
Currently in CS the student photo is only
visible through the Class Roster page or the
dedicated ‘Student Photo’ page.
Page 43 of 53
Appendix
A.doc
D0_106 Student Financials v3.8
Ref #
Description
Subject Area
I-FA-001.
The proposed new process increases Financial Aid
centralised responsibility to manage receipt,
processing and tracking of hardship and
scholarship awards. This will require UoG to
assess the benefits of this process change and
to manage any subsequent resourcing issues.
I-FA-002.
The business process around the award of Financial Aid
Postgraduate Research Studentships is still to
be determined as there were no participants at
the work shop who understood the requirements
in sufficient detail.
A separate meeting will be scheduled to obtain
this detail and included in the document at a
later date.
I-FA-003
The business process Government Based Financial Aid
Funding (SAAS and SLC) is still to be
determined as there were no participants at the
workshop who understood the requirements in
sufficient detail.
A separate meeting will be scheduled to obtain
this detail and included in the document at a
later date.
I-FA-004
Although the Discretionary Funds process is Financial Aid
based on a vanilla PeopleSoft approach, it is still
to be determined how much of the US regulatory
code will need to be stripped out to enable this
functionality to work in the U.K.
Although Oracle are planning an International
Aid component, there is currently no indication
as to when this functionality may be released.
A meeting with Oracle developers is planned to
get a better understanding of the offering in this
area.
I-FA-005
If an award is to pay additional expenses, the Financial Aid
credits will be configured to be unable to be
applied against current student charges. This
will leave them as an unapplied credit that can
be picked up by the refund process.
It was suggested in the workshop that UoG may
wish to restrict these types of awards. The
feeling was if the award is funded by the
University, it should be used to pay off fees
owed to the University prior to giving any money
to the student. Policy decision required on
criteria to apply for Hardship funds.
Page 44 of 53
Appendix
A.doc
Ref #
Description
Subject Area
I-FA-006
The Financial Aid process will involve a UK Financial Aid
localisation developed by Oracle for handling
transactions with the Student Loans Company
(SLC). It is still to be determined how the
processing of SAAS files will interact with this
specific localisation.
The process defined at the workshop and
detailed in the Student Financials process
document must be confirmed with the Oracle
localisation development team before it can be
considered a confirmed to be process.
I-FA-007
The refund process will be run to create a file of Financial Aid
students requiring payment transactions. There
will probably be a small level of customisation
required to produce a file that will interface with
UoG’s payment system. However, it is still to be
determined whether or not this modification will
need to occur in the PeopleSoft product or if the
change is more easily made in the University’s
payment product (Mentec).
I-FA-008
UoG is considering implementing a policy Financial Aid
requiring all payments to students to be issued
by BACs.
This has raised some concerns about the impact
of this policy on low income and foreign students
who do not have a bank account. It was also
mentioned that some student’s would object to a
BACS payment as this may use up a
discretionary fund payment on existing
overdrafts instead of providing students with
cash.
I-FA-009
Establish UoG definitions for scholarships and
Financial Aid
bursaries as well as review the effectiveness of
the current funding processes in supporting the
University’s strategic direction.
I-FA-010
Need to confirm the business process and
Financial Aid
technical requirements for an interface from the
document imaging system to CS
I-FA-011
Need to establish the level of detail required re:
Financial Aid
applications for scholarships to confirm if
customisation is required
I-SF-004
The Student Financials process outlined Student Financials
assumes a change in the billing timeframe. For
Page 45 of 53
Appendix
A.doc
Ref #
Description
Subject Area
new students, it is planned that they will receive
their first invoice shortly after receipt of the UoG
offer. For continuing students, they will receive
an invoice for the next years’ fees shortly after
being approved for progression into the next
stage of their programme. The invoice should
include all known charges relating to a specific
programme/research project.
This can only be achieved for non-modular fee
calculation. To support a standard billing
process for programmes that require module
calculation such as DACE or Undergraduate
part time, a standard fee will require to be
devised
I-SF-005.
Fees for Postgraduate Taught and Distance Student Financials
Learning courses be standardised into a matrix
of fees based on a student’s academic load,
programme of study and residency. The matrix
should also provide the framework that fees are
pitched at the appropriate level to cover all
incidental costs.
I-SF-006
It was also suggested that UoG revise their Student Financials
payment policy to require all refund and aid
disbursements to be issued via BACs transfer.
This suggestion raised a number of concerns
about students who may not have access to a
bank account.
I-SF-007
Concerns about early billing.
Fee Calculation
> There was a concern over how this early
billing would be viewed by the student
especially if this invoice becomes one of the
first points of contact with University after
admission.
> The timing of income recognition from the
volume of students who are admitted or
progressed but then never complete their
registration and enrolment. Devise an
automated mechanism to back out invalid
debtors prior to the collections process
> Format of the “billing” to be determined i.e.
standard invoice or initial letter referencing
fees
Page 46 of 53
Appendix
A.doc
Ref #
Description
Subject Area
I-SF-008
Currently, departments determine the specific Fee Calculation
fee for a programme. This has led to a
significant amount of variation in fees especially
at the Postgraduate Taught level.
It was proposed at the workshop, that these fees
be standardised into set levels. Departments
would then be required to select a fee band for a
given course as opposed to a specific amount.
May be useful to consider as part of this process
a systematic review on the pricing model
I-SF-009
For tuition revenue that had been previously Fee Calculation
booked to the balance sheet, the revenue will
not be reallocated to the department(s) which
offers the course into which the student has
enrolled.
For new charges, those associated with modular
fees or additional course charges, will be
booked directly to the department(s)’ revenue
accounts.
The student will also be provided with a revised
invoice at this time.
It is still to be determined by UoG if student
who’s fees have not changed since the original
recalculation will be re-invoiced.
I-SF-010
Potentially, after this initial enrolment a student Fee Calculation
may change their course schedule or drop
classes altogether. When any change to the
student record occurs, the fees will be
recalculated.
Potentially the dropping of a class will also lead
to a student receiving a refund on all or part of
the tuition charged for that class. The amount of
this refund will be automatically calculated in the
system. The exact rules that will be used have
yet to be determined by UoG, see issue, but will
be based on the following criteria:
> The type of fee that was originally assessed
> When in relationship to the start of the class
was the class dropped
> The reason the student has decided to drop
a class. For example a different refund rate
may be assigned to a student who dropped
the class due to ill health than to a student
who dropped without reason.
I-SF-011
At specific points in the Academic Year still to be Library Fines
determined by UoG, any unpaid Library fines will
be transferred into the Campus Solution System.
Page 47 of 53
Appendix
A.doc
Ref #
Description
Subject Area
At this point the liability will be removed from the
Library system so the balance is only ever active
in one system at a time.
I-SF-012
Once the student has completed the direct debit Direct Debits
request form, they would be enrolled into a
instalment payment plan specifically designed
for direct debits in the student system. The
frequency of these instalments is still to be
decided.
Currently three large instalments are made, but
the group felt it may be preferable to have more,
smaller instalments. This approach would be
especially useful for students on a monthly
income.
I-SF-013
After a certain number of rejected transactions, Direct Debits
the direct debit would need to be cancelled.
However, UoG is yet to determine how many
transactions can fail prior to cancellation.
I-SF-014
A decision still needs to be made about how and Direct Debits
when to interface the ledger transactions to
Agresso.
If this interface is done from the student system,
the GL information will be generated on the day
the direct debit request is made to Mentec, not
necessarily when we receive the cash from the
student.
I-SF-015
The student will be invoiced at two key times in Billing and Collections
the year, at progression and registration.
Invoices will then continue to be issued on a
regular basis throughout the year to pick
additional ad hoc charges.
This frequency has yet to be officially decided,
see issue, but monthly invoicing was discussed.
I-SF-016.
If a payment is not received, the student will Billing and Collections
enter the ageing and debit collection process.
The collection process and ageing categories
are still to be determined by UoG.
I-SF-017
The collector can be assigned using a selection Billing and Collections
of criteria including student name, debt age and
debt amount.
The exact parameters used at UoG are still to be
determined.
I-SF-018
Can Academic Advisers be included in the Billing and Collections
collections process? Administrative staff thought
this would be an extremely beneficial approach
as the student’s advisor already has a good
relationship with the student. However, it is
Page 48 of 53
Appendix
A.doc
Ref #
Description
Subject Area
believed there would be substantial resistance
on the part of academic to assist in collections in
any way.
I-SF-019
The utilisation of dunning letters as part of the Billing and Collections
collection process is still to be determined by
UoG.
I-SF-020
The language used in the dunning letters had to Billing and Collections
be carefully considered so as not to alienate
students.
In Campus Solutions, this text is completely
configurable, so it is simply a matter of UoG
determining the appropriate tone for each letter.
I-SF-021
Write off policy needs to be considered as part Billing and Collections
of the collections process
I-SF-022
Policy decision required to establish and Billing and Collections
implement the use of fee deposit rates for
overseas students as part of the PBS
Committee
I-SF-023
Campus Solutions Direct Debit customisation
Direct Debits
I-SF-024
Customising the Physical Invoice: Although Student Financials
Campus Solutions provides a delivered generic
invoice, the majority of institutions prefer to
customise that layout of this document at least
to the extent of adding a University Logo to the
report.
I-SF-25
Customising the Physical Receipt: Although Student Financials
Campus Solutions provides a delivered generic
receipt, the majority of institutions prefer to
customise that layout of this document at least
to the extent of adding a University Logo to the
report.
I-SF-026
DACE collection of fees to be sourced from the Billing & Collections
Fraser Building
Page 49 of 53
Appendix
A.doc
D0-102 Student Profile Design Document v3.3
Ref #
Description
Subject Area
I-SP-001
UOG to review policy on the recording and Student Records
updating of student Names. Who should be able
to update Names, which Name ‘types’ should
specific roles be able to update?
I-SP-002
UOG to review policy for collection and update of Student Records
Date of Birth data. Should Date of Birth be a
compulsory field to be collected for
all students?
Who should have access to amend date of birth
date once it has been authenticated?
I-SP-003
Is there a need for specific records to be Student Records
’suppressed’ –i.e. removed from search screens.
I-SP-004
Additional information is required to fully assess Student Support
the requirement for recording arrangements for
students with specific requirements (e.g.
disabilities). These can then be mapped against
the ‘Accommodation’ functionality to determine if a
match exists.
I-SP-005
Which system should be used to store student UOG Systems/Interfaces
photographs? CS can be configured to work in
either way.
I-SP-006
Confirmation of provision for UK information CS future development.
profile – including Unique Learner Number within
CS.
I-SP-007
UOG to review policy on term address being a Student Records
mandatory address type for all students.
I-SP-008
UOG to review policy on UOG email address only Student Records
to be used.
I-SP-009
UOG to review policy on who would have access Student Records
to update information regarding previous
degree/qualifications.
I-SP-010
UOG to review policy on access to/security of
data.
I –SP-011
UOG is introducing a PDP system (Mahara), with
which CS will have to interface, however the
precise requirements for the PDP system are not
known. The CS component for capturing
participation and extracurricular activity provide
significant scope for configuration to capture
information that UOG may deem appropriate.
I –SP-012
2.19 Ref comment regarding new points based
system. Would CS take into consideration the
requirements of the new points based system and
automatically check details, and generate sponsor
letters.
I-SP-013
Interfacing Addresses with the Accommodation
System: Interface of address information from the
Page 50 of 53
Appendix
A.doc
Ref #
Description
Subject Area
accommodation system into Campus Solutions
I-SP-014
Interface with QAS for address validation
I-SP-015
Validation of Phone Numbers: There is a
requirement to collect Home and Mobile phone
details and the delivered screens meet this need.
UOG has an increasing initiative to communicate
through SMS texts and the importance of accurate
mobile phone records in vital to this. There may
therefore be a need to consider background
processes to validate the format of phone
numbers and ensure that numbers are associated
to the correct ’type’. KL: Agreed that the amount
of valid variations in number formats would make
any kind of validation complex and costly.
Proposed that, beyond some basic
guidance/warning on format and accuracy, no
checks at data entry are made but there is regular
communication with students to encourage them
to check accuracy, particularly when moving
towards increased use of SMS as communication
tool.
Page 51 of 53
Appendix
A.doc
D0_107 Student Records Maintenance v3.3
Ref #
Description
Subject Area
I-SR-001
The standardisation of processes for student’s Student Records Maintenance
to request faculty / programme transfers online
will require custom development.
CS will handle the data processing of transfers
but the addition of common business
processes to initiate a request will need extra
development.
An alternative would be to retain the current
processes for submission of requests.
I-SR-002
Retaining the adviser ‘approval’ step in the Student Records Maintenance
course change process will require a
development to the system to put student
initiated changes ‘on hold’ and allow advisers
to complete the process.
This could be avoided by using standard
functionality to allow students requests to be
immediately processed and advisers to be
notified. Implementing a prescribed ‘add / drop’
period for student’s to make changes may
reduce the number of later, unsuitable
changes. The CS enrolment rules engine will
also help to prevent student’s making ‘invalid’
requests.
I-SR-003
Standardised process for submission of Student Records Maintenance
withdrawal requests will require a custom
development.
Alternatively the current practice of receiving
requests could be retained and the standard
data entry screens used to input the data.
I-SR-004 The
responsibility for confirming and Student Records Maintenance
processing of student withdrawals on CS
needs to be determined. Currently this resides
in the Registry but there was a proposal that it
should reside with the adviser since they are
deemed to ‘own’ the approval of other areas of
the student’s record and are also likely to be
the person that has final contact with the
student. If Registry automatically process
requests when they are submitted by the
student there is the potential for advisers to
‘miss’ the chance to counsel the student before
the withdrawal is processed.
I-SR-005
UoG’s attendance policy needs to be approved Student Records Maintenance
before detailed configuration of attendance
process on CS can take place.
I-SR-006
Interfaces will be required to enable automated Student Records Maintenance
import of attendance data from various
different recording systems – it is unlikely that
manual entry into the CS screens will be
Page 52 of 53
Appendix
A.doc
Ref #
Description
Subject Area
supported by University staff.
I-SR-007
University to determine level of detail at which Student Records Maintenance
attendance should be recorded (may link to
Issue I-SR-005)
I-SR-008
Student Absence Self-Reporting functionality Student Records Maintenance
currently offered in WebSURF will need to be
developed in CS in order to retain current
functionality.
I-SR-009
UoG to consider whether internal processes Student Records Maintenance
for faculty/programme changes can be revised
to fit delivered functionality where possible.
Can a common policy be developed across all
Faculties in terms of these business
processes?
I-SR-010
UoG to identify how the balance between the Student Records Maintenance
advisers role in guiding students towards
informed choices and greater automation of
course selection can be achieved. E.g. should
the adviser/student dialogue continue prior to
the changes being made in the system?
I-SR-011
UoG to consider the benefits of a prescribed Student Records Maintenance
‘add / drop’ period for students to make course
changes.
I-SR-012
UoG to establish standardised withdrawal Student Records Maintenance
policy by investigating current practice and
past experience.
Page 53 of 53
Appendix
A.doc
