What is a Solution in Workday?
A Solution is a 'collection of artifacts' (Workday's term), or configurations. So if you've built some complex reports in a sandbox environment or if another customer shares a report on the Workday Community, you can import these reports into your Production environment, by compiling them into a Solution.
How do you create a solution?
It's quite simple, in Workday you go to the Create Solution page and enter the details:
The really nice thing about this feature is that you have the ability to attach screenshots or documents to the item. So for example if you would like to attach additional manual configuration steps that should occur, these can be attached here. As well, I like the Description fields. Then, it's only a matter from a process and procedure standpoint, to ensure that people always complete them. :)
You then have a choice to either 'Save and Publish' or to 'Save and Migrate'. You then are walked through some more wizard-like screens that guide you in making decisions of what tenant you are sending the item to, etc. Importing a solution published by another customer is as equally simple, just follow the on-screen guidance.
My thoughts on this one:
- I am impressed with the ease of use. Not sure about you SAP folks, but in a PeopleSoft world, custom items are packaged into a project which is then migrated to another database. It's not quite as 'point and click' as we see here.
- As well, not sure about other companies, but trying to move small items such as calculated fields or a handful of reports does not work in our current ERP, due to the efforts of getting a developer to package it and to send it through the testing lifecycle. While you still need to ensure that testing occurs here, having the 'ready-made' access to these items should make our lives easier.
The disadvantages of Solution functionality in Workday
- As we've discovered firsthand, if you don't know what you're doing with this functionality, it's very easy to make a big mess. For example, we had someone moving reports that contained calculated fields. If you move something like this, it brings along everything underneath it that it needs. The person didn't realize fully what was in the reports, so we suddenly had 200 calculated fields appear. Fortunately, none of this was Production, but we still have an extra 200 calc fields to clean up.
For those of us in IT, this can be seen as quite a shift of responsibilities, potentially. For example, in our current ERP world, HR Systems Analysts make business requests and design functionality which the developer then makes happen. After testing, we have a 2nd set of IT folks (server admins) who perform our moves to Production, both for SOX separation of duties and as well since things are sometimes run on the database level, such as SQL statements.
In this new WD world, potentially, that server admin is not really needed in this process. Further, I'm doubting that a server admin would have any detailed knowledge of the item being moved, such as a calculated field. If anything, you'd want to keep that move closer to the source, so either an HR or IT Analyst makes a report or calculated field, then a 2nd one (who understands the functionality, but due to separation of duties), would then move the item.
So a changing of the guards in this area perhaps? Should make for interesting times for IT folks...