Sap Her

Student Lifecycle Management Product and Architecture
Applies to:
SAP Student Lifecycle Management.
Summary
The purpose of this document is to provide an introduction to the Student Lifecycle Management product and its architecture. For detailed description of the Student Lifecycle Management product please refer to the Student Lifecycle Management documentation BS7 (EHP 4)
Author:
SAP
Created on: 20 February 2011
SAP DEVELOPER NETWORK | sdn.sap.com 2011 SAP AG
BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 1
Table of Contents
1. Solution Scope ................................................................................................................................................ 3 1.1 Functional Areas: Business Processes covered by Student Lifecycle Management ............................... 3 1.2. Business Processes covered by Third Party Solutions ........................................................................... 5 2. Solution Architecture....................................................................................................................................... 6 2.1. Overview .................................................................................................................................................. 6 2.2. Glossary ................................................................................................................................................... 8 2.3. Architecture of SAP SLCM Master Data Management ............................................................................ 9 2.4. Architecture of SAP SLCM Academic Structure .................................................................................... 10 3. Organizational Structure ............................................................................................................................... 12 3.1. Academic Calendar ................................................................................................................................ 12 3.2. Program Catalogue ................................................................................................................................ 12 3.3. Module Catalogue .................................................................................................................................. 13 3.4. Event planning ....................................................................................................................................... 13 3.5. Process Control by Rules ...................................................................................................................... 13 3.6. External Academic Structure ................................................................................................................. 15 4. Student Master Data ..................................................................................................................................... 16 4.1. Student as an HR object ........................................................................................................................ 17 4.2 Student as Business Partner .................................................................................................................. 18 4.3. Student Contract Account ...................................................................................................................... 19 5. Student Lifecycle Processes ........................................................................................................................ 19 5.1. Admission and Recruitment ................................................................................................................... 19 5.2 Program Registration .............................................................................................................................. 20 5.3 Equivalency Determination ..................................................................................................................... 20 5.4 Module Booking ...................................................................................................................................... 20 5.5 Grading ................................................................................................................................................... 20 5.6 Progression ............................................................................................................................................. 20 5.7 Audits ...................................................................................................................................................... 21 5.8 Assessment Process .............................................................................................................................. 21 5.9 Graduation .............................................................................................................................................. 22 6. Student Accounting....................................................................................................................................... 22 7. General Concepts ......................................................................................................................................... 23 7.1. Authorization .............................................................................................................................................. 23 7.2. Audit Trail of Processes ......................................................................................................................... 23 7.3. Correspondence..................................................................................................................................... 24 7.4. Archiving ................................................................................................................................................ 24 7.5. Student Self Services ............................................................................................................................. 24 7.5.1. Online Course Registration ................................................................................................................. 27 7.6. Integration of SAP .................................................................................................................................. 29 7.1. Integration with SAP CRM ..................................................................................................................... 29 7.2. Integration with SAP NetWeaver Identity Management ........................................................................ 30 7.3. Integration with SAP/Non-SAP Applications .......................................................................................... 30 Related Content ................................................................................................................................................ 31 Copyright .......................................................................................................................................................... 32
1. Solution Scope
1.1 Functional Areas: Business Processes covered by Student Lifecycle Management This table lists Business Processes/Transactions available in SAP Student Lifecycle Management. For details please refer to the following chapters. 1. Curriculum Management: Academic Structure and Course Scheduling (Event Planning) 1.1. Maintenance of Academic Programs Define degree objectives: define qualification with level and type of degree or non degree 1.1.2. 1.1.3. 1.1.4. 1.1.5. 1.1.6. Define programs of study: define structure (based on study conditions of program) expressed with objects program of study (SC), module group (CG) Define majors, minors and concentrations: define specializations of program (based on study conditions of program) with module groups (CG) Define modules (courses): define modules (SM) the student should complete to achieve qualification of program Define pre- and co-requisites: define requirements for a module Student has to fullfill before s/he is able to book this module Publish academic catalog: publish study program in active versions on university page
1.2. Maintenance of Course Catalog 1.2.1. Define and set up courses: define and plan course (events) which are offered in current session with schedule and resources (date, time, room, etc.) 1. 2.2. Publish course catalog 1.3. Maintenance of Degree Audit Requirements 1.3.1. Define degree requirements: define requirements for a program a student has to fullfill before s/he achieves its qualification. 1.3.2. Associate courses with degree requirements: assign degree requirements to the academic objects (courses) of the academic program. 1.4. Class Scheduling 1.4.1. Demand Analysis: The course demand report shows bookings, module plan assignments, and course registration cart counts of students. It helps to determine how many students are likely to book a course for a future year and session. 1.4.2. Define sections and classes: Determine details of course offerings, e.g. sequence of courses and form of teaching (lecture, classroom trainings, lab, etc.), start/end times, and capacity. 1.4.3. Assign and schedule instructors, rooms, equipment: Maintain human and technical resources as well as location required for the academic offering. 1.4.4. Faculty Workload Management: maintain data regarding planned and actual workload for academic events. 1.4.5. Publish Class Schedule 2. Recruitment (-> SAP CRM) 2.1. Gathering Prospect Data 2.2. Prospect Segmentation 2.3. Campaign Management
3. Student Administration 4. Academic Lifecycle/Student Portal Role 5. Academic Advising 5.1. Degree Audit Simulation 6. Admission and Equivalency Determination 7. Academic Work Completion 7.1. Course Registration 7.1.1. Course Selection: Student selects course (module plus event) via course registration UI. Selection might be influenced by program objectives on the basis of a module plan. 7.1.2. Check course requirements: the needed requirements are checked; special approvals are taken into account. 7.1.3. Course Booking: Student books modules and events. 7.1.4. Waitlisting: Student books module and event on the waitlist. 7.1.5. Course Cancellation: Student cancels booked course. 8. Study Management: Module Plan
9. Progression (Standard Report) and Auditing 10. Teaching and Examinations 11. Student Accounting 12. Graduation 13. Student Self-Services and Faculty Self-Services Students 13.1. Student Admission Application 13.2. Student Admission Audit 13.3. Change of Program 13.4. Change of Specialization 13.5. Grade Change Request 13.6. Graduation Request 13.7. Address Maintenance 13.8. Special Booking Authorization 13.9. Equiv. Determination Simulation 13.10. Transcript Request 13.11. Course Registration Faculty 13.12. Online Grading 13.13. Course Request 13.14. Room Search 13.15. Maintain Transcript 13.16. Attendance Tracking
14. Tools/Functions 14.1. Reports 14.2. Mass Processes 14.3. Selection Methods 14.4. Correspondence 14.5. Data Archiving 14.6. Authorization 14.7. Workflow 14.8. Migration Tools 14.9. Interfaces 15. IDM Integration 1.2. Business Processes covered by Third Party Solutions Financial Aid: In the US, Financial Aid is the total amount of financial assistance (federal and nonfederal) a student is offered by the school. Related software solutions must address a complex set of USonly requirements, which involves close communication with US Government agencies and databases, as well as frequent updates regarding eligibility (etc) rules provided by the US Government. SAP does not offer an own solution to cover this requirement but works together with the partner Sigma Systems for the US market. SAP ERP and SAP SLCM provide much of the data and manage e.g. the financial transactions necessary for handling financial aid in the sense of internal grants in general. The partner solution supports processes such as Packaging, "Eligibility Verification" and "Disbursement" and provides some specific functionality such as accessibility, database interfaces, and compliance (reports and rules updates).
SAP supports this through a partner because 1. This is US-only and SAPs HER solution strategy is global. 2. This capability relies heavily on domain (content) knowledge which the partner has. 3. The partner solution sends data to and receives data from specific sources such as the National Student Loan Data System (NSLDS), the database for federal student financial aid where students can find out about the aid they have received. 4. The partner solution provides information and reports for the school, parents, and students. Scheduling / Enhanced Event Management Webservices are available in SLCM EHP 4 which allow for integrating SLCM with a scheduling software. Additional effort is required in defining that integration and adapting the services. Housing There is no configuration delivered for integrating Student Lifecycle Management with SAPs Real Estate Management solution RE-FX. Library Management There is no library vendor with whom SAP has a partner relationship. Touchpoints between SAP's industry solution for Higher Education, SAP Student Lifecycle Management, and a (third) party library system are minimal: The Library system needs to know student IDs, and probably look at any student holds that would prevent the student from using the library services. The Library system needs to post fines/fees to the student account Alumni / Fundraising Management: See BPX HER -> Knowledge Center -> Fundraising Management
Business Requirement and SLCM Module Mapping Example No Business Requirement SAP Module Mapping 1 2 3 4 5 6 7 8 9 10 11 12 13 Organizational Structure Recruiting and Admissions Curriculum Management Calendars Class Timetabling Correspondence Student Records Student's Academic History Academic Advisement Grade book Campus Self Service Student Financials Reporting Organizational Management, Academic Structure, Business Partner Admissions Recruitment via CRM Marketing and SLCM Admission Module SLCM Academic Structure and Assessment SLCM Academic Calendar SLCM Resource and Event Planning SAP Print Workbench SLCM Student File/ Student Records SLCM Student File/ Student Records Academic Advisor User Interface SLCM Appraisal and Assessment Student Self Services and Faculty Self Services SLCM Student Accounting SAP BI (see SLCM BW extractors described in SLCM Reporting cookbook on BPX HER)
2. Solution Architecture
2.1. Overview SAP Student Lifecycle Management (SAP SLCM) is the SAP Industry Solution for educational institutions. It is developed in software component IS-PS-CA (Industry Solutions Public Sector Contract Accounting) on top of FI-CA (SAP ERP Financials, Contract Accounting). SLCM is part of the SAP ERP and can be activated using the switch framework. After the technical installation of SAP ERP, the switch framework allows to activate one industry solution in that installation. SAP SLCM extends the functionality of SAP ERP through specific academic business processes which cover the lifecycle of a student starting from a students application for a program of study at university up to the students graduation. Educational institutions can manage their academic structure and curriculum, maintain student master data, and perform admission of students, registration, fee calculation, grading, grant management, and graduation with SLCM. Most business processes are done in SAP GUI transactions but self services are provided for students, academic advisors and instructors in the SAP NetWeaver Portal. SLCM is built using different components of SAP ERP Human Capital Management (SAP ERP HCM) and SAP ERP Financials (SAP ERP FIN). The academic structure of the university is realized using the HR Personal Development Infotype Framework (HR PD Infotype framework). The student master data resides in SAP Business Partner and HR PD Infotype framework. Student accounting covers business processes such as fee calculation and grant management is built on the Public Sector extension (PSCD) of SAP Financials Contract Accounting (FI-CA). SAP SLCM also reuses Validation Substitution Rules (VSR) from SAP ERP FIN, correspondence from FI-CA, Internal Service Request (ISR) for admission application processing, structural authorization from SAP ERP HCM, and business rules framework (BRF) from SAP ABA.
Administrative users of SLCM such as registrars work directly on the SAP ERP system, whereas students and instructors use self services such as course registration and appraisal self services. Academic Advisors who guide and help the students in various activities such as booking courses can work on SAP ERP system and also use the self service Academic Advisor Web UI to view the student study details and help students progressing in the university. Student self services are applications which can be either deployed in the portal or function as standalone applications. Administrators take care of master data maintenance that includes setting up the academic structure of the university and setting up the student master data and student accounts. Student master data is implemented using the infrastructure of SAP Business Partner and personal development infotype framework of SAP ERP HCM. The university master data is built on SAP HCM using the PD infotype framework, Organization management (OM) and Training and Event Management (TEM). Post processing framework together with the business rules framework (BRF) enable universities to enhance and adapt the student lifecycle processes to their specific needs. The post processing framework is plugged into the business logic of the student lifecycle processes to enable the execution of follow-up activities after the execution of the standard business process. For example, when the grading process is executed, it calls the post processing framework, which triggers the evaluation of rules in the business rules framework (BRF). The rules define that the university wants to inform the academic advisor in case a student gets a low grade so that the advisor can get in touch with the student for improvements. In case the rules say that the academic advisor needs to be informed the post processing framework triggers an email message. Student accounting is a separate component which implements the business logic for university-specific financial processes. For example, fee calculation is used to calculate and bill the tuition fee students have to pay. Universities run reports that calculate the fees for the students and post the amount due into the student accounts. Student accounts are contract accounts built on FI-CA where the amounts can be posted as tuition
fees, meal fess, hostel fess etc. Grant evaluation allows to maintain grants and scholarships and to trigger the corresponding payments. Student accounting is built on PSCD and FI-CA and is integrated to FI processes such as general ledger, cash payments and so on. Universities use standard FI-CA processes such as correspondence to send student fee invoices and dunning to dun the student if they do not pay. SAP SLCM provides enterprise services for integration with other SAP or non-SAP applications. It provides enterprise services for sending student master data, event planning data to other application such as a Learning Management System. SLCM also provides enterprise services for checking the existence or creation of academic structure objects such as academic course and program of study. To activate the industry solution SAP SLCM the business function set CAMPUS_MANAGEMENT needs to be activated. Activation of the business function set will activate all the basic configurations that are required to run SAP SLCM. Technically IS-PS-CA sits on top of software component FI-CA (Financial Contract Accounting) and requires the following software components: SAP_BASIS, SAP_ABA, SAP_AP, SAP_APPL, and FI-CA.
2.2. Glossary Term Academic Advisor Program of Study Course/Module/course module Module Group Assessment Definition An academic staff member who is responsible for advising selected students who are assigned to him or her. A plan of academic offerings leading to a specific degree, certificate, or comparable qualification. Combination of business event types and associated rules that can be used in one or more program of study. Combination of modules that can be used in one or more programs. Process used to monitor and evaluate academic work which a student submits to successfully complete the module or program. Date or time period classification. You can use the time limit to enter a date or time period in the academic calendar. A set of data grouped according to subject matter. The HCM component allows to process employee data in accordance with business requirements. The data structure of infotypes mirrors a logical set of data records. Infotypes can be identified by their four-digit keys, for example, the address infotype (0006). To facilitate reporting on past employee data, infotypes can be saved for specific periods. You can edit infotype records individually or by using fast data entry. The following functions are used for infotype records: Create, Change, Copy, Delimit, Delete A person, organization, group of persons, or group of organizations within or outside the institution. A ledger presents data used in creating financial statements. It records values at company code level. Agreement between designated universities regarding student exchange Helps to manage relationships between rules and academic objects. Contains validations and substitutions that the system processes to execute a check which is triggered by the occurrence of specific events. Time period during which only defined students are allowed to book courses / modules.
Time limit Infotype
Business Partner General ledger Exchange program Rule Container Rule Module Booking Window
2.3. Architecture of SAP SLCM Master Data Management The most important master data of SAP SLCM is the following: Academic structure of the educational institution which describes the organizational structure of the institution as well as programs and courses offered by it Student master data which includes personal data Student contract account
The master data uses the infotype framework from SAP ERP HCM, SAP Business Partner and FI-CA.
2.4. Architecture of SAP SLCM Academic Structure The academic structure constitutes the programs of studies a university offers, the various qualifications that it imparts to students, and the academic offering. In SAP SLCM, the academic structure consists of: Organizational Unit Organizational units provide a structure to the university. The university may consist of different schools or colleges and have departments assigned to them. The organizational structure of an institution is built using the organization management (OM) tool of SAP HCM. Academic Calendar Academic Calendar is an HR PD object which is used to manage dates and time in the university. Program of Study A program of study represents an approved combination of modules in one or more subjects which fulfill the requirements for a degree. Program of study is an HR PD object that constitutes the academic structure and is maintained using the program catalogue. Module Module is an academic unit in which students learn about a defined content and can acquire credits for this. Module is an HR PD object and is studied for an academic period. Universities offer the module in an academic period so that students book the module and attend classes. Modules are assigned to a program of study in the program catalogue. Offering of modules is maintained in the module catalogue. Module Group Module Groups are entities to group modules into a certain structure within the program catalogue. Qualifications A qualification represents the successful result of a students academic career. An internal qualification is an HR object that represents degrees, diplomas and certificates awarded at institutions. They are assigned to programs of studies that students pursue and for which final qualifications are awarded during graduation. Event Package An event package groups the various business events that are offered for an academic period. Business event packages are HR objects and are maintained via event planning. Business Event Type Business event types give a generic structure to business events. Business event types are HR objects and are maintained via event planning. Business Event Business events are classes or online learning sessions that can be scheduled and offered so that students can book them and attend them. Individual Work Individual work represents a students academic work such as a thesis or project works that can contribute to her/ his academic work. Individual work is maintained using the program catalogue or the module catalogue. Rule Containers Rule containers group business rules that need to be checked during the business processes. Rule containers are associated to academic structure objects such as programs of study, modules, and event packages in the program catalogue. Rule containers are used to control the business process flow. External Academic Structure Objects Universities can create an external academic structure as part of their academic structure using different external academic structure objects. The external academic structure is used to determine equivalent courses or qualifications of an incoming student from a previous organization.
3. Organizational Structure
In Organization management, each organizational unit is an HR object which can have relationships to other objects. This supports the assignment of positions such as heads of department positions/faculty to each organization object. The position represents another HR object which is occupied by an employee (HR object Person) in the university or an external employee (HR object external person). 3.1. Academic Calendar The academic calendar contains the different dates related to business processes of the university. Business processes of a university are aligned with its academic periods. Academic periods are time periods to structure the academic programs of the university over time. They can be full academic years or academic sessions e.g. fall session, winter session, summer session, or spring session. Academic years and academic sessions are defined in customizing. Their dates are maintained in the academic calendar to indicate When the academic session starts and ends when the classes starts and end for that session when the registration to courses starts and ends when the grading period starts and ends deadlines for the students to pay fees, etc
Academic calendars can be assigned at the organizational unit level or at lower levels such as program of study, module group, module, or event package. Dates are maintained using time limits. They indicate the specific purpose for which the date and time are maintained for the relevant academic period. For example, the standard duration of an academic period is maintained using a time limit. This time limit indicates the start date and end of the academic period in the university. To maintain when the classes start and end for an academic period, there will be a different time limit. During the execution of the business process, the dates are derived from the academic calendar and assigned to the object that takes part in the process execution. For example, when an admission is given to a student for a program of study in academic year 2011 fall session the validity dates of the admission are taken from the academic calendar which is associated to the program of study for which admission is granted. If there is no academic calendar assigned to the program of study, the calendar is derived using an evaluation path. Evaluation path is the way of finding the next object using the relationship between HR objects that are defined in the evaluation path. Please refer to the SLCM EHP 4 documentation for details.
3.2. Program Catalogue The program catalogue defines the structure of programs of studies that are offered by the university. Program catalogue is a view to structure and maintain academic structure objects such as programs of studies, module groups, modules, and qualifications. It is created by the administrator of the department which offers the program of study. A program of study represents an approved combination of modules in one or more subjects which fulfill the requirements for a degree. Universities offer programs of study with different qualification levels. Students register for one or several programs of study. A program of study can also consist of stages. Stages structure a program of study according to a time line. For example, a program of study with 8 stages splits the content of the program into 8 and its content is studied in 8 academic sessions. Students have to enroll to the first stage of the program of study. The modules or module groups that structure such programs are also associated into these stages. A student registers to only those modules or module groups which belong to the current stage of the programs/he studies. Progression of the student takes place along the stages of the program until s/he completes the final stage and graduates. Module or course is an academic unit in which students learn about a defined content and can acquire credits for this. Most modules are offered as courses but they can also represent a more generic type of academic work, such as a thesis. They can be offered as one business event or as a number of business events. Module groups are entities that group modules to give a structure to the program catalogue. Module groups can be used for two different purposes:
1. Module groups refer to a combination of modules and represent for example a structure for a catalog or set of modules for a degree requirement. For example, a university can have modules Mathematics Part1 and Mathematics Part2 as part of their core mathematics study. They create a module group Mathematics Core to include both the modules. 2. Specialization for a Program of Study such as major and minor: A university allows students to take specialization subjects like major or minor and these will be considered for the progression of a student. E.g. a major in computer science can contain modules artificial intelligence or neural networks. Students studying these major subjects get additional eligibility or credits to progress further. The academic structure is based on HR Personal Development (HR PD) framework and uses an object oriented approach. There are object types that generalize characteristics of objects. The described objects like organizational unit, program of study, module group, module, event type, event etc. are PD objects. Attributes of these objects are grouped into infotypes, e.g. personal data details like name, age, birthplace, etc. can be grouped into an infotype Personal Data. The advantage is that the infotypes can be reused, e.g. the personal data infotype is used to represent a student and lecturer. 3.3. Module Catalogue The module catalogue defines the academic offerings of the university. In this transaction, sessions of offerings for modules and individual work data for modules can be maintained. It is typically administered by the administrator of the department which offers modules, classes, and individual work. As the program catalogue, the module catalogue is used to enter academic structure data but only to maintain the offerings. 3.4. Event planning Event planning or class scheduling supports the planning of lectures, classes, and the assignment of resources such as rooms for these offerings. Event planning reuses objects from Training and Event Management (TEM). Lecture classes are maintained with business event objects, for online courses time independent events are used. Business events and Time independent events are created for a course module for a particular academic period. These events are created from a template called Business Event Type. Business events include data such as schedule information with the time of lecturing, the instructors name of the session, the room in which the lecture is held and the location or the building where the event takes place. There can be events without schedule and events with irregular schedule. Business events and Time independent events are grouped into event packages. Event package is also an HR PD object that is assigned to a course module through HR relationships. Modules, event packages and events are created and offered for academic periods. During the course registration (module booking) process, students book the course module and also the event package or the event. Unless a module or event package is offered, the students cannot book or register to these modules or event packages. 3.5. Process Control by Rules Universities set up guidelines on how business processes work in their environment. All these policies and guidelines constitute the business rules that a university uses for its business processes. E.g., to decide whether a student can be given admission, rules need to be checked to find out the students eligibility. To manage business rules, SAP SLCM uses rule engines such as Validations Substitutions Rules (VSR) and Business Rules Framework (BRF). Some rules are also built using the relationships of objects in the academic structure. For a specific scenario, a course module should not be allowed to be booked unless a pre-requisite module is completed successfully. This rule is built using the pre-requisite relationship of academic course modules. To decide whether a business process can be carried out for a student, statuses or holds are used. One example may be that students who have not paid the registration fee will get a financial hold. Further processes such as booking of academic course modules and the booking of class lectures will not be possible unless the financial holds are removed for that student. VSR is a rules engine from SAP ERP Financials to manage validation and substitution of business data during the business process. Multiple rules that are created in VSR are grouped into rule containers to support the control of the different business processes at the university. Rule containers are associated either to a process or to specific objects in the academic structure so that during the process execution the rule containers are evaluated and data validations or substitutions are carried out. Rule containers are
associated to the processes using call up points. Call up points are points or places within SLCM processes where business rules are checked. Call up points are defined for every process in SAP. Rule containers are associated to call up points in two ways. Either by assigning them directly to call up points. Or by assigning them to academic structure objects using HR relationships and specifying the call up point in the relationship. When the process is executed, the call up points are reached and the rule containers are determined by reading those rule containers that are directly assigned and also those that are indirectly assigned via the academic structure objects. Rule containers associated to the academic structure objects are only considered if the academic structure object is part in that specific process. The below graphic describes the existing rule frameworks in SLCM.
BRF is a rules engine in SAP NetWeaver and is used by the SAP SLCM Post Processing framework. Business rules are checked and when a rule is fullfilled, the post processing activity is carried out. Students may drop or cancel course registrations because of their unavailability. Cancelling a course registration can lower the performance index of a student. If the performance of a student is below the expected value, the academic advisor needs to be informed. In this case, cancelling the course registration is the business process and informing the advisor is the post-processing activity. The check whether the student performance is below the expected value is done by business rules. Business rules are maintained in BRF and are associated to business events in BRF. For each business process, there is a business event in BRF. On successful execution of the business process, the business event in BRF is called.
Statuses are used to map a students general status or status in relation to a specific program of study. E.g,, when an admission application is created for a student, s/he gets a status Applicant assigned. On approval of the admission application, the status changes to Admitted Applicant. On registering or enrolling to the program, the status changes to Student. There are system statuses and customer statuses. Statuses are associated to call up points and processes and are checked during the execution of the process. Depending on the status of the student, the process can be continued or discontinued. Holds have the same concept as statuses but they are used only for preventing the student from execution of a business process. Holds are also associated to call up points and processes. When the call up point is reached upon the execution of the business process, the holds are checked. If the holds are active, the user is stopped from execution of the business process. A student has to pay the registration fee or hand in a certain certificate before he/she is allowed to continue his/her studies. The system sets a hold and displays an error message that the student has to pay the fee or hand in the certificate before he/she can book modules. This prevents a student from module booking until the hold is deactivated. Apart from the above rule engines, SAP SLCM also has an inbuilt rules engine the audit framework. The audit framework is used for admission audit and degree audit and is linked with the assessment process. Assessment is a process where the performance of students is evaluated during exams. Users can create rules in terms of requirements such as university general requirements or program specific requirements. For example, students should have a specific GPA to be graduated. This represents a university specific requirement that applies to all the programs in the university. To get admission to a masters program in Electronics, the students must have completed successfully a graduation program in electronics describes a program specific requirement. All such rules are grouped into rule containers and are called only by the specific process such as admission audit and degree audit. Extended Booking Check Framework is another rule framework that is used for managing rules for academic course module booking. For example an academic course module should not be booked unless certain course modules are completed successfully by the student (pre-requisite relationship) certain course modules are also booked in the same academic period (co-requisite relationship) students have obtained certain credits or booked certain number of course modules Above rules are set up using the extended booking check framework. The framework technically re-uses the audits framework for setting up the rules.
3.6. External Academic Structure Apart from the academic structure of the university, the university also maintains an external academic structure. It consists of entities such as external organizations, external qualifications, and external subjects. All these constitute the external achievements of the student. Through the business process equivalency determination (ED) the university transfers the external works of the students to internal academic work. External educational organizations (EO) are high schools and transfer institutions that students attended prior to coming to university. They can also be testing agencies/sources from which universities receive the test score results of prospective students. External qualifications (EQ) are qualifications students acquired during prior studies (e.g. high school certificate, degrees). External subjects (SU) are the subjects students took at external educational organizations or previous school results. Exchange programs are programs offered by the external organization that can be transferred to an internal program of study.
4. Student Master Data

