This is the final post in a three-part series on Workday. In this installment, I'll talk about some of the differences in design and philosophy that Workday is hoping to bring to the ERP world.
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