Many companies who implement Workday have previously invested heavily in SAP. They might have SAP ERP, SAP PY or SAP CRM that needs to be integrated with Workday. This usually also raises a big concern: how does an Object-Oriented Cloud System like Workday integrate with SAP? Can Workday easily make iDocs for SAP to consume?
It is important to make correct decisions about data
When tackling this issue, many technical questions are raised and solved. This however is not the only key to build a successful SAP Integration from Workday. Workday implementations are often short compared to those dedicated to on-premise solutions. SAP Integration however will require time for preparation works before the integration build can start. To have the integration ready on time, it would be advantageous to even start discussing and designing it before the Workday projects begin. Early design discussions allow critical topics to be explored and possible gaps identified before the build commences.
For example, it might sound like a good idea to have scheduled weekly hours in Workday, as it is needed for reporting, but leave information about work shifts in the payroll system. However, be aware that SAP infotype requires both scheduled weekly hours and work shifts information, and unnecessary complications are created by splitting the infotype between two systems.
Scope should also be discussed. Of particular interest should be how to handle rescinds and corrections. A top-down view, the “big picture” discussion can also drive decisions and should be taken early in the project - what needs to flow to SAP and what needs to flow back from it. Once you understand your scope and requirements, review possible ready-made connectors by SAP vendors. This can speed up the project significantly.
Collect the correct experts
So, who should be participating the early design discussions? Firstly, the data model must be discussed and agreed. In short, what do we need to maintain, where, and why.
As a result, you should surface what the integration must control, what will need to be actioned manually, and perhaps most importantly, what can be dropped completely. Or, should our integration raise a warning, that manual handling is needed in some specific cases etc.
Here we need someone who can comment from the business side and understands SAP as well, to act as the SAP Expert. If payroll is in scope, we also need a Workday Compensation specialist that can either advise on Workday HCM Core too, or we will also need a Workday HCM Core specialist.
Ensure we reserve the resources on time. It is not enough to hire a “Workday Integration Guru”, we will need to gather people with crucial skills: SAP ABAP programming, SAP Payroll or SAP ERP knowledge, and Workday’s integration technologies. These people must be managed by a skillful Project Manager who is aware of the complicated nature of SAP Integrations.
Time to build
So, we have made our design, everyone agrees on data model, and we are ready to start with the integration design. How should we proceed? Based on many years of experience with such integration builds, my suggested best approach is to use Workday standard integration technologies like Payroll Effective Change Integration (PECI). Transformation should then be functioned by SAP, since Workday is not able to understand specific SAP logic, which can become a showstopper eventually. For example, Workday cannot easily replicate closing records for iDocs.
If for some reason we cannot use SAP for our transformational needs, we should carefully consider our resources. SAP Integration requires a lot of “if-then-else” logic, many different types of effective date, and very complex mappings. Additionally, whoever is going to own the transformation requirements, and ensure these are delivered, must understand the underlying business needs in different scenarios. Use the best-fit resources, and make sure they are the people that will execute the transformation.
Document and test!
Additionally, everything should be documented carefully and clearly. The integration will have very complex mappings, business logics and typically, maintenance will be difficult. By documenting thoroughly and clearly we make life in production much easier.
Besides high-quality documentation, these integrations must be tested in detail. Go through all different business scenarios including standard “business as usual” and exceptional use case scenarios. For example, a worker having a transfer and long-term absence simultaneously. Don’t just focus on one scenario at a time. Remember to test end to end critical processes including how these behave in SAP. Remember also to think about how to handle scenarios which are not in the integration scope.
Interested in finding out more? Do not hesitate to contact us and we will gladly guide you with your Workday Implementation or help with your existing setup. Tietoevry can provide Workday and SAP experts for your specific needs, both functional and technical.