Students represent the core objects in the SLCM and drive the various business processes in the university. Student master data stores students personal data such as address, bank account, and study data. A student object technically consists of Student as an HR PD (Personal Development) object of type ST. This object is used in student administration processes. Attributes of students such as personal data and study data are stored as infotypes for student object. Student as a business partner object with BP Roles PSCM10 (Student) and MKK (Contract Partner).
When a student is created, an HR object and a BP are created. Therefore the student master data maintenance transaction has screens for maintaining student HR data and central business partner data. The Business Data Toolset (BDT) is used to support screens for maintaining BP related data for the student. A student HR object will always have a student business partner attached to it. The student is also a BP. Business partner with role Contract Partner can have many contract accounts. A student business partner will always have a student contract account and can hold many other contract accounts also. The contract account is used for student accounting purposes. All fees that the student has to pay for the studies are posted to this contract account. Also the financial aids or grants that the student gets are also posted into this contract account. The student contract account will have many contract objects. Contract Objects hold the accounting information for the contract account. Contract objects are optional but are used in student accounting to group postings made to the student contract account such e.g. as tuition fees, and library fees.
4.1. Student as an HR object In academic processes such as admissions, program registration, module booking, progression, and graduation, the relevant object which is involved is the student HR object. The object is identified by a unique object ID and is characterised by a number of attributes which are stored as info types.
The HR student object stores the following information: Personal Data Personal data contain information such as First /Last name, Country of Birth, date of birth, Nationality, etc. Additional Personal Data Additional Personal Data contain information such as religion, social status, social service number, etc. Individual Study Data Study data holds information as student group, module booking data, campus data, and organizational unit. VISA data VISA data contain information about the various VISA details of the student. Residency Data Residency data contain information about the resident country, state, county, passport details etc. Challenge Challenge data stores information such as challenge type and e.g. the degree of the physically challenge. Employment Employment data stores details about the employments that the student did in the past or is currently doing. Alumnus Data Alumnus data stores details about the previous organizations of the student where s/he is an alumni. Fee Calculation Data Fee calculation data contain information as fee category, benefit category, and discounts for the student. The student object is also responsible for storing various transactional data such as academic work record usages, progression results, audit results, student statuses, student holds, student notes during various business processes within SLCM.
4.2 Student as Business Partner Student object as central business partner plays an important role in student accounting activities and also in integration scenarios where the student objects are distributed. For example, the SLCM - CRM integration is based on the student BP. Standard student master data integration to any other system including any 3 rd party system using enterprise services is based on BP integration. Student master data integration is an enhancement to the BP integration to contain HR related student information. The student BP is created with two business partner roles: PSCM10 (Student) and MKK (Contract Partner). The student role identifies the business partner as student, the role Contract Partner allows that the student business partner holds the student contract account where student fee and student grant data is posted.
The student business partner always has a student contract account and optionally some contract objects. It stores information about: Personal data Personal data stores information such as first name, last name, nationality, date of birth, etc. The same information is also stored as infotype in the student HR object. The data is first saved in the student business partner and is then synchronized into the HR infotype. Student address Student addresses such as standard address, correspondence address, etc, are stored in the BP. Here the complete address functionality of the central BP is re-used. Identification numbers Stores identification numbers of a student. Bank details Stores bank details of the student. Payment details Payment details capture information such as the payment method, credit card details etc. To maintain all the data, standard business partner screen are used based on the BDT (Business Data Tool) framework. Using BDT allows easy enhancement of fields and screens by customers.
4.3. Student Contract Account Whenever a student master data record is created, a student contract account is created in contract accounting of SAP ERP Financials. Student contract account data is used for student accounting at the institute. All fees that the student needs to pay to the institution, all the grants or awards or scholarships that the student receives is recorded or posted in the students contract account data. Contract accounts can be created for business partners with role contract partner (MKK). Student BPs are created with role contract partner so that contract accounts can be created for them. The fee calculation process calculates the fees that the student has to pay for the academic period and finally posts the amount into the student account. Grant evaluation process evaluates the amount the student gets as grant for her/his studies in the university and posts the amount into the contract account. Dunning is an FI-CA process which can be used to dun the student and send correspondence in case the student has some outstanding amount due in the contract account. The contract accounts are collected at the end and updated into the universitys general ledger. Contract objects hold the accounting information for the contract account. Contract objects are optional for a contract account. Contract Objects can be of two types. Tangible contract objects such as person or property (car, house) and intangible contract objects such as specific fee categories such as tuition, housing, meal voucher, etc.. Intangible contract objects are used in SLCM to post the fee amounts. For example, in a student contract account, fees are posted as tuition fee or meal fees. In SLCM, the required contract objects are automatically created on creation of contract accounts.
5. Student Lifecycle Processes

