Customer channels and user experience

In many of the places I work there is the concept of a customer access channel. That is - an interface by which a customer is able to interact with the business. For example - face to face in store, on the phone to a call centre, online web-page etc.
These have been extended to multi-channel and even omni-channel strategies where customers get similar or complementary experiences through all different mechanisms.
The idea being, of course Customer Focus (with capitals) and all the good things that come with it.

The trouble is that the entire focus is still on a discrete set of closely controlled access points. Most of which are conceived and built around a particular technology. But if we decompose this viewpoint you can see that there are overlaps in the technologies available - and generally they relate to the capabilities that may be offered, whatever the technology.
Hence - assisted channels, that is phone or store-front where you talk to a real person, have an experienced (sort of) user in front of the technology, and this allows for a much more complex (richer) customer experience. At the other end of the scale is voice systems talking to a machine, however well programmed, is restricted to a single set of menus and very simple operations. The overlap comes into things like using cash - which is restricted to store-front or self-serve kiosk (e.g. an ATM). Even through web channels the user experience on a smart-phone is different to a tablet is different to a laptop is different to a desktop - although many web-sites don't make the distinction.
The security profiles for mobile access, using the device id, cannot be used with a standard computer - especially through a corporate firewall.
A better way of thinking about the customer experience is thus by consideration of the set of capabilities that the access path offers - not by the 'channel', a concept which is becoming less and less well defined.

Working with Large Organisations

As an answer to a small business-man asking what it is like to work within a large company:

 

"I have been thinking about the questions you had about working with large organisations. I have not worked with many *small* companies so please take this with a grain of salt but:

One major concern of ANY organisation of any size at all is holding itself together and keeping people working together. With small groups this is done instinctively through shared goals and constant reinforcement. The larger an enterprise gets the more effort must be given to maintaining itself as an organisation. In the largest global companies the vast majority of the effort is involved in management – which is another way of saying getting individuals to work together.

Hence: they tend to be very conservative about change. There will be a (great) number of processes, procedures, governance etc. – basically red-tape – to ensure everyone does things the same way. All of which is designed to make sure that complexity is reduced, higher ups have good visibility of what is going on through the murk, and no-body is going off on their own.

There is, of course, less of this the higher in the organisation you go until the board is generally able to try new things – except that board members tend to have moved up through the chain and well aware of the balancing act and the need to stay close to the centre.

In summary – you will find it harder to ‘get things done’ the larger the organisation you are working with. You may be able to mitigate if your interest is restricted to a sub-set of the company. A division will operate as if it were a smaller group – but always within the context of the larger processes with regards to things like Procurement, Financials, HR etc. [This could be an issue for your product since an ERP is, by the very nature of it, concerned with the entire enterprise].

The same basic circumstance applied in IT. Any new system will almost certainly require integration with a number of incumbents. The larger the company, the more sub-systems (often more than one doing roughly the same thing – decommissioning anything is difficult) and therefore the greater the integration overhead. This manifests in negotiation and tight specifications, combined testing, shared environments etc. – all of which add significantly to delivery timelines. And costs – which is why the figures I quoted are relatively high compared to the smaller companies you are used to.

As above, the overhead can be mitigated by restricting scope to a single function/capability. Staying highly coherent and loosely coupled (of course this is also good architecture). But make sure you are not overlapping functionality with some strategic system which is carrying out the same work for the company as a whole.

Finally, I should call out the problems that all this poses for Agile development. Trying to tweak a web-site which relies on a mainframe that has an annual release cycle is an exercise in frustration. Full end-to-end testing alone can be a major issue in co-ordination. It is better to decouple through an integration layer and let each piece operate at its own natural pace."