05/16/11

Attendees:
Georgetown Project Manager - Marjorie Boursiquot <mb574@georgetown.edu>
Cornell - Vicky Mikula
Cornell - Steve Lutter

Integrations:
Georgetown is changing their model with the WD go-live.  They used to have 3 feeds - (1) transportation ; (2) key cards ; (3) id mgmt.   Going forward they are only going to feed the Id Mgmt system.  Systems, such as transportation and key cards, that need this information will go  directly to Id Mgmt and not Workday. Id Mgmt system will contain employee bio/demo and primary/secondary affiliation information (employee, student, alumni) - ie: job profile, supervisory org (department), home address/phone number, work address/phone number.   A 9 char GUID and a central netid for email system are maintained by Id mgmt.

* Marjorie will send the ID design document to me.

The integration with Id Mgmt is event driven with an end of the day reconciliation file.  Once the hire event is complete in WD an event sends the information to Id mgmt system.  
The event is triggered off of a manual business process and the existence of key data elements (bday or name or identifying information(I9)).  Id Mgmt creates an id and is sent back to WD and stored into a custom ID field.  WD matches on social security number.   The process for checking duplicates is manual.

Original WD provided estimate of hours for design to integrate with Id Mgmt system was :  160 hours -  but it took longer.  Marjorie doesn’t have the actual hours but guesses over 320 hours.

In order to create event driven integrations the BP’s must first be completed or at least 80%.  WD will push to start building integrations before these are completed and its a waste of time in most cases.  The BP is a prerequisite.   Must have the business process definition at 80% before can move forward on determining when to call out to outside systems.  Georgetown had to wait until the design is down.

Resourcing:

• 3 full-time technical managers (came from Central IT office) for HR/Payroll/Benefits.  Helped with design of integrations.
• 4 functional leads for each area HR, Benefits, Payroll and Absence Mgmt (added later - was a gap).  1 lead came from internal business office ;  2 new hires and 1 is a consultant (Towers Watson).
• The Id Mgmt Integration - 1 HR technical person from HR system working directly with WD Integration (full-time) and 2 Id Mgmt team member.  Began project with just WD and ID Mgmt team.  WD Integration specialist had to determine where in WD to pull data from.  The project had to wait until the BP was designed and existed in a working tenant.  WD did not account for this lag in time.  Time factor is based on the experience of the WD integration specialist.   Georgetown’s WD Integration person was new and relied on mentoring from WD’s HR functional person which caused some conflicts.  Rare to find an integration person who understands the BP in detail.  
• Project Management - initially 1 PM.  Then appointed testing and integration leads.  
• Need a testing coordinator - product changes throughout project.  Its a constant moving target.
• Need a data conversion lead - Georgetown does not have this role and has realized they should have incorporated.
• Size of project team - 3 technical at 100% who used to manage current systems ; 4 functional leads at 100% ; 1 tester at 100% (test, test, test scripts etc) ; PM at 100% from Central IT ; 1 reporting lead at 100%
• Consulting help - 1 from Towers Watson
  Extended team included SMEs

Misc:

• No support from WD implementation project to shadow systems - had to be absorbed by the units
• Time Collection
  • No TC system
  • There are specific groups of ppl who have time clocks.  The time clock information is entered into an Excel spreadsheet and manually entered into the Payroll system.
  • Others entries use timesheets for Payroll manual entry.
  • Could not use WD’s TimeIn/TimeOut - no costing model.  Going to use Hours Worked timesheet within WD.
  • Split shift workers need to be tracked in TimeIn/TimeOut per Georgetown’s legal council’s but they do not have split shift workers.
• Is Georgetown building an integrated Data Warehouse - No.  
• Building an operational datastore to ensure shadow systems don’t break.  
  • using some of the data warehouse staff for this.  
  • 1 reports lead is focused on this - what information needs to go into the data store.
  • 2 people from data warehouse team working off/on with reports lead
  • To-date estimate - 2 weeks a month since February ‘11 (data warehouse ppl)
  • Going forward estimate - 2 full-time data warehouse resources.  Georgetown does not have cross domain reporting (at least not as integrated as CU).  They tend to propagate data across domains to get integrated reporting.
• Integrations with external vendors - elongate the timeframe that WD gives you.  WD doesn’t account for delays when working with vendors.
• WD had planned for integration design work to start in October ‘10 although functional design work was  not completed.  Original estimate - design, build and testing starting in October ‘10 and ending in Feb ‘11.  Today’s plan - still trying to design and build and won’t be done testing by July’ 11.  WD does not plan contigency in their estimates (for instance - issues from vendors, purchase order delays etc.).  They don’t factor into the estimates peripheral items.
• PS 7.6 Finance - inbound from PS to WD (cost centers/accounts) - 2 files.  Outbound from WD to PS (payroll - actuals, encumberence, adjustments, accruals, fringe) - 5 files.  GL is detailed employee information of payments.  PS Finance system - SQR changes were not included in the project.  2 developers to make these changes (200 hour total effort for the 5 files).  Transformation is done in the SQR and is fairly simple.  
• Emergency Mass Notification system - yes but from ID Mgmt system.