A European solutioning example in Workday

As a global company, we have offices and employees in almost every country in the world.

Much of our North American Workday implementation was based upon US requirements, with a handful of Mexico and Canada business needs sprinkled in.  This design, configuration and use became 'the global footprint'.

Now that we're looking at European countries as part of our next wave of implementation, in general the current use is getting challenged.  In addition, the design is getting extended for business requirements that did not exist in the US, e.g. contract data.

What is European contract data?

 

First, I'm not talking about contractors.  :) In Europe, most countries have the concept of employment contracts, so prior to accepting an employment offer, the contract provides a contract offer to the candidate (i.e. future employee), and the candidate may choose to sign 'as is' or negotiate some of the contract clauses.  Then both the candidate and a company representative sign the contract to make it official.  Each country will usually have different things that they put into their contracts, depending on local business practice.  There is no 'Euopean contract'. 

For comparison, I've worked in three countries for the same company.  In the US I received an offer letter of 2 pages, it listed things like salary and work location.  In Germany, I received a 25 page contract with all of the employment terms and details spelled out.  In the UK, my contract was a little shorter, only 12 pages.

If you get a big promotion such as from non-manager to manager or to a high position, you may get a new contract.  Otherwise, for smaller promotions, your contract would just get an addendum with any new details.

What kind of data is in a European contract?

 

Often, you'll have some general and overarching principles that apply to all employees, such as an ethics policy or general details about working conditions.

A contract will often hold basic data, such as the employee's name, home address, and job data such as title/position, the title/position that the role reports into, weekly hours, pay frequency, pay rate, hire date, seniority date (if differing for benefits calculations), notice period, probation date, etc.

As well, you'll find some 'eligibility' items 

• if a company provides a contribution to a pension on the employee's behalf, what is the percent
• if a company car is provided, what is the level/budget or allowance in lieu of car
• holiday entitlement
• private medical scheme, if offered
• what sort of sick pay you are entitled to
• etc.

 

What is the Workday functionality?

Workday gives us a page for contract data, it looks like this:

• Workday has the usual 'per country' configuration, so that you can set up your Contract Types per country, which is helpful.
• The attachments and comments feature is also there, so that is useful if we want to attach a copy of the contract.

Some of the job-related data found in the contract will be on the 'regular' Workday job pages.  Other data such as pension or health, we can try to store on the benefits screens.  However...

Where we're challenged in Europe, trying to use Workday

There's a lot of great fields on this page, which we would definitely use.  But we're struggling to figure out where to put the rest of the contract data.  It's like we were invited to dinner and only served the appetizer.  My current thought is that this page was designed without European input.  Mexico does have more of a concept of contracts, so maybe that was the driver, who knows.

Here are some areas that are providing heartburn at the moment.  And specifically, our payroll systems in the countries do have the concept of contract data, and would like to receive it on an interface from Workday.  Our HR people as well would like to be able to store and view this data.  So where are the disconnects?

1. Notice period

 

This particularly pains me, as it's such a basic concept that any European based HR system would contain.  A notice period is included in your employment contract.  The higher your position, the longer it is likely to be.  None of this '2 weeks notice' in Europe!  My notice period in the UK and Germany has been 3 months.  High level executives may have 6 months or a year even. 

This applies to both the employer and the employee, and may differ, although if we could just get the employee one, that would be great.

Notice periods are often a 'date in words', for example:  3 months, 6 weeks, etc.  There is an added complexity to some, such as 1 month to the end of the quarter.  I've heard some other companies try to simplify and specify a number of day or weeks.

In addition, local labor law may specify a minimum statutory period, but as a company you may wish to put a longer notice period into place.

Workday has no functionality in this area!

There is a Workday Brainstorm (Workday's mechanism to make change requests to the application) from other companies to at least get a 'notice date' added.

2. Dual contracts

 

This comes up in various EU countries, in particular where we have better benefits than our NA counterparts.  :)  Often, an employee has a regular contract, and as a part of that may receive maternity benefits from either/both the company and/or government, depending on the country.

