Workday Rising -- Free Your Mind
Quick, name the movie with this line: "I'm trying to free your mind, Neo. But I can only show you the door. You're the one that has to walk through it." If you guessed the Matrix (the original) as your answer, you would be right. But this line is not just applicable to science fiction thrillers -- it's also applicable to thinking about core applications system design. In this regard, Workday really is trying to get people to free their mind from the old ERP paradigm (which ironically, SAP is also attempting to do with NetWeaver and Oracle with Fusion).
Workday's application design approach is fundamentally different than systems of old. Phil Wainewright does a good job explaining the limitations of legacy ERP system designs. He notes that in ERP environments, "there are certain super-entities, such as 'account', 'department', (and) 'region' that are the master-definitions that every other entity has to be defined in relation to. Those choices, once made, cannot be undone; they can only be worked around. While it's true that there are some highly sophisticated workarounds available these days, each one that's added brings further complexity to the system." In contrast, Workday "moves away from a fixed database structure ... Workday's database tables reflect the needs of the object-oriented application architecture -- there are just three tables, for 'instances', 'attributes' and 'references' -- and the data and definitions stored in the table are instantiated only when the application runs. The definitions are therefore as easy to change as the data."
Over on Rough Type, Nicholas Carr notes: "It's an alternative to ERP, rather than a Web-delivered version of ERP [argues Workday] because the system's software guts are entirely different. Rather than being tightly tied to a complex relational database, with thousands of different data tables, running on a separate disk, the Workday system uses a much simpler in-memory database, running in RAM, and relies on metadata, or tags, to organize and integrate the data. Having an in-memory database means that the system can run much faster (crucial for Web-delivered software), and using metadata rather than static tables ... gives users greater flexibility in tailoring the system to their particular needs. It solves ERP's complexity problem -- or at least it promises to."
What does this all mean for procurement practitioners? In theory, it means that configuring new types of business processes is as simple as writing and dropping in a business rule (provided the application supports the functionality required). Let's take a scenario -- albeit one that Workday cannot address yet, but I suspect they'll be able to in soon-to-emerge releases. Let's say that in the past, whenever an employee created a shopping cart and added items to a requisition, that there was no type of check to see how a supplier had performed recently to help the user (or the procurement department) decide how best to act on a particular item. With Workday, one could, in theory -- once an integrated scorecarding, compliance and overall performance monitoring system is included in the package -- alert users to the fact that the item they have requisitioned from a supplier comes with potential baggage. Perhaps it might alert the user or procurement to the fact that based on recent invoicing mistakes, that the vendor is likely to overcharge for the item (or provide a similar but not identical one to the SKU specified). Or perhaps this supplier has a history of late shipments. The system might then suggest alternative items or suppliers based on this analysis and rule look-up.
With Workday, creating this type of analysis and alert should, in theory, just require the addition of a business rule set that business users could author -- rather than requiring an army of IT consultants to remix and pour ERP concrete to make it a reality. Of course, it would be possible to create this sort of workflow approach with any type of system -- the key becomes the ease with which you can create it. And that's the genius of the Workday. One could imagine dozens or hundreds of these types of scenarios that procurement organizations could create material benefits and returns from, yet the ease with which current software allows it makes deviating from embedded business processes and workflows no longer worthwhile. Still, it will take more than just a better architecture to drive Workday's success in procurement. After all, no one said that freeing your mind -- or your IT organization's mind -- was easy.
- Jason Busch
Ok I have an idea that it's a bunch of hype marketing spin, but I'm hoping that's not what is actually going on. Thanks for any enlightenment.
A major challenge for ERP solutions lies in what is called the code block: the set of account, department, etc. super-entity codes hard-programmed into the system at implementation. Defining the code block is typically done based on accounting requirements for the business at the time of implementation, with as much forward visibility as possible because once they are defined in the system the effort to change them is almost always economically impractical.
But as much foresight as you have, the reality is that business changes in ways that aren’t imagined during system design and deployment. For this reason, many ERP deployments have code blocks that no longer reflect the current business. The associated problems are many, but simply put the very system deployed to accelerate business processes instead creates drag on the organization.
A second significant problem with this approach is that it is accounting-centric as opposed to business-centric. When other organizations (beyond finance) in the enterprise want to get information from the ERP system to support business decisions, they have to reconstruct that data. This has led to whole industries being born – think business intelligence – just to reconstitute information because it isn’t captured, managed or available in ways that support the business user.
A simple example is to think about a marketing campaigns manager. This individual may want to track the fully loaded cost of a specific campaign across regions. In ERP, there is simply no practical way to have that level of granularity in the code block.
Workday replaces the notion of a code block with tags. To answer your comment directly, we do have super-entity tags for account, region, department and so-on. Those tags can be defined (or redefined later) by the organization to support accounting/back-office requirements. AND we also allow department-level tags so that managers and department leads can track things that are important to their business performance. We also make it possible for organizations to change tags over time, because companies and markets change unpredictably. Using tags means our customers aren’t locked into a one-time definition of their data structure.
Fundamentally, the system should adapt to the business, not the other way around.
Let us know if you have more questions, we’re more than happy to provide further examples and clarification.
"To answer your comment directly, we do have super-entity tags for account, region, department and so-on. " As I thought, cause it would be really pretty freaking hard to actually produce the monthly financial statements without them.
So since I like to cut to the chase, I'm putting you down as....can easily reconfigure metadata and we allow the users to tag the data with a lot of extra stuff that most people will never need or look at, and will be impossible to report against. Believe it or not, I'm rooting for you. I just don't fall for marketing hype too much.