Part 1 of this blog series described the genesis and current state of affairs of Workday – a novel company that was founded in March 2005 and launched in November 2006 by two great IT minds and PeopleSoft alumni: Dave Duffield and Aneel Bhusri. Part 2 of this series then got under the hood and analyzed Workday’s secret sauce: its object-oriented and in-memory database (IMDB) and definitional services approach, which involves no coding by developers.
The final part of this series will discuss who should be a good fit for Workday and who might not, and why.
Who Should Give Workday a Go?
Workday’s results and growth in these recent (otherwise tough) years should speak volumes about the company’s attractive value proposition to some organizations. Certainly, as long-tenured ex-PeopleSoft executives employees, Workday’s management and staff must have known about all of the unhappy PeopleSoft customers in the world, and they had a good target audience from the start. The company’s ideal prospective customer is a large multi-national enterprise that needs global human capital management (HCM), a payroll and/or financial management system, and sees the advantages of on-demand software.
In other words, Workday should be a good fit for global companies that are comfortable adopting the newest technologies. These high-growth and dynamic businesses not only tend to lean more toward bleeding-edge technologies, but should also benefit from the tools’ flexibility to reorganize the organization frequently. Ideally, these would be those companies that thought that they were getting Workday when they bought and installed an on-premise administrative enterprise resource planning (ERP) system over a decade ago (e.g., PeopleSoft 7x or SAP R/3 3x or 4x).
The company has an established presence and bandwidth in North America and Europe, the Middle-East, and Africa (EMEA), and only an early presence in the Asia-Pacific region with the recently opened office in Hong Kong. For now, Workday remains focused on providing an administrative ERP system (i.e., HCM, payroll, finance, expense management, and project management) rather than a full-fledged ERP system, and its partner ecosystem is expanding.
Not for the Faint of Heart (and Other Situations)
Workday’s clever architecture has managed to avoid the flaws of a static relational database and could play a major role as a global HCM, payroll, and/or financial management software provider. As described in Part 2, the key Workday concept is that the system only requires several tables to store data (in its object database) and that the behavior of the system is configured by describing objects and the behavior/rules of these objects. But the question is: how much can it be configured by the end-users vs. by developers and power users in the system? In other words: can the end user/customer freely define and change the objects and these “rules”? Or are they depending on some form of system delivery?
Over time and with continually delivered enhancements, all functionality is configurable in Workday by end-users and/or customers nowadays. The only exception at this stage is integration, which still requires IT staff’s involvement. Since Workday’s object model is built in a proprietary architecture, this means that power users have to know this architecture intimately to make any integration changes. Workday’s Enterprise Interface Builder (EIB) allows business users to do simple integrations themselves, without the help of IT. Reportedly, 95 percent of Workday production customers use EIB for simple inbound and outbound integrations.
Too much system flexibility and end-user leverage might not appeal to some conservative and faint-hearted companies. As Jason Busch describes in his Spend Matters blog post, there is a limit to a procurement manager’s ability to tightly control and monitor a closed-loop spending process — one that starts with up-front spend capture, analysis, and negotiation and then progresses to supplier enablement, catalog management, requisitioning, invoicing (and the broader concept of electronic invoice presentment and payment) and finally contract management and contract compliance. In other words, some smaller and conservative companies might prefer the hard-coded and rigid nature (best practices boilerplates) of their enterprise software packages. They do not necessarily want their end-users to get to “creative,” in other words.
Not the Only Malleable System in Town
In addition, Workday is not the only “malleable system” and “post-implementation agility” game in town. For example, Agresso (now part of UNIT4) managed to avoid the flaws of a static relational database a long time ago and in a different way. As described in my 2009 series, Agresso’s VITA architecture, attribute/relations, and the so-called “flexi fields” allow customers and end-users to create their own objects without coding, only via configuration in the graphical user interface (GUI). Furthermore, these objects can be changed at any time as can their behavior and the relationships between them.
Agresso, as an incumbent in the higher education and public sector market, will provide stiff competition to Workday’s intended market entrance (see Part 1). Agresso acknowledges that more processing in memory (on the server side in Workday’s data center) is quite a clever approach, but the big question is how scalable it is. Could Workday, for instance, run payroll (in memory) for the large customers that Agresso has, such as the City of Oslo, Norway? And how are data security and potential rollback scenarios handled in memory?
To this end, Workday cites scalability benchmarks today running payroll for 35,000 employees in a production environment (not a lab) and continues to enhance scalability and performance. One of the nice features of its software-as-a-service (SaaS) model is that the vendor can do that and its customers simply benefit when it’s turned on (i.e., they don’t have to invest in expensive hardware, software, benchmarking efforts and resources, etc.).
What’s in Store for Workday?
In any case, Workday is the real goods and represents a much greater advance over competitive systems than, e.g., the much lauded salesforce.com was at an equivalent time in its history. To be an effective replacement for an existing infrastructure system, the newcomer has to be much better than the old establishment to justify the cost of ripping the old system out. Workday’s architecture could permit its offering to be that much better, which is why I was impressed. The company has yet to fully take advantage of what it has, but there is some chance that it will eventually do so.
So Workday is already several years ahead of the “old school” incumbent vendors with a vastly superior value proposition. The company won’t be able to roll through the market the way SAP and others did in the early 1990s, because the “do nothing” attitude is more competitive today than it was then. But Workday should still be able to do quite well over the next few years.
Essentially, what happens, at least in the realm of human resources (HR) management, is that the demands placed on global HR organizations are simply not met, partly because they spend an enormous amount of money inefficiently on mundane tasks such as just keeping their benefits and payroll going. Eventually, users decide that they need something that’s designed for a modern organization. Given how really bad most ERP systems built in the 90s are, I’m surprised this doesn’t happen more often and in more areas, but there’s plenty of evidence that it is currently happening in HR departments at the largest global companies.
Workday is building a complete administrative ERP suite, which is an immense agenda. Still, the definitional development approach provides a huge lift once you’ve got the tools sorted out. There are many customers for which Workday is not the right answer, at least right now, and some things could always go wrong, but I’ve rarely been so impressed with a vendor’s leadership and bench as well as its products.
Some may wonder how Workday compares with other star vendors in the on-demand HCM space, say, SuccessFactors (see my related series), Taleo, and Saba Software (see the related series). As for the questions of talent management, there are vast differences among these products and in the utilization of these products, since each one reflects its heritage.
Namely, Successfactors is perhaps the best talent performance management and employee development needs product — most complete, best UI, most nuanced, etc. For its part, Saba is similarly qualified for enterprise learning management and social platforms, while Taleo rules the recruitment space. But companies cannot run a payroll from any of these products whereas they can from Workday, nor can they use those systems as a global HR system of record. The recent alliance with salesforce.com to integrate Workday with Salesforce Chatter and Force.com should mitigate Workday’s lack of a native social platform offering.
At the end of the day, I will paraphrase David Dobrin’s statement in one of his past write ups that Workday is a gnat compared to the gorillas and elephants in the market, but the buzz is catching up. I would perhaps add that this software’s metaphoric “insect bite” might even carry some nasty “West Nile viruses” for its “old school” competitors and a cure for their unhappy customers. In fact, given that David’s article is a bit dated, the gnat reference is no longer the case: Workday currently has over 240 customers, two million workers under contract, and over 950 employees. For more information on the company’s recent Workday Rising 2011 conference, see the Enterprise Irregulars blog post by Naomi Bloom.
Dear readers, what are your comments, thoughts, suggestions or individual experiences with global talent management in general, and Workday in particular? How do you view the company’s novel approach to developing and delivering enterprise applications?