If you've got a thousand people using your key business applications and you make those people 1% more productive through an IT architecture change, what have you achieved?
The actual number will, of course, vary with respect to what those people do and what margins you make, but we can adopt a handy convention from the way the national accounts people handle government, and guestimate output value as input cost - meaning that if the average all-in cost per FTE is $60,000, your 1% change for a thousand people will be worth $600,000 a year or six million bucks in present value terms at 10%.
Look at the factors that inhibit productivity for effective, fully implemented, business applications across numerous organizations and you'll discover that the number one productivity killer is a degenerative disease I call "usage habituation" - and anything you can do to reverse it, will improve productivity across the enterprise.
Usage habituation is a phenomenon that sets in after the initial training and adaptation stage in business application deployment. What seems to happen is simply that people choose to use what works - for them - and, in that process, are implicitly choosing not to use both what they genuinely don't know and what didn't seem to work according to their, or a co-worker's, expectations the one time they tried it.
In other words the system users actually use starts out a bit after the initial post deployment experimentation phase as some subset of the actual system - and then that subset shrinks as as early users habituate to the processes they're most comfortable with and new users reduce that subset further with every generation.
Upgrades suffer the same fate: new ways of doing things get modified by reference to the known, business change erodes, and new staff get further and further from the knowledge base theoretically transferred during pre-deployment training.
So what can you do? Annual refreshers help, so does sending people to user conferences for your application - but what you really need to do: getting people to experiment with using the system on their own, is hugely inhibited by the typical PC based approach to desktop access.
You'd think it wouldn't matter - but it does. In fact the one thing that drives the downward spiral characterizing user habituation faster than all others combined is the PC -because users don't naturally trust it and develop, instead, group responses to inconsistent problems that transcend, both in severity and duration, the problems themselves. Thus you can usually track down and fix specific problems causing client crashes, but if that takes a few days the work-around is apt to become user folk wisdom - perpetuated through every subsequent generation of the software.
Track the roots of that phenomenon down and what I think you'll see in the general case is that the thing that both kills user driven innovation and pushes the downward spiral along fastest isn't really the PC, but the typical organizational approach to the help desk.
That approach evolved, of course, in response to the PC and the drive to control centralization needed to contain its costs - you need a central help desk to deal with simple user queries and the entire reboot, reload, or replace cycle and, once you've got that, having help desk staff field the initial user help requests with respect to key applications is almost unavoidable.
Unfortunately a help desk staffer on the phone with a user claiming to see a flashing red "82IS01 No Key" error message is going to tell that user to reboot before considering what the user might actually have wanted to do before triggering the crash.
Since users don't like calling the help desk - in part because the helpers have to focus on the PC rather than the application - the result is that users learn not to experiment with the system. They learn, in other words to stick to a diminishing set of what they know works -and to erase error tracks by rebooting before facing up to the need to call the help desk.
Now imagine, however, that you replace those PCs with Sun Rays - realizing that no PCs means no PC help desk, get rid it too. How does this change the picture?
Well, the users still need usage help - but with the PC out of the way it's obvious that user problems can only be either usage problems or application problems. To deal with those you assign key users as lead users and they take over application help within their own groups. They know the people, they know the job, they know the application: they're naturals in the role and have no problem either in infecting new users with their own enthusiasm for the application or calling an application error an application error when they see one - something they could not do with PC clients where even IT experts often can't tell server, network, or client failures from application failures without considerable effort.
With Sun Rays users experience no cost to failure, so they can act on their motivation to learn - to be the best: meaning that freeing them to learn by experimentation creates exactly the class of super-users the organization needs to succeed with the software.
And that's the bottom line, because getting rid of the PC reduces ambiguity in the system, thereby letting you eliminate the help desk and thus lowers your IT costs while getting rid of the biggest impediments to getting productivity gains from the money your organization implementing the application.