FDM Design Tips Series – Part 1
The Foundation Data Model (FDM) is critical to a successful Workday® implementation. It has touchpoints with every other Workday module and is the backbone for all financial reporting within the system. As such, each tenant’s FDM must be built with downstream reporting as a central focus, aided by a tried-and-true set of best practices. In this series, we will walk through the most important of these, and guide you towards successfully designing and maintaining your FDM.
Maintain One, and only One Dimension per FDM Component
The FDM is comprised of several components, or worktag types, each of which have values that can be tagged on transactions or transaction lines in Workday. The delivered worktag types include Company, Cost Center, Location, Spend Category, Revenue Category, etc., and you can create custom types as well. These are used together to drive downstream reporting, but in order to do this effectively, it’s important that each worktag type is clearly defined and only represents one reporting dimension.
This concept is often explained using a slot machine analogy, with each worktag type represented as a single reel. A pull of a slot machine handle can result in ANY combination of resulting symbols across the reels. Workday features a similar flexibility when tagging worktags to a journal line – one value from each worktag type enabled for a given transaction can be combined to form a journal string, and the combinations do not have to be formed into a rigid COA in advance. Gone are the days of establishing thousands of account-sub account groupings – Workday is built to be dynamic!
Companies new to Workday can sometimes find themselves in trouble when they attempt to do one of two things:
Comingle more than one dimension using a single worktag, or
Represent one dimension across multiple worktags
These issues tend to go hand-in-hand, so let’s explore a common scenario where both are at play.
Workday Customer, Inc. (WCI) is a manufacturing company that is implementing Workday Financials. WCI has three different products and also offers a repairs and maintenance service. It needs to track Revenues and Expenses related to each product in order to evaluate its profitability. WCI’s FDM included the following values for Revenue and Spend Categories:
The first issue with this approach is that more than one dimension is represented by each of these worktags: product and revenue type, and product and expense type. Moving forward with this design would not allow WCI to track both type of revenue (e.g., Service Contract Revenue) and product sold (e.g., Product A) on a customer invoice line, since Workday will only allow you to tag one Revenue Category value to a given journal line. The same is true for Spend Categories; this approach limits WCI in its ability to track both type of spend (e.g., Commissions) and the related product (e.g., Product B) to a supplier invoice line.
It can be tempting to want to update the FDM as follows to solve this first issue:
While the consequence of the first issue may be avoided, a second issue still runs rampant: the product dimension is still represented across multiple worktags. This structure is reminiscent of typical COA architecture in many legacy systems, but Workday is built to operate differently. An approach like in the table above will quickly lead the Revenue and Spend Category worktag value lists to grow exponentially, increasing both the maintenance required and the risk of choosing incorrect values during data entry. This will also inevitably lead to inefficient and convoluted downstream reporting, and effective profitability reporting will be all but impossible.
The best course of action here, which will solve both issues at once, is to split out the product dimension as its own custom worktag type:
WCI now has the flexibility to tag any product to any corresponding revenue type or expense type. The Product worktag type now also becomes the lever by which WCI can run profitability reporting. Custom validations and worktag relationships can be configured to add layers of control around which worktag types (or which values from each worktag type) can be used in on a given transaction or journal line -- more on that in a future installment of this series.
It can feel daunting to tear down your legacy chart of accounts as you work to architect a more efficient and flexible structure. The easiest way to avoid headaches in the process is to start with a solid FDM built on Workday best practices and time-tested guidance.
We hope you found this helpful, this is part 1 of a 5 part series on FDM Design Tips. Come back next month for part 2. And, as always, please contact us if you want to discuss anything in greater detail.
