Monday, January 6, 2014

Customer focused Information Architecture/Enterprise Architecture - A Commonsense Approach

I was in a conversation recently with a Fortune 500 manager handling Voice of the Customer (VOC) initiatives. I think she just needed  to vent steam. 

The gist of her story was that she felt her company was not treating customers right, making them run through hoops to get even basic information to help them understand their invoices and on and on. 

The processes and systems were not structured to deal effectively and efficiently with customer requests for information. 

“I would not want to be my own customer” is what she said as she described how on the personal front she had switched a vendor for providing the type of service her company was providing its customers.  

My question to her was how does the company treat its own employees? Do they have to run through hoops to get information, get claims reimbursed etc.? The answer was a resounding “Yes”.  I was not surprised. 

My premise is that customer service like charity “begins at home”. The reason is not just semantics or platitudes but more nuts and bolts. Organizational DNA has an information architecture strand. It remains same whether it is dealing with external customers or with internal employees. 

It is very unlikely that a company with excellent  internal processes would have lousy customer facing ones and vice-versa.

How can organizations get their Information Architecture right? My answer is “with some COMMONSENSE”, by building an architecture, systems and processes which focus on :

·                     Collaboration – “Can we all work together ?”
Are people, systems, processes, technologies working in a collaborative way? Does the architecture support that? Has it emerged from that?
Ownership and Oversight - “Who is minding the candy store? ”
Governance, Stewards
Mediation – “ Can we get a referee ? ”
Who breaks the tie of conflicting information needs? How?
Maintain  - “Houston! We’ve got a problem”
Does the architecture facilitate trouble shooting, problem solving?
Open- “Help yourself”
Does the architecture facilitate users/customers helping themselves? Does it help in monetizing new value streams?
New – “ What have you done for me lately”
Does the architecture showcase new and emerging trends? Does it have the flexibility to leverage them?
Strategic – “ Boldly go where no man has gone before”
How effective is the architecture in enabling the future state vision for the organization
Enterprise wide- “ whole kit and caboodle”
Can the architecture be scaled for the entire organization?
Necessary – “Keep the lights on”
Does it ensure that  legacy systems stay operational and can be leveraged to the extent possible
Scout, Speed, Scalable, Selective - “We are the Special Forces”
Does it allow innovation : a small "Special Forces" contingent which can quickly scout new options , build prototypes, execute limited precision deployments for a selected target audience. Focus is on 4 S's : Scout, Speed, Scaleable and Selective.
Evolutionary: Parameters, Process, Performance – “Go with the flow”
Plan, Build, Run: The larger "Infantry" component focuses on scaling up some of the early wins of the Special Forces component , establishes a process framework around it and launches them for mass deployment. Focus is on 3 P's: Parameters, Process, Performance.

And if organizations do not get these right, they end up with:

Conflicting priorities and resource allocations
Rapid growth of unorganized data and inability to deal with emergence of newer technologies
Arbitrary decision making focused on the short-term/tactical rather than the strategic
Political jockeying amongst departmental heads in the organization and within IT departments resulting in sub-optimal decision making.

Needless to add, this results in crappy service for both external customers and internal employees.

But as they say “Commonsense is very uncommon”

No comments:

Search Google

Google

Site Meter