10 Lessons Learned using BI with Workday

  1. The Workday reporting tool has limitations.
    • The reporting tool looks very intuitive and easy to use at first blush.  You pick a data source, start selecting fields, add some filters, and everything is great.  Then a user requests a specific field…. You finally find this field and realize it is in an object that is not easily accessible by the data source you chose.  So you create 3 calculated fields that stack on top of each other, and use each other as an input, to get this data on your report. Then you realize this object does not behave the way you would expect.
    • Performance can sometimes be an issue.  Yes, even in the cloud.
    • You can not join data sources.  You will have access to the objects contained within the data source you use to create the report.  You will have access to objects contained within those objects, but this will require building Workday Calculated fields to get to.
    • Most objects return the “top of stack”, or most recent, value.  It can be challenging to get a list of changes made to an object.
  2. Compared to creating BI content sourced from an ERP with direct access to a relational back-end data store (ie, PeopleSoft, Oracle, etc.), things take twice as long.
    • You do not have direct access to the data, so you must access data through APIs or Workday’s reporting tool.  There is a layer of logic between the data and the file you get. Figuring out the nuances of this logic adds time to the project that you may not expect.
    • Since there is no direct access to the data, a lot of troubleshooting is done through the reporting tool.  On top of learning a new tool and new ways to access the data, troubleshooting gets a little more interesting, and takes a little longer.
    • In HR there are quite a few manually entered fields that will not have formatting checks at the application level.  You may need to add more data checking/cleansing operations in you ETL than you are used to.
  3. Be involved in the implementation and conversion projects/activities.
    • At a minimum attend the status meetings.  Tenant usages, refreshes, and the like are always shifting.
    • The BI team will discover oddities in the data that will be important to share with the implementation team.
    • You will want to know which tenants have the most accurate data.  What data is sample data vs production versions.
  4. Get appropriate resources and time commitments from experts/SMEs at the beginning of the project.
    • This is a general tip for all BI engagements that are attached to ERP implementation projects.  The ERP resources will have their own priorities and will be focused on getting the system up and running.  This will leave little time for helping the BI team out. As the project moves on, the amount of time they are willing to spend helping BI will shrink.  It’s good to get certain key resources to block out time for working with and educating the BI team from the very start of the project.
    • If you can find someone that has experience in this type of project, you should try to add them to your project team.  At a minimum engage them for a short period of time to point you in the correct direction.
    • It may be hard to find someone with direct BI experience.  Your next best thing may be someone with a broad range of experience working with the Workday objects.  Integration consultants may be helpful, but you may find the necessary skills in unexpected places such as report writers or QA/validation experts.
  5. Make sure your BI team has proper access to Workday.
    • This is a big one.  Since this is a new system it will hard to know what you missing.  You don’t know what you don’t know.
    • You will most likely need integration developer and/or administrator access for ETL developers and architects.   BI developers and analysts will need some sort of report writer role.
    • Ensuring proper data access, can help mitigate wasting time searching for data you can’t find.
  6. Watch out for time zones.
    • In certain circumstances a user’s time zone is used.  In other cases the time zone is of the Workday instance (likely PST).
    • When I used public APIs a couple years ago, values passed as request filters were considered PST.
    • If you are on EST, the Today Global field when passed as a date (instead of date time) will be truncated to date format, and then converted to EST.  This means if you are passing Today as a prompt value on 1-2-2018 01:00:00, what your report will get is 1-1-2018 03:00:00. Workday will start with the PST value for 1-2-2018 01:00:00 (1-1-2018 22:00:00).  It will truncate the time to 1-1-2018 00:00:00, and then convert to EST by adding 3 hours, leaving 1-1-2018 03:00:00.
  7. Be prepared to learn the Workday reporting tool.
    • Since you have no direct access to the data, the Workday reporting tool will be your new SQL.
    • You will most likely develop at least some reports here as RaaS.
  8. Most objects deliver ‘top of stack’ data.
    • Most objects in Workday give you the current view of an employees data (or current as related to an effective date passed to the report).  This means it is tough or impossible to just select an object and see all the changes made to that object.
    • In Workday Human resources there are Worker History and Event based objects you can use source transactional style data.  These data sources, however, like most of Workday have their own subtleties that must be taken into account when using.
  9. Use Workday IDs where possible for joins.
    • WIDs are the unique identifier for an object.  WIDs will stay consistent on the same tenant. You may have to do a full reload, if you switch tenants.  This is not a problem after go live, as all dev tenants are replicas of the production tenant.
    • Typing WID:{insert Workday ID value here} in the search bar, will take you directly to the object.  This is useful for troubleshooting.
    • Some objects will select WIDs from different objects based on some logic.  For example, the Position object from the All Positions objects will use the Position WID for filled positions, and for positions that are not filled the Position Restriction WID.
  10. Validate until you don’t think you need to anymore. Then validate once more.
    • Trust but verify… Use whatever slogan you want to get the point across to your team.  Workday object behavior, and by extension the data, will sometimes be what you expect and sometimes it will not.  You will need to work with the data and validate it from different angles to make sure you understand what you are getting.
    • I generally like to validate the data throughout the project.  Make sure if you are validating data at the beginning or middle of the project you are sourcing from the tenant with the best data for your validation.  In other words, sample data you get at the beginning of the project will change.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s