Every company claims to be customer centric these days. But, then, if you look back, companies always claimed to be customer centric. “We are focused on what the customer wants, right?” They say. In fact, it was and is the bed rock of American industry, we are told.

All true. In deed, organizations have been focused on the customers always. However, when it comes to IT, the story is not so straight forward. Consider the following evolution of IT.

Let us look into a brief background of this evolution, with some examples.

System Centric IT

As organizations started going beyond payroll systems to using computers in running the business, the primary concern is about the functionality of the applications. To large extend, the PCs of that era also influenced the purchase decisions: We want as many tick marks as possible in features.

Consider the IT manager trying to automate procurement. Any procurement application requires partner qualifications, tender management, contract management, PO generation, quote generation, etc. (I am not an expert in this area, but you get the gist). The IT manager looks at various products and makes a judgment based on several factors, including functional fitment. That is the how IT is built of several systems, selected for different functional capabilities.

What is the flipside of this kind of selection? Let us look at the problems and the ad-hoc solutions that IT had to deal with because of the fragmented systems in IT.

Overlapping functionality

The overlapping functionality of the systems in the enterprise leads to lot silly problems that IT vendors have been making money off for several years:

Of course, there is a simple solution: Buy one system that solves every problem of running a company. The big ERP systems (an excellent example would be SAP) promises exactly that. You get a unified view of the world, with one application (even if it is broken as modules) dealing with standardized data, clear delineation of responsibilities, and best practices about what functionality is to be implemented in what module.

Despite all these promises, enterprises still will have to build applications, buy different applications for different functionalities, and live with the consequences.

Process Centric IT

System perspective of IT enables an IT to automate all the core functions. Yet, when we look at an enterprise, more and more, the business sees itself as carrying out some processes. For example, procurement is a process, managed by a business unit.

This process view in a company has several benefits: firstly, companies can measure themselves by process. For instance, how long does it take to procure a new computer for a company? If that is the metric that needs to be lowered, then, people can modify the process, optimize the process, or simply train the people to process requests faster. Secondly, process is natural to companies, as they are optimizing for operations. Since operational responsibilities fall along the lines of process, it is convenient to create KPI’s based on the process.

In the world of IT that is built on systems, this process centricity poses a problem. Let us look at the ways:

1. If a process is entirely contained in a single application, it looks almost like a functionality, right? Then, what is the problem? The problem is process view demands certain uniform approach to process management. For example:
   1. Process visibility: Where exactly is that request for new onboarding of a supplier stuck?
   2. Process metrics: How long does it take to process this new supplier on-boarding?
   3. Process delegation: Jane went on vacation. Can John who reports to her approve the request?
   4. Process allocation: We have three people verifying the supplier bank information. That is the where the lag is. Can we increase the number of people handling that task?
   5. Exceptional processing: We have an important project for which we need this new supplier. Can we hand-hold the process to move it past the gate?
2. If a process spans multiple applications, that creates additional problems. For example:
   1. All the process management requirements become that much harder to implement. For example, consider delegation: You may have to repeat the same delegation in two different systems.
   2. Integrating the processes is complex. We need to bring the data in sync between different applications.
   3. Process optimization is complex. It is difficult to change two systems and keep them in-sync when the overall process is changing.
3. If a process is not fully automated, it creates even more problems:
   1. Process management may be impossible, with manual steps. In particular, visibility, metrics, and allocation – all have to be done manually, leading to inconsistent results.
   2. Process operations may be costly, because of the manual steps. In addition, it may be error prone and inconsistent.

With all these problems with systems view of IT in a process world, what is the solution?

BPM for process management in a company

BPM as a emerged as a general mechanism for business process management in an enterprise.

Consider the implications of the picture presented:

1. It is preferable to implement a process outside of the systems, in the BPM, if we are looking to manage effectively.
2. Even if the process is contained one application, it still may be preferable to implement in BPM.
3. BPM can provide additional benefits, in addition to process management: 1. customization of process, which may be simpler do in BPM than the application 2. Reconciling different data models – customers, partners, orders etc. 3. Automating simple tasks, without being custom systems – to full automation of the process.

The enabling technology is SOA, which lets applications work with a BPM system.

People Centric IT

Process centric view is fine for lot of purposes. It lets IT support efficiency drive in enterprises. It lets the companies focus on the processes that matter most. In fact, it gives the organizations a blue print on understanding which processes to customize and which processes to leave alone.

But, one important aspect that gets hidden is this: How do people use the systems? Are they happy to use the systems? Do these systems work in the context of the usage (like, say on the go, or in the office)?

As an analogy, consider a government office, say DMV. If you are there for license renewals, you stand in one line. If you are there for registrations, another one. Auto titles, yet another one. That is, users are tasked with figuring out where they should stand.

Much like that, most of processes typically have their own way of serving users. Even if we were to integrate them in one portal, the experience is different. In fact, users may be forced to learn lot of different interfaces depending on the context.

Or, consider a corporate website. Typically they are designed describing the way the company is organized. But, a visitor does not care about how the company is organized – they only care about how their interactions are organized.

When we start taking a user centric approach to IT, we should not expose the systems or processes to users. After all, systems are the way vendors developed the applications, and processes are the way organizations carry out their work. We should design the interactions of users with the internal systems and processes and focus on providing the user interface supporting the context of the usage.

What customer centricity means to IT

If a company decides to reshape their IT to incorporate customer centricity, what should it do?

First and foremost, it should realize that the most of the systems that it can acquire still will be operating in the old-fashioned mode. And, internal processes will remain the same. Until products and internal applications are retooled to customer centricity, we will have to implement customer centricity differently.

Designing for one

Ideally speaking, we should design an application for every user. After all, every user is different in the way they want to use the systems. But then, it is too costly for that level of customization even with personalized applications.

The right approach to that is through Extreme Segmentation. That is, we do not divide people into segments based on static attributes. Gone are the days when people are classified into established buckets such as “college educated over 50’s white male”. Instead, we provide several attributes of users that lets us group users into very many overlapping sets.

To support that many segments, we may want to retool the IT in the following way:

1. Self-provisioning, community-supported, discoverable applications
2. Easy to develop, deploy, and operate applications
3. Standardized applications catering to segment specific interactions.

I will be writing more about extreme segmentation in digital marketing soon.

Three main groups of users

While it is nice to talk about extreme segmentation, I find the following three groups of the users very important:

Each group of users use the IT systems differently. And, as such customer centricity would mean different for each group. We can consider other groups such as partners, operations people etc – their needs tend to be a combination of these three groups.

Standard approach to customer centric applications

Finally, let me summarize by describing a standard reference architecture that can be used for developing customer centric applications.

This is somewhat simplistic, but the essential principles are going to be same even in a full blown picture. In summary, the architecture uses:

1. API’s to build the experience on top of existing applications
2. Use modern UI technologies to design applications
3. Applications can replicate functionality, in catering to different sets of users.

Concluding remarks

In this note, we discussed the emergence of customer centricity in IT. We described what it means to IT and architecture. In subsequent notes, I will describe the following:

1. What extreme segmentation means and how it works in digital marketing
2. A prescriptive approach to creating a customer centric IT – an enterprise architecture approach
3. An in-depth look at architecting a customer centric application: concept, design, and implementation

Till then, happy reading!