SAP SLCM provides business processes support for administering a student lifecycle at an educational institution. These business processes cover the students application for admission up to the students graduation from the university. The different processes are explained in the following. 5.1. Admission and Recruitment Students may enter educational institutions either through the recruitment process or directly through the admissions process. Universities can run recruitment campaigns to make prospects aware of the academic programs offered by the university. Through recruitment campaigns, the university identifies these prospects with the goal to turn them into students. The recruitment process is realized using a BP integration of SAP CRM and SAP SLCM. Running marketing campaigns and identifying the prospects and leads is performed in SAP CRM. Prospects turn into students when they apply for the program of study at the university. Here the BP data from SAP CRM is used to create the student in SAP SLCM. The recruitment process is not part of the standard SAP SLCM offering, but can be implemented by the customer. Students enter into the university through the admissions process. Students get to know about the programs offered by the university and apply for getting an admission. Universities can provide an online admission application form to the student in the university portal which is provided by SAP NetWeaver Portal. Students fill the form with the required details and submit the form. When the form is submitted, an admission application is created in SAP SLCM either manually or automatically depending on the configuration. The online student admission application form is supported by Internal Service Request (ISR also called Internet Service Request, as the tool can also be used for web based internet applications). ISR is a SAP NetWeaver tool to support online processing of form requests. Actions or workflows can be configured to start on submission of ISR forms using ISR notifications. Applicants submit the admission application form after filling all the details required for the university. On submission of the application form, an ISR notification is created. Actions or workflows can be configured as different steps for the processing of the ISR notification. These actions or workflows can create the student master data and the admission application automatically. An admission officer can create an admission application manually, too. When an admission application is created, status Applicant is assigned to the BP. After the admission application is created, the eligibility of the applicant for admission is checked. The admission audit can be used to determine based on the results whether the admission can be approved or not. Once the admission is approved, the Applicant becomes an Admitted Applicant at the university.
5.2 Program Registration Via the program registration, a student enrolls at the university for the academic period. The registration is typically executed by the Registrar office. A program registration is required for the students entry at the university. For a program that spans across many academic periods, students need to enroll for each academic session to continue their studies. Program registration is a pre-requisite for all further business processes such as course registration, grading, and progression. After the program registration, an Admitted Applicant becomes a Student 5.3 Equivalency Determination Equivalency determination (ED) is a process through which the university transfers external academic work of students to internal academic work. Students submit transcripts of their previous university and based on this, the university maintains external academic work for the students. The university can set up transfer agreements for transferring the external achievements to internal academic work. Transfer agreements are agreements which decide which external academic work can be considered and transferred to an internal academic work. Transfer agreements are built based on the policies and guidelines of the university. For example a transfer agreement can be that a post graduate program in Electronics from university A is equivalent to a graduate program at university B. Another example could be that course Basic Electronics from university A with Grade A translates into academic course Advanced Basic Electronics at university B with grade B.
5.4 Module Booking Module booking (Course Registration) is the process whereby students register for academic courses and classes. Students register to academic courses (modules) either through their academic advisors or by using the student self service in SAP NetWeaver Portal for course registration. Course registration creates an HR relationship between the student object and the module object. If the capacity of the module has reached an optimum level, students are booked as waitlisted if the system has been configured accordingly. It is then possible to move up the students from waitlisted bookings to normal bookings when there are booking cancellations or capacity of the module is increased. The course registration self service for students is built as a composite application and the front end is completely decoupled from the backend. All communication from the front end to the backend takes place through Remote Function Calls (RFCs). The calls to RFCs are made through Business AddIn (BAdI) implementations so that potentially the RFC calls can be easily replaced by the enterprise service calls. This represents a security measurement for the self service web application. Students also have access to further self services in the portal like change of address and request for a change of program. Instructors or teachers evaluate students through the grading process. Teachers can do an online grading through the corresponding self service application for appraisers.
5.5 Grading Students academic work is evaluated and awarded a grade by instructors during this process. The process typically starts at the end of an academic session. Grades and credits are used to evaluate the performance of the student and to finally decide on the students progression. Instructors can grade the students using the online grading self service functionality or through the corresponding backend functionality in the SAP GUI. If required configuration has been done, instructors will get the list of students for whom they are responsible for grading and grade them accordingly. Grades are stored as academic work record in the academic work history.
5.6 Progression Students performance is calculated based on the grades and credits that they achieved at the end of an academic session. Indexes are used to evaluate performance. Based on these indexes, students progress in their studies. For example, they are awarded with the academic standing such as honors, first class, and
second class at the end of progression. There are two types of progression supported: Program Type Progression and Stage Progression. Program Type Progressions is used for undergraduate and graduate programs in the United States. Students are promoted depending on the program type, such as undergraduate or postgraduate. Progression categories for undergraduates include freshman, sophomore, junior and senior. In contrast to program type progression, stage progression is typical for European universities and for professional programs in the US. A staged program of study requires the completion of a stage before students can progress to the next stage. Each stage sets requirements which have to be fulfilled to complete the stage. Stage audits are used to check whether requirements were met. The stage completion process is part of the students academic progression.
5.7 Audits Auditing is a process that defines and checks requirements that a student has to fulfill for the completion of certain business processes. The audit returns a result based on which the university can e.g. execute an admission or award a degree for a student. SAP SLCM supports the following three types of audit runs: Admission Audit: Before granting admission to a student, specified university requirements can be checked to see if the student full fills the admission criteria. If configured, the admission audit is called before executing the admission application for the student. Stage Audit: A program of study can be divided into stages. A student starts with the first stage and progresses to subsequent stages based upon successful completion of each of the stages. Via stage audit it can be determined at the end of an academic period whether a student can progress from one stage to another. Degree Audit: After completion of a program of study, a degree audit determines whether the student is eligible to receive the degree or final qualification. A degree audit is executed upon the graduation request by the student.
Business rules are created in the audit framework based on the type of audit run and are called and evaluated during the audit run. The audit framework is built using rule containers, rule modules and BAdI implementations. The rules or the conditions are created as rule modules and are called sub-requirements. Sub requirements are actually implemented as BAdI implementations. Sub-requirements are grouped into requirements which are stored as rule containers. There are two kinds of requirements - concrete requirements and abstract requirements. Concrete requirements are actual requirements which are associated to academic structure objects and call up points. Abstract requirements contain requirement pattern that give a structure to the requirements. For example, in a university, a degree can be awarded if the program requirements are fulfilled by the student. The program requirement can consist of general requirements and major requirements. This structuring is achieved by using a requirement pattern. The requirement such as that the student should have an overall credit of 35 to be graduated is a concrete requirement. The requirements are associated into requirement catalogs. Requirement catalogues are created for each audit types and are associated to students and/or to the programs of study. When an audit is run for the student, the requirement catalogues are checked and the requirements are determined. Sub requirements are evaluated to get the final result.
5.8 Assessment Process During the assessment process students academic work is evaluated. Two types of assessments are supported in SLCM: Assessments for Exams and Assessments for Program Completion/ Stage completion. Assessments are created as academic structure objects and are scheduled for academic periods. When registering to these assessments, an assessment process for the specified student is opened. The assessment process sets a status at the student based on the assessment process step. Exam assessments are created for academic course modules. Students register to course modules and also to exam assessments. Once the exam assessment has been completed, it can be re-used in grading to derive the grade for that student. Finally, a students request for graduation, opens an assessment for program completion. The assessment can link to the degree audit and its result will set the status of the assessment as completed. Once the assessment process has been completed successfully, students are awarded a degree. The assessment process is an optional process in SLCM.
5.9 Graduation Students progress during the course of their study and this process is referred to as progression. To complete their studies at the university, students can use the graduation self service request to request for their graduation. On receipt of the request, the degree audit process is triggered to check whether a student successfully meets the requirements of the institution to get the degree qualification. Based on the audit result, students are awarded the respective degree. After their graduation, the alumni status can be assigned to them by the institution.
6. Student Accounting (for details refer to the Student Accounting cookbook in BPX HER)
Student accounting supports the following processes at universities and educational institutions: Calculating fees that students need to pay for their studies. The fees are posted in the contract account of the student and then to the general ledger (G/L) of the institution. Here SAP SLCM is integrated to SAP ERP Financials. Calculating the grants that students receive to pay for their studies and other institutional expenses. The grant amounts are also posted onto the students contract account and finally to the G/L of the university. Managing the university funds in providing the grants or awards to the students. Here SAP SLCM is integrated with Controlling and Funds Management of SAP ERP FIN.
The fee calculation process uses the students study data and calculates the fees that the student needs to pay to the university. Fee calculation allows calculation of fees for individual students, or in a mass run for several students. Calculation takes place based on a set of business rules referring to the student master data and study details. The rules are set up using the SAP ERP SD pricing tool. During fee calculation the rules are evaluated and results are calculated Each fee calculation run creates fee calculation documents. Fee calculation documents are required for audits and are used to analyze the calculated result. After calculating the fees, administrators can manually correct the calculated result and finally post the result to the student contract account. Calculated fees are posted into the student contract account as an FI-CA document. It is a Financial Contract Account document that contains the fee information for the students. The documents line items show the
fees that the student has to pay based on grouping such as tuition fee, meal fee, hostel fee. The grouping can be configured and is based on contract object types that are defined for the contract account. The contract object type defines the type of fees which are posted. The due date schedule defines the date when the student has to pay a certain fee. These dates are derived from the academic calendar. Based on the due date schedule, the fees are split and posted separately into the student contract account. Universities can also distribute these revenues using Public Sector Funds Management. The fees calculated for the students or the financial aid calculated for the students can be integrated to funds management. For example the revenue that the university gets out of fees can be linked to a fund. In addition a university can use their own funds in giving grants or financial aids to the students. The fund center, fund and controlling rules are associated to the objects in the academic structure. During posting of the fees or the financial aid amount, the correct fund centre, fund, and profit centre are derived from the academic structure objects such as organization unit and the program of study. The derivation of the fund management objects is based on the controlling rules defined at these academic structure objects.
7. General Concepts
7.1. Authorization (for details refer to the SLCM authorization cookbook in BPX HER) Access to SLCM data can be restricted in the sense that authorization is based on the type of data - master data and transaction data. Master data access authorizes users to create/change/delete master data. SLCM master data is mainly HR data and BP data. For HR data the authorization is carried out using Basic authorization For basic authorization, objects are created and checked in the programs. User profiles and PFCG roles are created based on these authorization objects and are assigned to the users using SU01. Structural Authorization Authorization checks in Student Lifecycle Management are using HCMs structural authorization. It is based on HR objects P_CM_PROC and PIQ_PLOG. PLOG checks whether a user is allowed to read, write or insert specific HR infotypes. P_CM_PROC checks whether a user has the authorization for a specific Student Lifecycle Management process. SLCM provides BADI HRPIQ00AUTHORITY which is called during each authorization check but this BADI cannot be used for complex requirements, e.g. context sensitive authorization checks. That means that the assignment of different activities (=business contexts) which span across different organization units is not possible. The list of HR objects that a user can access are determined using an evaluation path. The evaluation path is configurable and has a root object. All other objects are determined from the root object which is related to the root object where the relationship is maintained in the evaluation path. A profile is created using the evaluation path and assigned to the user using HR customizing. For checking additional authorizations at student master data, there are BAdIs available. To set authorization at Business Partner data, event AUTH1 for BP object BUPA can be used. Transaction data access authorizes users to execute business processes within SLCM. For example, an instructor is allowed to do grading but not to carry out admission. This process based authorization is achieved using authorization objects which check the authority of the user to execute the process. The list of processes is delivered by SAP.
7.2. Audit Trail of Processes (for details refer to the SLCM audit trail cookbook in BPX HER) Audit Trails track master data changes and changes within administrative processes to show which data was changed when and by whom. Student Lifecycle Management offers two concepts: Change Documents and Activity Documents: Change Documents Change documents log master data changes and always refer to an application. They show the technical audit trail of a process and record changes to data base tables. Activity Documents
Activity documents show the business audit trail of the process and always refer to a business process and the student for whom the process is executed. Activity documents are linked to the change documents that
are created during the execution of the process. Activity documents are created for all business processes that are delivered by SAP.
7.3. Correspondence The correspondence functionality enables universities to print documents containing student and academic information. The tool can be run for individual students or for a group of students. Correspondence is FI-CA based and has been adapted to support correspondence requirements for SLCM by adding correspondence types specific for SLCM. There are three correspondence types supported in SLCM depending on the available data: Student Correspondence Student correspondence helps to create and print documents containing student information. Admission Correspondence Admission correspondence creates documents containing information about the admission details of the student. Admission correspondence is run immediately after the admissions process is completed. Module Correspondence Module correspondence creates documents with information about the courses that the student studies.
Correspondence is done in two steps: Correspondence creation: This creates the document and stores data in the correspondence container. Correspondence Print: This step moves data from the correspondence container to the print workbench and uses the print workbench to print the document.
7.4. Archiving (for details refer to the SLCM archiving cookbook in the BPX HER Knowledge Center) SLCM supports archiving information that is no longer required, e.g. after the student has graduated such as: Student master records Contract objects and contract accounts Activity documents Change documents FI-CA documents Fee calculation documents Audit runs, etc. Archiving re-uses standard archiving functionality from SAP_BASIS. Archiving functionality is developed based on ADK (Archiving Development Kit) which is the technical framework for archiving. ADK provides the runtime and administration environment for SAP archiving. Archiving objects are created for SLCM to support the archiving requirements. 7.5. Student Self Services The University provides students self services for students and staff based on SAP web dynpro technology. These online applications are available: Degree Audit Grading / Appraisal Academic Advisor User Interface Course Registration User Interface Missing Grades (alert report) Incomplete Grades (alert report with Web Interaction) Student Self-Services Student Admission Application Student Admission Audit Change of Program
Change of Specialization Grade Change Request Graduation Request Address Maintenance Special Booking Authorization Equiv. Determination Simulation Transcript Request Online AuditsAudit run application in student mode View academic work information Course Request Room Search Maintain Transcript Attendance Tracking Faculty Workload report Academic Substitution
Universities need to ensure that data which students can change via self services are in a secure environment and do not allow access directly via the HTTP protocol. To achieve this, self services need to be deployed in a specific way at the universities. The self service online course registration is deployed in a different way. See the following chapter for details. To achieve secured calls from the web application (self services), the recommended way is that all student sensitive data is decoupled from the system in which students access the self service applications. This means the solution IS-PS-CA needs to be installed in two different systems. One is the front end application where student self services are deployed, the other one is the back end application where all the student data is maintained. The university can set up a firewall between the front end and the backend system so that access to the backend system takes always place through the firewall. Students request data in the frontend application. This request picks data from the backend application via RFC calls to ensure security. The figure 6-1 below shows the architecture of all student self services except the Online Course registration. Students can access the application either as a standalone application through a web browser or through the application deployed in SAP Enterprise Portal. In the latter case, the enterprise portal should be connected to the front end application where IS-PS-CA is installed. The user interface is built with web dynpro screens. All UI displays and actions of web dynpro screens are handled by the user interface handling layer. UI handling layer consist of a set of assistant classes that handle the user requests in the applications. The assistant classes use the model classes to fetch the required data. All those data such as customizing settings and academic structure data that are read only in the web application are read from the front end system so they need to be set up in the front end system. All student related information is read and updated in the back end system using RFC calls. So the back end will have all the student information maintained. In addition the back end system can be firewall protected (to allow only RFC protocol based calls) to prevent attacks from outside.
7.5.1. Online Course Registration (for details refer to the Online Registration cookbook in BPX HER)
With this web application, students can register for courses themselves without having to contact their academic advisor or administrative staff to book a particular course: Students can see their courses with statuses registered, cancelled, waitlisted and special approvals. Students can search for courses and store them in the registration cart to be booked later.
The Course Registration application allows students to view and register for courses that have been suggested by their academic advisors for a particular year and session. Course registration corresponds to the module booking function in the back-end system. The application has an intuitive and flexible user interface characterized by high performance. A general authorization check at application level and data level ensures that users can perform permitted actions only. In addition, customers can implement a firewall to protect their productive server from outside attacks. This means that the UI layer and the business logic layer are totally separated and are installed on different servers. As shown in the below figure, students access the application either as a standalone application through a web browser or through the application deployed in SAP Enterprise Portal. In the latter case, the enterprise portal should be connected to the front end application where the thin client application (package PMIQ_COMP) is installed on a SAP NetWeaver instance without installing any ECC (ERP Core components) on it. The separation as two layers front end and back end has a twofold meaning here: Functional Separation The Course Registration UI like the student UI in general, should have a clear separation between UI and backend function. The frontend part (the part shown in green) includes only the UI related functions, such as UI presentation or help text/documents or UI related handling and logics. All the business logic and data storage are controlled only by the backend part such as read/change/check/search information. The frontend communicates with backend parts only via RFC calls. The user requests are handled by the UI handler layer which calls business abstraction layers. Business Abstraction layer handle the logic of decoupling the front end application with the back end. Abstraction layer contain a list of BAdI implementations that direct the calls to the backend application. The BAdI implementations call the Business Logic Layer in the backend using RFC enabled function modules. The BAdI implementations can be replaced by Enterprise Service Calls that also call the backend application. DDIC Separation/Independence The objects in frontend and backend shall be stored in 2 different packages: PMIQ_COMP and PMIQ_ESOA_ST. The package PMIQ_COMP should only use DDIC objects from package SAP_BASIS or SAP_ABA. Any DDIC objects from PMIQ* (except PMIQ_COMP) are NOT to be used. Customer can then install the frontend layer on a very thin and clean system, which has no ERP components. Due to the separation of frontend and backend, customers can add a firewall (to allow only RFC protocol based calls or enterprise service calls) between the frontend and backend system. Students can only access the frontend servers which are outside of firewall. Their operations are filtered and limited by the firewall. All the productive servers are inside the firewall and are protected. Another advantage is that in case the frontend system faces technical problems, the backend system can still be kept safe still. Internal staff, e.g. registrars or administrators, can still work in the productive and secured system.
7.6. Integration of SAP SLCM SAP SLCM offers integration capabilities to other applications. In all integration scenarios, the business partner part of the student is the leading entity. The following integrations already exist: Integration SAP CRM and SAP SLCM BP to support student recruitment Integration with SAP NetWeaver Identity Management Integration with SAP/non-SAP applications: SAP SLCM uses SAP NetWeaver Process Integration (PI) to provide student master data, academic structure data and student study data to any SAP or non-SAP applications. Integration to SAP Records Management to manage students study records: During admissions, the university can request study records such as certificates and transcripts from the applicants previous university. These documents are stored in records management to support the admission process.
7.1. Integration with SAP CRM (for details refer to the SLCMCRM integration cookbook in BPX HER) SAP Customer Relationship Management helps an organization to manage the relationships with its customers. In a university environment, customers are represented by applicants and students and the university can manage its relationship with them through SAP CRM Marketing functionality. Student Recruitment is a process for which the BP integration of SLCM with CRM can be used. Educational institutions can set up and run recruitment campaigns to attract and recruit students for their upcoming academic session. Recruitment activities include campaigns in which different communication channels can be applied to keep in touch with prospects (e.g. via surveys, follow up activities, emails, etc.). Survey results can e.g. be used to identify the academic interests of prospects and to send out appropriate academic information materials. The SAP Business Partner is the entity that exists in both systems and acts as entity for integration. A student in SLCM is a business partner with role Student. This business partner can be replicated to SAP CRM as business partner with role Student Record Holder. This happens vice versa also. When a student record holder business partner from SAP CRM is replicated in SAP SLCM, it will have the role Student assigned to it. The integration takes place through CRM middleware. The integration reuses standard functionality of CRM BP integration with ERP. The replication can be triggered from both systems.
7.2. Integration with SAP NetWeaver Identity Management User management of SAP SLCM is integrated with SAP NetWeaver Identity Management (IDM) which allows to manage users centrally in an identity management system. In a typical educational institute landscape, there are multiple applications in which students have users, for example, library management system, university portal, and SAP SLCM. With the SAP NetWeaver Identity Management it is possible to manage student users for all these applications centrally. The integration is available from SAP SLCM Enhancement Package 5 release onwards. SLCM is integrated to IDM from the student perspective. All students who have a user in SLCM receive an identity in IDM. Creation of student identities in the identity hub and provisioning of users in SLCM and portal are similar to the existing HCM employee scenario in IDM. The student identity in IDM will have attributes of a person or employee (attributes relevant from an SU01 user) and additional attributes relevant for a student user. The additional attributes are set by SLCM when the identities are created. These attributes distinguish the student identity from other employee identities. After identities are created, users can be provisioned in SLCM system or enterprise portal or other applications connected to IDM. This provisioning can be manual or automatic. The attributes of the identity are used to create rules or logic to assign business roles while user provisioning from IDM. The rules or logic are scripts such as Javascripts which decide what roles to be assigned to the user during provisioning.
7.3. Integration with SAP/Non-SAP Applications (for details refer to the SLCM Post Processing cookbook in BPX HER) SAP SLCM offers Enterprise Services to integrate SAP or non-SAP applications. For master data exchange, services exist which reuse existing BP integration services and include SLCM specific attributes. SLCM also offers Remote Function Modules (RFCs) for integration with other applications. Student master data are replicated or integrated to other systems using the standard integration feature of SAP Business Partner (BP). The enterprise services for BP are enhanced to include student details so that standard BP integration is used for student master data integration. There are enterprise services available to integrate academic structure data and event planning data to a Learning Management System (LMS). Also, student lifecycle processes like admission, registration, and graduation can call enterprise services to push data from SAP SLCM to other SAP/non-SAP applications. Often integration with external non-SAP systems requires additional integration logic, data evaluations, and mappings. The post processing framework which is part of SAP ERP allows to insert certain logic after a standard student process is executed successfully. A real-time integration is possible by calling the outbound asynchronous process enterprise services on successful completion of an SAP SLCM process. Systems such as financial aid systems require the study details of a student. Financial aid systems help universities to find and manage the aid or scholarship for students. The financial aid systems require the upto-date details of the student studies. The post processing framework calls the enterprise services automatically on change of the student study details. These enterprise services can be used by the financial aid system to get updates of the students studies. Mass reports help in replicating data to other systems during the initial set up of the integration scenarios. Reports are used for initial load where the integration is just set up or during delta load where the integration should be switched off for some time and switched on again. The reports call the enterprise services and update the data from SAP SLCM.
Related Content
All mentioned cookbooks are available at the Higher Education & Research Business Process Expert (BPX) Community at https://www.sdn.sap.com/irj/sdn/bpx-highered. The Student Lifecycle Management Online Documentation is available on the Help Portal: https://help.sap.com/ -> SAP ERP Central Component-> SAP ERP Enhancement Packages-> Industries in SAP ERP-> Student Lifecycle Management (IS-HER-CM) For more information, visit the Business Process Expert homepage.
Copyright
2011 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, System i, System i5, System p, System p5, System x, System z, System z9, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, POWER5+, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. MaxDB is a trademark of MySQL AB, Sweden. SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. These materials are provided as is without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages. Any software coding and/or code lines/strings (Code) included in this documentation are only examples and are not intended to be used in a productive system environment. The Code is only intended better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, except if such damages were caused by SAP intentionally or grossly negligent.

