This isn't true for enterprise applications at all.
For consumer applications, the end user and the buyer (if they pay to use) are the same. e.g. Amazon, eBay, Google, Facebook, LinkedIn etc. For enterprise applications, the end user is not the buyer. The buyers of enterprise applications write a check but don't use the applications, and even worse, the end users have a little or no influence on what gets bought. The on-premise ISVs don't directly benefit from user adoption, once the software is sold. This is also true for cloud or SaaS solutions except that there is no shelfware in SaaS. I would argue that the enterprise ISVs, on-premise as well as SaaS, would in fact benefit, in short term, from reduced user adoption since they would save money by supporting fewer users and reduced activity. Obviously, this is a very short-sighted and myopic view. I hope that the enterprise ISVs don't actually think that way since broader user adoption and deeper engagement are certainly important for longer term growth that allows the ISVs to build brand loyalty, develop stronger customer base, and gain an opportunity to up-sell and cross-sell.
The fundamental reason behind poor adoption of the enterprise applications is that they are simply not easy-to-use and they almost always come in the way to get the actual work done. In many cases, they are designed to be orthogonal to the actual business process that it is supposed to help an end user with. Also, in most cases, these applications are designed top-down to serve the needs of senior management and not the real needs of end users e.g. a CRM system that helps management to run pipeline reports but doesn't help a rep to be more efficient and agile. In cases where broader adoption for enterprise applications is required, it is typically achieved via a top-down mandate e.g. annoying reminder emails to fill out time sheets. The end users don't see themselves as a clear beneficiary of these applications.
Simply put, the approach to gain user adoption for consumer applications is a "carrot" and for the enterprise applications it is a "stick". But, it doesn't have to be that way. There's a significant potential to apply gamification elements to increase the end user engagement for the enterprise applications, make them sticky and fun to use, and make it a win-win situation for the buyers as well as the end users.
Cater to perpetual intermediaries:
Have you ever played Angry Birds? If not, I would highly encourage you to do so. It serves the category of people known as "casual gamers". These games have pretty much zero adoption barrier for a novice, but when you get serious, there are enough challenges in the game as you progress to keep you entertained and bring you back. The equivalent of casual gamers in the enterprise applications are known as "perpetual intermediaries". They don't want to become power users, but they don't want to stay beginners as well. The tool should have zero barrier for a first time user and should have affordances that encourages users to explore and learn more. Microsoft has done a pheneomenal job with Word and Excel. They are extremely easy to use for a person who has never used these tools before and they provide further discovery via contextual menus and reassurance via drop-down menus (and ribbon in later versions) in the journey of becoming a perpetual intermediary. That's exactly how I expect all the enterprise applications should behave.
Let users leverage serendipity:
One of the early features of Google Apps that I really liked: when user logs into Google Apps for a specific domain, she can see other people in the same domain (same company) who are also using Google Apps. This was not a task that someone explicitly wanted to accomplish, but sheer serendipity allowed them to discover other people and eventually helped collaborate with them. If there's an element of surprise in any app, that experience typically leaves positive impact on a user. How many times did you run into someone at a cafetaria or in a hallway and found that short and tacit conversation extremely valuable? The ISVs should thrive to create this experience in their applications. Foursquare's feature to let users know who else is at a venue, Facebook Places' push notification to notify when friends check-in at a place close by, and certain activity feeds that passively push information to users are all examples that leverages serendipity.
Design for teams over individuals:
The gamification elements for consumer applications target individuals, but that's not how corporations are run. In these corporations, the work gets done by a team and not by individuals — it's a team sport. It's the team and not the individuals that wins and loses. Also, for the most consumer applications, the individuals don't compete with other individuals on aspects beyond the application. The employees in a corporation aren't necessarily known for healthy competition and the gamification rewards might aggravate the existing rivalry. The badges are a digital reward, an accomplishment of some kind. Consumer companies are still struggling to take the badges beyond the reputation. I clearly see an opportunity to link the reputation, gained through some kind of contribution, to an economic reward. I know of a case where a manager had set aside 20% team bonus based on contribution to a group WIki as means to open up information and help others. It did work. However, I would be careful in setting up these kind of systems. The reward model, if not applied correctly, could backfire. But, on the other hand, it's a gamification element that holds significant potential. It'a dagger, use it carefully.
Balance simplicity and productivity:
Simplicity is one of the simplest (no pun intended) yet the most ignored and least understood gamification element. As I mentioned above, the systems that are designed for the perpetual intermediaries should be simple to get started. These systems could potentially get far more complex as you explore more and more features. But, there's another class of systems that people only occasionally use e.g. leave request, annual goal setting etc. It's far more important to keep these systems simple at all levels. Imagine the experience of going from one carnival stall to another and play all the games. You need very little or no instructions. These games at carnival are derived from a few basic games with a few twists, but these twists do not require people to go through a steep learning curve. That's how the applications that people rarely use should be designed; it should use the affordances and principles that the users have witnessed and experienced some place else and it should be broken down like carnival stalls to make the journey easy and fun.
The serious gamers prefer power over simplicity. They like to use shortcuts and a zillion combinations of all the keys on their consoles to get moving quickly inside the game. This is exactly the behavior of the power users of enterprise applications. An Accounts Receivables (AR) interface should not force an AR clerk to learn how to create an invoice every time she opens the application. She has learned the ropes and she expects to be productive and she wants to be faster and better than others. The tools should provide enough "power" features to such users to make them successful.
Photo credit: ccarlstead