Enterprise Solutions: Where to start

Recently at work we were conceptualizing a large enterprise solution. A debate started on what needed to be done first .... where to focus. Should we start on focusing on the end user screens or should we start with the information flow in the enterprise. I found it difficult to start focusing on the user screens without understanding the key business outcomes and the resulting information flows. Coming from an enterprise solution background, it was important to see the entire information flow and then looking at each individual user's needs for deciding the screens.

Conversely, my colleagues came from a product development background. My colleagues insisted that it was useless to proceed unless we had conceived the exact screens. It was as if my colleagues wanted to build an Adobe photoshop for the user. They wanted to know what menu options will be available, including tools and shortcuts. They were planning to build this software feature by feature. My colleagues felt that what I was proposing lacked sizzle and excitement and that customer would not see the value unless we had really exciting screens.

We were at an impasse for the next few minutes. Finally I started giving an overview of why the customer wanted us to build a solution for them. I talked about the business case that had been sold to the finance department. As my colleagues got more context, they realized that they did not know how to proceed with building the exact screens. We finally agreed that we needed to start with information flows before reaching the screens.

The whole episode was interesting to me. Neither they nor me could agree on each others' perspective.

It got me thinking. Why was it that enterprises were willing to pay huge sums of money for enterprise middle ware and back end technologies such as databases, ERP solutions and Enterprise Service Buses while cringing on paying for desktop applications that would improve productivity.

I realized that enterprise solutions can justify higher sticker price owing to their relevance for multiple groups. The same piece of information was important for financial, operational and executive decisions. Same cannot be said about productivity tools that may enhance the productivity of one user group within an organization. This is because each group of user will have different toolset requirements for improving productivity.

Therefore for most large organizations, it will be easier to fund something that has benefits for multiple user groups instead of only one. In the process I would recommend, one should start with mapping multiple flows to application functionality and user groups and then flip it around to look at each individual user's needs for designing screens.