Sap Her

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Sap Her

Загружено:

Авторское право:

Доступные форматы

Student Lifecycle Management Product and Architecture

Created on: 20 February 2011

SAP DEVELOPER NETWORK | sdn.sap.com 2011 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 1

Student Lifecycle Management Product and Architecture

SAP DEVELOPER NETWORK | sdn.sap.com 2011 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 2

Student Lifecycle Management Product and Architecture

SAP DEVELOPER NETWORK | sdn.sap.com 2011 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 3

Student Lifecycle Management Product and Architecture

SAP DEVELOPER NETWORK | sdn.sap.com 2011 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 4

Student Lifecycle Management Product and Architecture

SAP DEVELOPER NETWORK | sdn.sap.com 2011 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 5

Student Lifecycle Management Product and Architecture

SAP DEVELOPER NETWORK | sdn.sap.com 2011 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 6

Student Lifecycle Management Product and Architecture

SAP DEVELOPER NETWORK | sdn.sap.com 2011 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 7

Student Lifecycle Management Product and Architecture

Time limit Infotype

SAP DEVELOPER NETWORK | sdn.sap.com 2011 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 8

Student Lifecycle Management Product and Architecture

SAP DEVELOPER NETWORK | sdn.sap.com 2011 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 9

Student Lifecycle Management Product and Architecture