The employee on maternity may receive their regular benefits, but may want to work part time during maternity leave.  Usually in this case, the company will need to make a new contract with the relevant employment information.

Workday only allows for one active contract at a time!

Again, there's a Brainstorm to get this changed, or at least configurable to allow for two simultaneous contracts.

A workaround is to use Workday's 'multiple jobs' functionality.  If you put the employee into two distinct positions, the employee may have two active contracts at the same time.  However, that's a lot of work to enable, both from a functional and technical side, just to get some minimal contract data into place on a 2nd contract.

3. Contract renewal

In Europe, for better or for worse, it's more difficult to terminate an employee.  Often, we hire people on in temporary contracts.  Depending on the country, you are allowed to extend the contract a certain number of times, but after extension number x, it automatically converts the emp into a 'regular' contract (with all corresponding rights).

Workday missed to include this functionality!

Workday workaround:  Use the freeform 'Contract ID' field and get the data input folks to consistently put in '0001' for 1st contract, '0002' for 2nd contract, etc.  I don't like using freeform fields in this manner, as you end up doing extra auditing as people forget the 0's or make it length 5.

There's a Brainstrorm for this one too.

I could continue on here with my online gap analysis, but I think you get the idea.

Why is this especially irritating?

 

PeopleSoft has a lot more functionality!  Granted, we probably only using 10% of the fields on the pages, but they met our needs.  In my 'notice period' example above, we set up a contract clause for each notice period, such as the 'non competing' clause listed below.  As each employee has a contract, you then choose the relevant notice period clause for that employee.

In Summary

We're continuing to review the data against what our payroll systems need to receive.  As the contract data pages are not very robust in Workday, we'll be left having to 'MacGyver' it in, or not store it at all.

In discussions with our Workday certified consulting partner, the only thing they can tell us to do is: either don't store the data in Workday, or make custom objects, custom IDs etc. to accommodate it, recognizing that you don't have enough custom objects free to meet the needs.  As well, it would just be generally ugly from a data entry and reporting perspective, as well as not in harmony in one place, with some fields on the contract data pages and others independently as custom objects etc.

I think the irritation here is that we currently have a workable solution in PeopleSoft, and in going to Workday it's seen by the users a going backwards as Workday does not come to the table with a real solution here.

Apologies for the radio silence

It's been a busy few weeks here in the UK, and I'm currently working and traveling a lot for our project.

In addition, I haven't been overly pleased with the solutions I've been designing in Workday for our business requirements, so I have not felt compelled to list them out here.  As a little bit of background on that point...

We're heavily in the throes of gathering business requirements for our European countries.  My more HR-oriented colleagues do a great job of gathering the HR folks in the countries and they outline our new global Workday processes and inquire about the local processes that HR do in comparison to our scoped out list of global Workday processes, as well as gathering their field level requirements for those processes.  Then, for anything that does not fit into the global model or is not readily available through existing configuration, e.g. new event reasons, it gets forwarded over to me to provide some solution options and a recommendation.  I look at things holistically, so keeping things in mind like:

