Adopting omni-channel communication – part II: complications

No Comments

In the previous post on the topic, the necessity of omni-channel communication for companies in the current competitive market was laid out. As stated, fundamental changes in enterprise architecture with critical and intertwined legacy systems are extremely difficult to carry out successfully.

In this post, we explore common complications when it comes to implementing an omni-channel strategy. The next post will address these challenges with pertinent guidelines and tips.

Scope overflow

Most meaningful changes demand or stem from restructuring existing organizational structures and processes. Making a company omni-channel often requires changes not only to the current tool landscape, but also to organizational structures, roles and accountability.

This means that both technical and business layers of an enterprise architecture need to be adjusted and tweaked respectively. A consistent and homogeneous adjustment of IT landscape and the accompanying processes to enable omni-channel communication is more of an art than a science and requires expertise in technology, business, organization and people (users).

Any system that is related to handling incoming requests, processing them, and sending the corresponding output is inevitably subject to analysis and possibly fundamental changes in the journey towards an omni-channel reality. The affected areas include physical input/output administration (mail, fax, etc.), workflow/task management, appointment planning, customer relationship management (CRM), automatic call distribution (ACD), skill management, resource and capacity management, SLA[1] configuration and monitoring, email gateway, data warehouse(s) and BI systems, knowledge repository and corporate website.

Figure 1 demonstrates the common pertinent systems when it comes to an omni-channel solution.

omni-channel communication

Figure 1 Omni-Channel-relevant systems and modules within an IT landscape

The scope of an omni-channel solution should, therefore, be decided diligently.

Many functionalities may be offered by existing systems in one way or other. These include video chat, appointment management, personnel and capacity planning, skill management, request routing and assignment, reporting, monitoring and pipeline (task) management. Any of these domains can be an out-of-the-box (internal) feature of an omni-channel platform, or they can be handled in a separate system that should be plugged into the existing platform accordingly. For example, an appointment management system used by a sales department may be different than the system agents or 2nd level support are using to manage appointments. These redundancies need to be addressed, which may extend the scope of the omni-channel program.

The decision what channels should be the core functions of an omni-channel solution and which ones may seamlessly be integrated is not quite that easy to make. It simply depends on various interdependent factors including the specific requirements for channels, licensing models, technical restrictions (e.g. network speed) and the overall maturity of the main platform. Lastly, it depends on how much decision makers are willing to let go of a “running” system and how deep of a surgical operation on the enterprise architecture is possible and desired.

One thing is certain, though. In the early stages of an omni-channel adoption program/initiative,  these questions should be answered, so that the scope is relatively clear and the accountability and interdependencies are transparently laid out. Ignoring these – sometimes inconvenient – questions only results in more complications in the future.

Moving targets

In large organizations, there are always a few large and company-wide projects and dozens of smaller projects that are running in parallel to the omni-channel initiative. More than often, some of these projects are relevant to the target architecture that is to be designed to enable an omni-channel communication.

For example, a company might be planning to use Office 365 in two years or to migrate to a new CRM or OCR[2] system, or to change its website to a new platform. All these systems have a direct impact on the desired target architecture and capability matrix, even if they have not yet materialized.

Such moving targets, particularly in large organizations, can make requirement and architecture design even more strenuous. That is why in the early phases these relevant projects and plans should be identified and investigated to avoid any conflicts in the future.

In some cases, it may prove necessary to cancel or radically change the definition of some projects, if they happen to contradict the devised target architecture. For example, if the selected omni-channel solution already has a competent OCR feature, a project to replace the existing OCR with a new system can simply be dissolved or integrated into the omni-channel program.

Too many options

Selecting a solution (a set of systems) to be added to a complex landscape is itself an arduous task. There are quite a lot of technical and legal requirements to pay attention to, not to mention that hundreds of different solutions may exist in a market, each promising some tempting features.

It takes expertise and insight to see beyond the façade of decorated software and see how technologically sound, stable, easy-to-adjust, and user-friendly they are; and how well they fulfill the collected requirements. Mapping omni-channel requirements and use cases to the features and capabilities of a system or platform is not quite trivial.

Moreover, scalability and flexibility are important characteristics of a modern IT landscape. A modern solution for supporting omni-channel communication should provide out-of-the-box services along with connectors and APIs to interact and operate with other systems or modules. For example, it might make sense to outsource operations including OCR[2], request classification, capacity management and routing to an external system that may be on a cloud platform. A modern solution should not only be web-based and cross-browser, but also be based on a plug-and-play architecture with flexible APIs and connectors to facilitate and maximize interoperability with any other system.