SAP DEVELOPER NETWORK | sdn.sap.com 2011 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 10

Student Lifecycle Management Product and Architecture

SAP DEVELOPER NETWORK | sdn.sap.com 2011 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 11

Student Lifecycle Management Product and Architecture

SAP DEVELOPER NETWORK | sdn.sap.com 2011 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 12

Student Lifecycle Management Product and Architecture

SAP DEVELOPER NETWORK | sdn.sap.com 2011 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 13

Student Lifecycle Management Product and Architecture

SAP DEVELOPER NETWORK | sdn.sap.com 2011 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 14

Student Lifecycle Management Product and Architecture

SAP DEVELOPER NETWORK | sdn.sap.com 2011 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 15

Student Lifecycle Management Product and Architecture

4. Student Master Data

SAP DEVELOPER NETWORK | sdn.sap.com 2011 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 16

Student Lifecycle Management Product and Architecture

SAP DEVELOPER NETWORK | sdn.sap.com 2011 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 17

Student Lifecycle Management Product and Architecture

SAP DEVELOPER NETWORK | sdn.sap.com 2011 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 18

Student Lifecycle Management Product and Architecture

5. Student Lifecycle Processes

SAP DEVELOPER NETWORK | sdn.sap.com 2011 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 19

Student Lifecycle Management Product and Architecture