A fully custom absence management system that rationalised 6 existing absence management systems in 12 different entities in 4 languages. Documented, built, tested and delivered in less than 120 days.

1. GLOBAL BANKING & INVESTOR SOLUTIONS DIVISION
CORPORATE & INVESTMENT BANKING, PRIVATE BANKING,
ASSET MANAGEMENT, SECURITIES SERVICES
3/7/2016
THE CLOCK IS TICKING:
Societe Generale Absence Management
3 March 2016

2. |
Agenda
P.2
1. Introductions
2. Business Drivers
3. Goals & Objectives
4. Planning & Governance
5. Design
6. Page Layout & Testing
7. Metrics
8. Post-Mortem
9. Q&A

3. |
Introductions
P.3
Duncan Hartree
PeopleSoft functional/technical expert with 15 years of HCM experience
Project role: Functional and technical design
Nidhi Shah
HR PMO & Systems Associate with 11 years experience in the Investment Banking industry
Project role: Functional specialist and business analyst

4. |
Business Drivers
 Lotus notes being retired:
• Platform management moved to Paris
• Support scaled back
• Increasing costs
 PeopleSoft absence management:
• Experience with existing user group suggested that current version was not fit for purpose
• Application upgrade required approval from Paris
 1st of April is start of the new holiday year for SGCIB:
• Switch of absence system at any other time likely to cause more support issues and queries
• Newedge integration due to complete on the 1st of April
• Close to start of year for other entities
 Global approach to absence management:
• Reduce costs of multiple systems
• Common approach helps simplify business processes
P.4

5. |
Goals
 Replacement of existing absence systems:
• Bespoke AMS in Lotus Notes (used by approximately 50% of population)
• Bespoke PeopleSoft solution (used by single entity - ALD)
• PeopleSoft Absence Management (used by all European entities)
• 3rd party off-the-shelf solution (Security Services)
 Move responsibility of absence to employees and mangers:
• Lotus notes solution relied heavily on team based administrators
• ALD managed via spreadsheets sent to HR for entering into PeopleSoft
• PeopleSoft absence management, inherited configuration from Paris that was supported out of London
HR
• Security Services managed by HR
 Create a common interface and approach for the management of absence:
• Standardisation of reports
• Single source of data
P.5

6. |
Objectives
 Build a solution in PeopleSoft self service using vanilla elements:
• Use prior experience of building a similar solution to define the key design elements
• Utilise work schedules and templates, vacation plans and holiday schedules
 Provide a configurable solution:
• The solution should allow for the enrolment of additional entities with minimal code changes
• Solution must be flexible enough to allow for configuration changes but also intuitive for support
 Self service must be simple to use and user friendly:
• Self service page must be in local languages (English, French, German & Polish)
• Graphical representation of annual calendar is required
• There must be a running total of balances
• Users must be able to see details of historical and future absences
 HR must be able to deal with any exceptions:
• HR must be able to break the rules if and when needed
P.6

7. |
Planning & Governance
Why did we end up with only under 4 months to complete the project?
 Upgrade to version 9.2 put on hold
• Business decision taken in Paris and only communicated to project team early summer
 Investigation into 3rd party applications
 Extension to lotus notes production cycle
 Purchase of bolt on module for PeopleSoft
 In house development vs 3rd party consultancy
• Resources
P.7

8. |
Design (Key Decisions)
 Minimum absence resolution is half day
 The approving manger is the reports to position in PeopleSoft:
• The team is defined as all those people that share reporting hierarchy
• The reporting hierarchy is defined as the reports to field on position data
 Strict pro-rating of holiday based on formula
• (elapsed days/days in period) * total annual equivalent rounded up to nearest half day
 No absence can span the end of the period
 Changes to work schedules or holiday schedule that could result in changes to
duration calculations will be have to be processed manually
 Delegations are team based and not on an individual basis
 All absences will be stored in ABSV_REQUEST
 Only one ABSV_ACCRAUL row can exist per person for a given period:
• Changes of company or empl_rcd are effectively a clean slate
P.8

9. |
Page Layout (Company Absence Information)
P.9
All options specific to each company
held in a single place
Not all fields on this page were fully
realised at the start of the build
Email language is independent from the
login language

10. |
Page Layout (Company Absence Type Configuration)
P.10
Divided into 3 logical areas:
• Validations
• Interfaces
• Permissions
Absence type group
• Logic only coded against groups - not
types
Validations only apply in self
service
Permissions apply in self
service and core

11. |
Page Layout (Employee Self Service)
P.11
Links and legend are dynamic
Tool tips on calendar
Approvals are dynamically
calculated
Start of the period is defined
in company configuration

12. |
Page Layout (Employee Self Service)
P.12
Only relevant balances display:
• Possible balances are holiday, carryover, time in lieu, volunteering, child care, study leave and banked holiday
Logic rules determine if and when an absence can be edited or deleted
Balance is only updated for requests at a status of approved or pending delete

13. |
Page Layout (Employee Self Service team view)
P.13

14. |
Page Layout (Booking an Absence)
P.14
Content dynamic
Duration calculated based
on work schedule
Validations carried out
based on configuration

15. |
Page Layout (Manager Self Service)
P.15
Action requests
Manage delegations
View wider population
Drill down into
organisation
View read only version of
employee home page

16. |
Page Layout (Approving a Request)
P.16
Return to work:
• Required when an employee didn’t enter the details of the request
• Absence rolls forward until completed

17. |
Page Layout (Approving a Request)
P.17
Email sent to employees:
• Simple calendar invite

18. |
Page Layout (Delegations)
P.18
Delegations only ever active to one level
No request queue, all requests go to the current approver

19. |
Page Layout (Core Component)
P.19
No emails triggered from
the core
No validation rules applied
to requests

20. |
Testing
 Phased approach to testing
• Based on criticality of module
P.20

21. |
Metrics
 Numbers at the time of go-live:
• 4,605 employee self service users
• In the first week 1,784 absence requests were raised
• Rolled out to 12 different Entities across Europe and the Gulf regions
• 128 different absence types created all with specific configuration requirements and business rules
• 46 different work schedules
• 93 vacation plans
 Numbers to date:
• 5,991 self service users
• 71,000 requests raised to date
• Now used by 20 entities with more planned for 2016
• 159 absence types
• 68 work schedules
• 123 vacation plans
P.21

22. |
Post-Mortem
 Is this the ideal way to run a project?
 Be very clear on what you aim to deliver
 Prioritise all tasks and be ruthless
 Each functional request must have a strong business case and there must be
benefits across multiple business lines
 People with experience are critical when timing is tight
 Additional 1,500 people added for the 1st of Jan 2016 with the only change being
the introduction of banked holiday
P.22

23. |
ANY QUESTIONS?
P.23