• Ease of use for the person doing data entry.  Will they enter it all on one page or have to go to multiple pages?  Are the labels good, or are we heavily mis-using a page (doing it Saas style, as I'm now calling it), so they'll need to ignore the labels and fill in the data entry boxes. 

• Can we interface any of the data in?

• Is this data going somewhere, such as a payroll system?

• How do all the pieces fit together in the process?  Can we get all of the data in a certain step or is this going to be a back and forth to collect data?

• Ease of reporting on the data

• Making is easy for the integration guys, for current as well as future interfaces

• Etc.

As I've been based in Europe for 10+ years, I often know the business needs/use better than my US-based HR colleagues, so some of the things they just throw over the fence to me to define requirements and solutions.  For other stuff, they're doing a great job of gathering data definition, especially where the business does not use PeopleSoft now to meet a need and the central team thinks that we should start to accumulate this data in Workday.

I was talking to a colleague of mine, he's a general all-arounder, understanding technology plus the business use of systems, although his area of expertise is recruiting systems.  He's been assigned a task to investigate a certain area of data that overlaps between the recruitment system and Workday core HR data, and to get a team together to figure out what data should be captured in the business processes.

I gave him a debrief today of the Workday functionality.  It's a common European set of data, but WD is very light on the ground in this area, as it's not data that is used in the US.  I was giving him an overview of:

1. Here are the business requirements that I have heard from the core HR calls in Europe.
2. Here is the data we currently store in our European PeopleSoft instance for this topic.
3. Here is the Workday functionality in this area.

So now we're counting on him and his team to define the business requirements, and I'll then solution them.

He was asking me questions to confirm that he understood the WD functionality and was a little surprised that the functionality was so light in this area.  In particular, it's basically a page with some dates and free form fields.

For anyone who has worked in an HRIS operational capacity, free form fields are the devil's handiwork:

1. They're a hassle for the data entry people who can't just do a few characters of predictive text/choose a dropdown value.
2. They're a hassle for the team responsible for auditing data, as they're always chasing up and having to get corrections to misspellings, etc.
3. They're a hassle for downstream systems, due to a lack of consistency.

Workday modules (licensing woes!)

During the past two years, I've had a chance to do fit gap analysis and scope out how we'll meet our business requirements by data entry and processes within Workday.  As you might expect, a lot of the core HRMS fields are in Workday just like they would be in any other HRMS.  A few gotcha's however:

1. Company credit cards 

• Background  
• we use equivalent functionality in PeopleSoft, mainly with a minimum field set.  We use it to flag that someone has a card, expiration date and card status (closed, etc), but none of the actual card details.  
• We built an interface from the credit card (CC) vendor into PSoft to load the data automatically.  Then the team responsible for credit card administration runs existing reports to see what terminated employees have a non-closed card so that they can close the card and take steps toward chasing up any open balances.  The team in Europe has 90 days to get the balances paid off by the employee, otherwise they are written off.

• Workday functionality 
• Workday has credit card pages, and they look very similar to what we need and currently have in PeopleSoft, yay!
• WD classifies the credit card pages under their 'Expenses' rather than 'HCM' module...so we cannot use them...booo!  :(

• Our WD workaround?
• Use the 'Business Asset' functionality.
• The good:  it allows us by hook or by crook to shoehorn the data in there.
• The bad: we cannibalized the pages to make the data fit.  Also, Business Assets are tied into the Finance Management side of WD, so there's a lot more background functionality that you need to work around.  Don't get me wrong, officially, you can use it under HCM, but you need to take care to not wander into the FM fields/processes, as those are not allowed.

  2. Non-employee/Contingent Worker Suppliers

• Background - we store contractors, consultants, auditors, etc. in PeopleSoft currently, including their provider (Randstad, Hays, etc.)

• Workday functionality
• Workday allows you to store non-emps, yay!
• Supplier (provider) is not an HCM field.  Instead, you're wandering back into the Finance side of things, and having to make big changes to business processes (BPs) to create a supplier setup process to be able to set up a supplier and associate it with a non-emp.

• Our WD workaround?
• Our WD certified consultants would prefer not to do all this extra work to get in one data element.  So now we're going back to the business to inquire further if they really truly need the supplier data on the 70%+ non-employees where they have entered it, or can we drop it when we go to WD.
• If they do not agree either we'll need to start setting up the processes or we'll need to use one of our custom fields instead.

I'm sure we'll find more of these and no software is perfect.  However, I'm noting them here as I wasn't expecting to get tangled up with either of these.  Hope this helps someone out there!

Names in Workday

We're starting to get into the data analysis phase here in Europe.  Something new I learned about Workday today--names are not configurable per country.  To put it another way:  if WD defines that country xyz has name format (first last) and country abc has name format (first middle last), then that is what you get.

Understanding WD is defining a global solution based on name requirements around the world, as they understand them.

Also sitting here looking at the analysis done by one of my analysts to compare our current PeopleSoft names data to the Workday global matrix (a helpful resource that lists out per country the various fields available for items such as names).

We have a mismatch in a number of countries.  :-(

So now, we'll need to look closer, per country, to figure out what to do with our current data.  A few options, of course:

• Delete the middle names from PS.  Don't store going forward.
• Concatenate into the first name field in WD.  Then, get smart coding that parses out the middle name part depending on the country/interface.  Deal with the fallout if Middle Names (located in the first name field) are pulled into a report by an analyst and distributed further.
• Put middle names into another solution such as a Custom Object.  Then build rules that 'if country is xyz, then concatenate this field with First Name when sending the data to downstream system 123.  Force the report analysts to reference it as well.

In a perfect world, WD would make this a configurable item for me, so that I could use checkboxes to select which name types apply to a country.  Just sayin'.

Once we start making the conversion decisions, I'll give you an update about how it all turned out...

Tracking Ethnicity in Workday

Many countries around the world need to track ethnicity data, especially for government reporting:  the US, Canada, the UK, South Africa, etc.  Most HRIS systems give you some options, Workday included.  As it's a SaaS, there's a little less maintenance than in a traditional ERP setting, so thought I'd give you an overview of this today.

Tracking ethnicity at the employee level

Workday allows you to track Ethnicity for an employee under the Personal Information section:

Two nice things about this page:

1. The user doesn't need to know or worry about codes.
2. As the codes are hyperlinked, the user can directly click on them to find out more details about this value. 

Both of these points are an improvement over our current ERP.

Ethnicity setup

Workday delivers the values needed for many countries, and is continuing to increase the list with each release.  I dumped the list for our user, there were around 300 values, maybe 15 or so countries.

For those countries where WD delivers nothing, or where prefer to not use the WD values, you can use the Maintain Ethnicities page to add values or modify current ones.  As well, you can inactivate values so that they are not available:

Again, this is a SaaS advantage, as we'll be able to go into a country with a list in hand, rather than chasing people to try and get the correct government values.

How does the Workday functionality work?

• Ethnicities can be set up at the country or country region level.
• If you have countries where Ethnicity should not be tracked for employees, e.g. Germany, then you simply keep the setup list empty for Germany.  Then a user cannot choose anything as there is nothing there to choose.

IMPORTANT TO NOTE:  The Ethnicity values are tied to an employee's *work location*.  So if you have a US employee whose work location is in Mexico or Canada, that person will get the ethnicity options for Mexico or Canada.  If you change someone's location to another country, the current values for that person are blanked out.

I'm not sure I 100% agree with that logic, in particular as I think about cross-border workers in Europe.  For example, I think of our head office situation (Country A), where we have workers in a satellite location (Country B).  Reporting would still roll up via the head office, they are paid via the head office so would be reported to the government in Country A.

However, I understand how it is coded that way.

Overall, the functionality looks nice.  Now if we could just get Workday to deliver more of the statutory government reports (such as these involving ethnicity) in countries outside of North America, I'll be very happy.  :-)

How good is Workday HCM?

Someone found this blog through typing 'How good is Workday HCM' into google.  I began to ponder that question, with 10 months of implementation experience behind me...

As a SaaS, it's as good as any other SaaS HRIS.  If you want the pre-built processes, fields etc along with heavy configuration/low customization, it's great.  If you have a highly customized environment or your business cannot fit the pre-defined mold of a delivered system, it's probably not the best option at the end of the day (nor would any other SaaS be a fit for your needs though).

If you're coming from *no system*, it's probably an easy way to jump quickly into an HR system, with little or no fuss.  Everything is pre-built and out there, you only need to start using it..

As far as functionality goes, the system offers the fields and processes one would generally need.  My major area of concern remains the 'global' pieces.  I noticed last week on the Workday community that one of the HR Consulting houses had published a set of reports into the Workday Solution area of the Workday Community.  This is the area where customers can publish their solutions, as a means to help others.  While it's great that this consulting firm created this set of country regulatory reports, I am a little surprised that WD does not pre-deliver this solution as a part of the base product. 

For the end user, the system does have a high degree of usability, and a well-designed user interface.  If you're used to a 'traditional' HRIS, you're used to a set of menus and training manuals that take you to various places.  WD instead drives everything off of the 'search box' functionality.  So if you're looking for an employee or setup data or a process--you simply type the keywork into the search box to be given a set of options that contain the keyword.  From a training perspective, it means that you don't need to focus the user of following a strict set of guidelines to follow a path to get to data.

Also, the interface has a 'webpage' look and feel.  When a manager is looking for data about an employee, or an employee is looking for data about him/herself, it's all available in dashboards and easy to find via following 'about me' links and such.  It's intuitive from that perspective, and much more like a 'web page' than a 'system'.

One topic that I have not yet discussed on this blog is the frequency of updates.  While it's great that WD is constantly evolving, it does equate to updates occurring three times a year.  On one hand it's great to have new functionality, on the other hand it requires you to then have a team that is responsible for testing new functionality, new configurations, testing and communication to the end users.  As well, if a  user is trained in doing things a certain way and they suddenly change, that may be confusing or even annoying at the end of the day.

Other thoughts anyone?

My review of the Workday Report Writer training

I recently attended virtual training on reporting from Workday. While you get a high level overview of reporting in the HCM Fundamentals class and run one report, Report Writer is the first reporting class that you can take to learn how to create your own reports.  It's a virtual class, 10 hours spread over two days. 

At first glance, the WD reporting product is not the easiest to learn on your own with no instruction (believe me, I tried!), especially if you're used to a relational database model.  In WD you can access the reporting tool from within a page, so you can click the 'related actions' from a hyperlinked field and choose to 'create report from here' or to view related reports.  However, if you don't have the report basics, you will soon be lost.

I'm happy to say that the two day WD training cleared that right up for me.  The class starts with some background about the WD database structure and some high level details about how the reporting works.  Then, you start to run delivered reports, then you build basic reports (on one object such as the Worker object), and finally advanced reports where you combine objects and then some simple matrix ones where you run counts, similar to an Excel pivot table.

This class was probably helpful to me at this point, because I now understand the structure of Workday, and how there are various objects such as the Worker, Location, Company, etc. and how the data is clustered around these objects.  There were some people in the class who have never seen WD beyond attending the HCM Fundamentals class (a required pre-requisite for this course) and they were lost before the end of the first day.  If you are at least in the implementation stage and have some idea of how to navigate around the WD system on your own and hire someone, for example, you'll be fine.

WD offers Report Writer as an introduction to reporting, then you can follow it up with Advanced Reporting and Analytics (15 hours over 3 days) and/or Calculated fields (15 hours/3 days).  These are all virtual options, with Report Writer being the pre-req to the other two.  There is also the option to do the reporting suite in a classroom setting by taking Workday Reporting:  Basic to Analytics.

That being said, assuming that you have a test tenant to use and can get a hold of the manual, you could probably walk yourself through the training quite easily. 

Some of the things that confused me at face value, before taking the course:

1. The overwhelming plethoria of fields with the same name.  Every instance of a field is its own reporting field.  This differs greatly from a relational database, where if you have something like 'jobcode description', you'll have one jobcode table with a description and you tie your code on your secondary table back to your foundation table. 

If you type 'Name' into Workday to find the field 'Name', you'll quickly get confused as you'll get all sorts of Names (descriptions) for things.

2. The icons used in the reporting tool.  The icons are meant to give you short-cut details about a field without having to look into the details, but until you know what they mean, it's a bit confusing.  Sure 'T' stands for text and '#' is a number field, but what's the thing that looks like a spoon?  Or the fireworks?  Once you know that the spoon is the base table and the fireworks represents a one-to-many relationship, it becomes a little more clear.

Once you get a handle on those basics, it becomes easier to navigate through the tool.

The one odd thing to me--and granted I come from a mix of HRIS systems from basic homegrown MS access applications to more sophisticated tools like PeopleSoft--is that WD locks down reporting from the join perspective.  So if you're doing a 'basic' report, then you're only working on one object--say 'Worker'.  If you change your mind and need other data that is not on Worker, you need to convert to an advanced report (which is possible).  However, if you start your report on an object and discover that it does not have all of your fields, if a join does not exist, you cannot 'force' a join the way you can in other databases.  You basically have to begin again, this time using the 'right' datasource.  I can imagine that one causing some frustration at the user level.

To view my other posts on training, click here.

Customization in Workday - Custom Objects

As a SaaS solution, customer customization of the Workday application is limited to the delivered customization options that you as a customer can configure, and mainly that involves the use of 'Custom Objects'.

Custom Objects can be considered as 'free fields' which you set up to use however you want.  They are attached to the various WD objects such as the Worker object, Location, Company, etc.

An example:
We have a manufacturing location in Europe that is required by law to issue safety clothing to the employee on a certain schedule, so every 6 months they receive a new set of trousers, every 12 months a new set of safety boots, etc.  This clock starts as of the employee's start date, so every employee would have a different date to get new clothing.  (Workday has some business asset/company property functionality so we might put it there, but we're just using this as an example.)  Our goal is to put all of this data into the system, to avoid the need to have any data in Excel, etc.

So your Custom Objects need to be applied to the Worker Object.  We need 3 fields: 

1. Type of Clothing (boots, shirt, trousers, etc. choosing from a dropdown/validated list)
2. Size of Clothing - needed for HR purposes, so that we know how many size 40 trousers to order for next year
3. Date received - this is important, so that HR can run reports in advance, to see when they need to provide the employee with new items.  In particular, we have a night shift and while HR rotates to try and provide a presence during some of these hours on some days, they need to ensure that the supervisor receives the clothing in advance, to avoid any issues with the union that contractual obligations are not being met.

So in our case, our data entry person would get to any entry screen like this:

Date Received:
Uniform Type:
Date Received:

They're quite easy to set up and configure, once you make the decision of how your fields should be defined.  You only need to define things like:  Field Label, Field Type, Prompts, Validation, Status, etc.

The above example took about 5 minutes to set up.  The key is knowing your business requirements.

So in thinking further about Custom Objects:

Advantages:

• You can set them up to meet your business needs.  For example, if you need to track something which is not typically found in an HR database, this is the place to do so. 
• There is some flexibility in how you set up these custom fields.  For example, you can choose to set them up with some validation values, or you can make them formatted as a date, etc.
• It's 'easy' customization that doesn't involve any development--it's merely 'configuration'.
• You can do EIB loads into these Custom Objects, if you'd like, to be able to load data.

Disadvantages:

• You can only apply custom fields where they are delivered at the object level.  For example, you can apply custom fields to the Worker object, so associate custom fields at the employee level.  Or you can apply custom fields to the Location object, so for any custom fields you may need to associate with a location. 
• However, if you have a custom field that is not associated with Applicant, Company, Customer, Job Profile, Supervisory Organization, or any of the other objects available. but instead a different object that does not have Custom Fields associated with it, you will not be able to use it.
• There is a limit of 20 custom fields per custom object!  This is a big one.  It means that you may only store up to 20 custom fields at the Worker level.  In my above example, this would use up 3 of 20 custom Worker fields, leaving 17.  At a global organization, this is insufficient for our HR needs.
• You can store up to 100 instances of a custom object in each instance.  In my example then, let's say that we are storing 5 types of clothing for a worker, and that each worker gets a new set of 5 rows every 6 months.  At 10 rows per year, we'll be out of space in 10 years.  Of course we can archive the data to Excel after a certain time to make room for more, but it would be nicer if we didn't have this concern.
• The data entry for the user isn't so nice.  The user does data entry on custom objects in a stand-alone area for each object.  The fields are not able to be integrated into the 'core' object in a logical fashion.  In our Uniform example, we need to count on the data entry operator to go to the Custom Object area for the Worker to enter the needed data.  This is a different menu item from Job or Personal Data, so easy for the entry operator to forget.

Final thoughts:

• I like the functionality, and how easy it is to 'customize' the system.  In our old ERP such new fields would involve a customer request, request approval, a functional spec, development effort, testing, test documentation, and a production turnover.  Creating these fields in WD is a much smaller effort. 
• We need the option for a lot more custom fields, or we need WD to better enable the application with more regulatory reporting and global fields.  In our implementation we are not able to use the fields for 'business needs' because we need to utilize them to hold regulatory data which is not addressed by WD.  It would be great if WD would increase the limit to say--40 per object.

Workday's merit process

We were recently reviewing some setup in our test Workday tenant, done by our consultants.  As a large, global company we have everyone on a year end merit process, with increases effective as of January 1st.  In order to accomplish this process, we need to start in Sept/Oct, as there are various approval chains and roll-up reporting.  As well, we then need to deliver files to payroll systems in time for them to process these updates too.

The consultants were suprised that we start this process prior to January 1.  As well, WD appears to want you to only think about merits AFTER the period has closed...so in our case, as of January 1.  When you are running the various processes within WD and automatically selecting your employees, we seem to be running the risk that someone terminating in November will get caught up in the process in WD and we cannot get them out of the pool.  (As opposed to our current process where they will get manually removed when it's still in Excel or excluded via PSoft functionality). 

In WD it's not smart enough to exclude them along the way, but instead the manager will need to allocate a 0% increase to the person.  It's not the end of the world, but the functionality could do with being a little more flexible as to how companies have structured these processes.  My guess is that we are one of WD's largest customers so it's the first time they are seeing such large-scale processes.  Smaller companies surely have a more lean and nimble timescale when having fewer employees to process and maybe do more things closer in to the actual effective date.

Workday's Compensation functionality

While I can see many echoes and/or improvements in the various pages of Workday when compared to PeopleSoft, from a front end functionality perspective, Compensation appears to be an entirely different kettle of fish.  The whole structure and setup of comp plans, bonuses, etc. in WD seems to have been created from scratch, or based on a totally different system or model.

From a user perspective, it looks quite nice, especially when they do the demos showing a manager with international employees, with all the bells and whistles of currency conversions and comparisons enabled.

From a setup/maintenance perspective, I'm not yet sure if it will be a major upkeep effort or an improvement. 

Workday field lengths

One of the most interesting features that I’ve noticed so far in Workday is the fact that fields allow the user to enter unlimited content. There are no ‘field lengths’ like you might see in a traditional database. Name, Position Title, Org Title–doesn’t matter–unlimited text.

Coming from a traditional relational database environment, this is fascinating! However, I am struggling to see the advantages of this feature. In particular, if you are interfacing to any downstream system, most will have field lengths. Then, your interface is either truncating the field and losing data, or it’s blowing up the downstream system by sending data that is too big to insert. Or worse–you’re truncating to downstream systems but having a longer value in WD reporting, so a ‘mismatch’ of data, leading to distrust in HR data. Or you’re stuck with having to run audit reports to find incorrectly entered data after the fact in order to have it shortened…rather than just being able to impose data lengths on the field in the first place.

I am struggling to see the advantage of this feature…