Furthermore, the licensing model of a system should be considered and taken into account in the selection process. Flexible licensing is of utmost importance, particularly for an omni-channel solution that often has different types of users with various levels of activities. A rigid licensing model leads to huge costs. These costs can come from unnecessarily high licensing fees, or result from questionable workarounds when not every relevant role can be added to the system as a user. Either way, a flexible licensing model is a vital part of a modern solution.

Figure 2 shows a summary of common expectations from a desired solution.

omni-channel: common expectations

Figure 2 General expectations of an omni-channel solution

It should be noted that modern and future-oriented tools provide additional values including low-code development, real-time reporting, and clean and sophisticated APIs to be well-integrated with other systems. Finding the right set of tools inevitably demands a comprehensive study of process-related requirements, organizational hurdles, enterprise architecture, technology trends and, finally, a methodological approach to market analysis to evaluate identified solutions.

Legacy applications

Selecting a tool might be a major challenge. Still, integrating it effectively and with minimal costs and readjusting the existing capability matrix (shifting functionalities from a system to another) is just as important.

The integrity and scalability of the conceptualized target architecture cannot be overstated. An enterprise architecture should be dynamic, transparent, and expandable when faced with new technologies or business opportunities. Imposing a solution for the sake of omni-channel communication to a complex IT landscape necessitates not only modifications in the existing interfaces and data flow, but also an initial clean up and replacement of old systems and interfaces.

Such outdated and “user-unfriendly” systems have generally evolved in an ad-hoc manner, often without a central vision and roadmap. Many of them are, therefore, not seamlessly integrated with one another. Outdated have-been tools may offer interesting features, but when it comes to easy integration or a simple customization, they fail miserably. Solutions such as Genesys, LotusNotes or SAP tend to show such problems. Having a large market share because something used to be good a decade or two decades ago does not necessary equal to having a modern, scalable and user-friendly technology; sometimes quite the opposite, sadly. That is why certain analysts (e.g. Gartner) may give you some insight into big players of the market, however, they often do not include highly sophisticated solutions that are just gaining ground, nor do they tell you how outdated the underlying technology may happen to be. Big players are not necessarily best players at this very moment.

Here are a few symptoms of an ineffective and outdated system, which may help you identify them easier:

  • a release interval of more than a month for new versions,
  • existence of desktop applications,
  • not being cross-browser[3] in the year 2020, and
  • local administration of users (instead of all users of all systems being synchronized from a central user repository).

As a rule of thumb, if you have an important system in your IT landscape that has one or more of the symptoms mentioned above, you should seriously consider retiring and replacing them. The hidden costs of their development, operation and/or maintenance are simply too high. There are numerous low-code systems for any domain nowadays in the market, which thankfully make desktop applications and silo-oriented IT landscapes a thing of the past. Companies that continue tolerating such systems in the third decade of the 21st century will soon find themselves in a tough situation in today’s competitive and rapidly changing market.

Lobby resistance

In addition to all this, the lobby power of the representatives / sales agents of legacy systems should not be underestimated.

Critical systems in large enterprises bring millions of dollars in revenue in licensing, consulting, and maintenance. Retiring these applications is not only a technical and organizational challenge, but sometimes a political fight with vendors’ representatives. Where there is money involved, eyes should be open against conflict of interest. Even organizations in developed or democratic countries are not immune to financial influence of lobbyists.

If you feel like the existing solution has some level of influence on the decision makers, evaluation criteria and the pertinent suggestions should be impeccable. In the next post, more elaborate guidelines will be provided to help you handle and tackle this problem with minimum friction. Just keep one thing in mind: your organization does not owe anything to outdated existing solutions.

Local mentality

One of the fundamental principles of a grand vision for omni-channel communication is to conceptualize processes with an end-to-end mentality in a unified and holistic way. This “process re-engineering” should be carried out both before and after a solution is selected.

Local mentality means that organizational units (e.g. departments, teams, divisions, etc.) tend to see existing procedures from their own perspective instead of viewing them as part of a bigger picture. This is one of the major problems in steering customer journeys. End-to-end process management means that any process starts with a clear trigger (e.g. a customer sending a request) and ends with a clear closure (e.g. customer receives a required document). Whatever happens in the middle should be considered an incomplete part of the whole journey. This way of comprehensive consideration is necessary for omni-channel communication.

