As we undergo a BI implementation with a cloud-based ERP provider, I thought it would be interesting to share some of our insights. As you know from previous posts, Georgetown has been undergoing a large ERP implementation on the Workday ERP. We are now live on both HCM and Financials.
The Business Intelligence (BI) project has been running in parallel to this effort and I wanted to share some initial findings in the event that it may be helpful for others.
Here are our top 10 gotchas:
#10 – Be cognizant of time zones. When you are setting up incremental nightly data pulls, ensure that the user account that you are utilizing is in the same time zone as the underlying tenant. Otherwise, you might spend hours validating data that may be hours out-of-sync (e.g. user account to extract data is in EST and the tenant is in PST).
#9 – Chop the data into sufficiently sized extracts to prevent timeout issues. This may be less of an issue on a nightly basis, but is important if you are loading historical data or preparing for a time in which there is a large integration into the ERP. Large integrations (e.g. from your Student Information System into your Financial System) can cause a nighly extract file to balloon and subsequently fail.
#8 – Send your team to deep ERP training – immediately! Be prepared to know the ERP as well as the team administering it.
#7 – Ensure that your BI team receives the appropriate security that they require in the SaaS ERP. If this gets into policy-related issues, ensure that you work these through with the respective owners in advance. You may have to work through operational protocols and procedure that are not expected.
#6 – Plan a strategy for how you will create BI related content in your SaaS-based ERP. Typically, this development needs to occur in a lower tenant and migrated to production. How will you access these environments? What is the path to migrate content? Be prepared that some sandbox tenants may refresh on a weekly basis (i.e. BI content may not reside there for longer than a week). Consider the notion of development in a dev tenant, migration to sandbox (which may refresh weekly), and then to production. The timing of this process should feed into your planning.
#5 – Set up BI extract notifications. We setup a specific email address which routes to our on call team. These alerts notify our team if any of the extracts failed so that we can quickly extract and reprocess the file as needed.
#4 – Prepare to either learn an API in and out, or work with custom reports in the SaaS ERP. Remember, there will be no direct connection to the database, so you’ll need to find alternate ways of efficiently extracting large amounts of data. In Georgetown’s case, we wrote custom versions of reports from our SaaS-based ERP and then scheduled their output to a XML or CSV format. These files are then processed by the nightly ETL routine.
#3 – Create a portal for consolidation and collaboration of reporting deliverables. We set up a portal which provides instructions, documentation, links to metadata, ability to ask for help, report guides, etc. Make this easy for your end-users to consume.
#2 – Test, Test, and Test. SaaS-based ERP tenants typically go down one night a week for patches and maintenance. This can be problematic for nightly BI extracts. Make sure that you are aware of the outage schedules and can plan around them. ETL routines may need to start a bit later on the day in which maintenance occurs.
#1 – Create an operational structure for the ongoing needs of the BI function in advance. Georgetown is embarking upon a ‘BI Center of Excellence’ that will handle this sort of cross-functional structure which will be comprised of subject matter experts which represent different business units. This will help the business units to continue to drive the development of the platform and allow IT to play a supportive role.
Robert Goodman 