User Focus in Enterprise Software: Part 2 of 2

Customer Data: It’s not just for designers anymore…

In Part 1 of this article I discussed some of the problems enterprise software vendors create for themselves and their clients when they neglect customer data when designing products. But product design is only part of the story. A lack of focus on the customer also negatively impacts other aspects of an enterprise software vendor’s business. Consider the following examples:

Change management

Whether you are doing a global, multi-module rollout of an enterprise resource planning (ERP) application at a multinational corporation or simply installing a new email system for a line-of-business workgroup, you are introducing significant change into an existing system. Business software vendors — and more commonly, software implementation service consultancies — each have their own “Big M” implementation methodology that invariably contains a change management step as part of the overall process. In many cases, this step pops up towards the end of the methodology’s prescribed process, somewhere in the vicinity of “System Implementation” and “System Maintenance.”

I have found that many people equate change management — consciously or unconsciously — with “End User Training.” Simple training, however, will not adequately prepare users to adapt to a potentially foreign way of working and, potentially, a brand new set of responsibilities. A woman I once did a CI interview with told me that even after her change management-sanctioned training, she was horrified by the prospect of touching the new reporting system — and shortly thereafter got back down to work in Excel.

The results of such a compartmentalized perspective on change management can be disastrous. In one example reported in Supply Chain Technology News, a large consumer durables manufacturer deployed an application to support planners who had been using spreadsheets—along with their historical knowledge, experience, and intuition — to do sales forecasting. The new application employed “advanced algorithms” working behind the scenes to do the forecasting for the planners. Did the users embrace this new, intelligent system? Because they didn’t understand the algorithms and their usage context, they didn’t trust the application’s forecast results. They viewed the application as a mysterious “black box,” working around the application instead of with it. Moreover, to take full advantage of the application’s functionality, users needed to learn an entirely new set of skills. Over time, the company estimated that only 25% of the users made what the business considered to be a successful transition. Another 25% actually left the company because they couldn’t handle the new software.

The lessons to be learned here transcend industry boundaries and are equally applicable for large and small companies alike. Hundreds of millions of dollars of IT spend on software, hardware and services are wasted each year as ambitious, enterprise-wide system rollouts fall to the floor due in large part to failures in preparing for and managing the enterprise-wide changes they imply. In hindsight, the problems in the example above were probably inevitable as neither the business nor the software vendor fully understood the potential impact of the system’s model of work on the existing user work practice.

Action

For software implementations, vendors can mitigate change management risk for customers by gathering field data from prospects and existing customers and incorporating it into designs or customization plans. Vendors, consulting partners and system integrators can also proactively limit their own risk by using techniques like Contextual Inquiry and the resulting affinity and consolidated work models to determine where a specific solution is appropriate and where the customer’s existing work practices might present problems. Customers, pick vendors and consulting partners that don’t oversimplify or understate the importance of user-centered change management during your project. If they aren’t interested in observing the way your users currently work and reconciling that with work as structured in the to-be system, find someone who is.

Knowledge sharing

I have always been impressed by the extent to which business domain knowledge is fragmented in software companies. Designers and product managers often lack a standard language or notation that they can use as a basis for communication. When studying the artifacts that drive vendor designs it is as though one must start over and learn an entirely new set of conventions and semantics. I believe this discourages the wide circulation of such materials and encourages lumpy knowledge distribution.

Modeling languages like the UML (Unified Modeling Language) are a step in the right direction in terms of providing common modeling semantics and notational conventions. Unfortunately, the vast majority of UML literature attacks modeling problems at levels too close to implementation to be useful to work practice modelers. Use cases supplemented by activity diagrams and domain models are a good place to start but it would be nice to see the UML community move more business and work practice modeling constructs into the UML metamodel itself rather than treat business modeling peripherally via the Profiles convention.

The benefits of modeling in persisting knowledge for later use should not be overlooked. I once worked on a solution project that focused on how high tech industry suppliers manage customer accounts for large customers with geographically dispersed manufacturing and distribution operations. After our project started, it occurred to us that there was significant domain overlap with a previous supply chain project that had been mothballed several months before. Since the previous project had been executed using Contextual Design, we had access to all of the user data and consolidated models they had generated. This was enormously helpful in knowledge transfer from two different angles. From the consolidated flow and sequence models, we saw convergence in work practice across domains and identified reusable design patterns to support our own work. As well, the models revealed “meta” information about how the team managed the design process itself; this helped us tailor our own approach and avoid the mistakes and pitfalls that they encountered.

Action

Adopt standard notations and establish common semantics that product managers and designers can use to support more effective communication. Contextual Design practitioners already know the value of knowledge modeling through formalisms like the sequence, flow, and cultural models. They make it easy to see patterns in work, are understandable to anyone familiar with the notation, are reusable across projects, and can communicate information across multiple business domains. Make quality and precision in requirements and design communication a fundamental value in your organization.

Sales practices

Vendors often squander valuable opportunities to leverage customer data during sales cycles. Large business software deals can easily last 6 months or more. During the cycle vendors that make the short list generally have ample customer exposure to pitch solution visions, demoing software and collaborating on as-is and to-be processes. In my experience, vendors rarely go past the conference room to gather data and identify the real “as-is” pain points. The entire sales dynamic is largely characterized by software feature presentation and attempts to relate individual product features to problems the customers have voiced. In some cases, there may be some sort of vendor “strategic process analysis” complete with spreadsheets and dollar ROI value estimates. As a result, valuable development resources are marshaled to deliver functionality that has no grounding in real work practice and thus goes unimplemented or unused.

Action

Vendors should use contact with customers to collect and structure real user data to understand what solutions to propose and to support their business case. Any customer value proposition can be made more compelling via real observations of and direct quotes from end user stakeholders. Above anything else, it allows a vendor to differentiate itself from its competitors by truly listening to potential customers instead of hurling features at them. As one CI interviewee once told me, “I feel like this is the first time anyone has really listened to what I need.”

Conclusion

During the “rush-to-market” 90’s, the belief by business software vendors that real people actually have to use their software was pushed aside by “automate everything” thinking. For some companies, solution design became an exercise in detached hypothesis by designers to whom real user work practice was opaque. Ironically, the current economy is pushing those vendors left standing back towards their end users; some large vendors are actually starting to mobilize product support to customers — a service rarely provided on site. In any event, software that is designed, marketed, and sold with users in the periphery will continue to fail to deliver sustainable value to customers. A new era in business software began with “.dot collapse” and for companies positioned to use customer data effectively, this will prove a tremendous blessing.[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]