The re-conceptualization often requires that many departments change the way they employ communication channels with customers and the manner they process their requests. Many of them may be merged or assigned new tasks and roles. Many smaller systems may have to be dissolved and new responsibilities and procedures may be deemed necessary.

This is a huge change, especially for large organizations, and needs an insightful and purposeful change management, strongly supported by the leadership.

Rigid organizational structure and local politics

Even when we know, after meticulous analysis and rigorous design, what needs to be changed on the organizational level to enable an end-to-end process management, the game is not over. Planning to change established organizational structures and adapting new roles and accountability and training personnel to acquire new competencies is yet another considerable challenge to prepare for.

Change is often reacted upon with resistance and suspicion, and that is absolutely normal. The arguments for change should be laid out transparently and frequently, so that every stakeholder and user is on board. Remember, nobody likes outdated software that constantly disappoints its users and causes irritations and waste of time and nerves. This means that you have good chances to be welcomed by certain departments such as customer service, marketing or sales. Still, users are not the only stakeholders. Department managers, decision makers and members of the Working Union are as important. Especially Working Union should be handled carefully and wisely, which brings us to the last section.

The mighty Working Union

The concept of working unions is great. In a highly capitalistic market that tends to ignore or underrate workers and focus solely on stock prices, revenue and profit, working unions can provide a resisting body to make decisions that would work for both business and employees (workers). Having said that, there is a risk factor with unions when it comes to innovations and new technologies.

In some countries, including Germany, working unions have gained substantial power in intervening in innovation initiatives and be involved in calling the shots and making decisions. Assuming all these efforts are based on good intentions, there is an inevitable tension. Modern technologies, in some cases, may help an organization automate certain processes or reduce the time and effort needed to do certain procedures. In a perfect world, an organization is responsible for finding new activities for those employees whose daily jobs are affected by a new solution or approach. Since such a plan cannot be guaranteed or its implementation is uncertain due to entrenched mistrust between stakeholders and union members, working unions sometimes tend to shoot down and block an innovation instead of allowing it to happen and helping with mitigating the effects.

That is why an innovation-heavy initiative such as adopting an omni-channel strategy needs to be carefully discussed with the working union. A compromise can always be achieved, as long as both parties agree that employees’ interest shall not be sacrificed for the sake of more profit.

Handling Immense Complexity

Summarizing all the complications listed above, it is now clear that enabling omni-channel communication is a complex program with lots of dependencies and various dimensions of activities (technical, organizational, etc.). Such program requires a suitable knowledge repository to collaboratively collect, formulate and share requirements and design concepts with regard to all relevant users, systems and business segments. Furthermore, there are a lot of activities, milestones and deliverables to carry out. These activities range from defining requirements and selection criteria for a new solution all the way to designing various concepts, implementing change requests in relevant systems, approving outcome, etc. This is not something to be handled by Excel or alike.

Furthermore, identifying the status quo and designing a sound target architecture requires a suitable EAM (Enterprise Architecture Management) tool. An EAM tool helps with efficiently generating and viewing various layers, particularly business and technology layers with regard to the design architecture. All these require modern solutions for PMO and EAM to manage information (knowledge), to document architecture and to steer activities efficiently and transparently.

—————————————

Figure 3 shows an overview of the common technical, organizational and political challenges when it comes to adopting an omni-channel strategy.

challenges of an omni-channel strategy

Figure 3 Common challenges/complications in adopting/implementing an omni-channel strategy

In the following post, applicable guidelines and tips will be provided to address these challenges and, hopefully, reduce the risks and costs of an omni-channel adoption.

——————————————————————————————-

[1] Service Layer Agreement

[2] Optical Character Recognition (OCR) systems convert images of documents (e.g. received fax documents or mails) to text to facilitate readability and automatic classification.

[3] Cross-browser means that the web-application is browser agnostic (can be run on and accessed by all popular browsers).

Avatar

Pujan is a technology, process and knowledge management expert with a focus on Atlassian products, IT strategy and end2end process management.
Upon finishing his PhD degree in Managing Information Systems (MIS) at Technical University of Munich, he has worked at and consulted multiple international companies in Europe, Asia and the US on how to manage their processes, communication channels and knowledge in a holistic and collaborative way. He has also published 10+ papers on various topics including online community design, omni-channel communication, knowledge management and IT benchmarking. His new book (in progress), “Shaping a Digital Beauty with Jira” elaborates on using the potential of Jira and Confluence to go beyond software development and provide a modern solution for managing complex processes and projects.

Comment

Your email address will not be published. Required fields are marked *