In the previous posts on omni-channel necessity and complications of adopting an omni-channel strategy, we explored the new world of omni-channel and most common challenges when it comes to its adoption. In this final post of the series, a few general guidelines are laid down to increase your company’s chances of a successful transition.
The following table provides an overview of common challenges (from the previous posts) and a few suggested measures to help mitigate their possible problematic effects. Most important and relevant measures will be formulated as guidelines to provide a frame of action and mindset when pursuing omni-channel adoption (OCA for short).
- Intensive communications, especially in early phases
- Having decision makers sign off the agreed scope
- Making the agreed scope of program transparent to all stakeholders
- Comprehensive analysis of status quo to identify running projects and possible interdependencies/impacts
- Leadership support to redefine relevant projects, if necessary
|Too many options|
- Comprehensive requirement analysis
- Devising a rough target architecture before market analysis
- Methodological market analysis and transparent selection criteria
- Avoiding over-quantification of criteria
- Desisting licensing traps (cheap is the new expensive)
- Leadership support to retire relevant outdated applications
- Transparent capability map based on target architecture
- Transparent selection criteria with the corresponding weight (importance)
- Leadership support to neutralize nonconstructive meddling of representatives
- Workshops and other forms of training to raise awareness
|Rigid organizational structures|
- Leadership support to restructure processes and roles, if necessary
- Intensive communications to make the benefits of new structures and roles clear
- Intensive communication with Union members to make the impacts of the new solution on employees and organizational structure clear
- Intensive communication with employees
- Using a proper EAM tool and project management infrastructure
- Planning big and starting small
- Sticking to the defined scope
We can consolidate most important and repeating measures into a handful of actionable guidelines, as depicted in the following picture.
Securing leadership support
Leadership support is one of the primary and necessary factors for any company-wide program to succeed. If an OCA (Omni-Channel Adoption) program lacks unequivocal support of the leadership to achieve its goals and enforce necessary actions and compliance, it might be wiser not to start such a program in the first place.
OCA requires a significant investment and a clear willingness to rethink business and customer segments, re-engineer existing IT landscape, acquire and align new technologies with the business, change the established culture and inevitably restructure organizational structures and roles. Leadership support is necessary for demanding actions from pertinent projects when we are dealing with moving targets, fending off lobbyists of outdated but established technologies, retiring legacy applications and adjusting organizational structures.
If highest authorities of a corporation are not convinced about the significance and importance of this program, or there are non-resolved political disputes over accountability and scope, it is often advised to postpone such an ambitious program rather than pushing it prematurely without proper support.
Maintaining a clear scope
It is crucial to have a clear scope for an OCA program in the early stages (after initial requirement analysis). As mentioned in earlier posts, OCA can touch on a lot of fronts and a documented and agreed-upon frame of activities and responsibilities (usually as part of the project mandate) can prevent undesired conflicts and unsystematic and counter-productive growth. Scope Creep is a common problem in large software development and IT transformation projects. In How to Manage Scope Creep, you may check out some advice on how to deal with problem.
Similar to other company-wide transformation initiatives, documenting objectives, roles and accountability areas within the project descriptions often helps with keeping activities and program scope under control.
Of course, the scope of an OCA program can be extended if deemed necessary during the project. This redefinition should have clear mechanisms regarding an increase in budget, resources and accountability.
Formulating SMART expectations
Not every relevant activity that is required for the success of OCA is carried out within its determined scope. What is important is that these prerequisites and requirements are articulated and documented as expectations from other relevant projects.
For example, if migrating to Office 365 or upgrading the current website platform are deemed necessary for achieving OCA goals due to identified inter-dependencies (in the initial analysis), these assignments (projects) should be defined in a SMART way and monitored closely with regard to the master time plan (often depicted in Gantt chart form to demonstrate inter-dependencies).
SMART stands for Specific (descriptive verb & specific result), Measurable (quantity and/or quality), Actionable, Realistic and Time-Bound (deadline, milestones or frequency).These dependencies, their corresponding risk factors and reporting structures should be clearly defined in the governance-related documents in the early stages of the project. Coordinating such parallel and interdependent projects requires a competent and authorized program manager.
There are a few important expectations that need to be fulfilled in order for any OCA program to succeed regardless of industry and context. These include:
- ensuring 360 customer overview (and respectively: unique identifiers for customers),
- availability of a central user repository (so that users of different systems are synchronized from a central source), and
- Zero tolerance on relevant desktop applications (they need to be replaced with web-based and API-friendly applications).
Otherwise the implicit costs of workarounds and impossibility of certain necessary automations may cripple the whole program.
Modern and collaborative PMO infrastructure
Project Management Infrastructure
The OCA program is complex. Keeping track of tasks, risks, deliverables, etc. and ensuring that all sub-projects and side-projects go on with regard to the plan requires a modern platform. In addition, all requirements, customer journeys, responsibilities, protocols, etc. should be managed in a suitable knowledge platform to reduce work and increase quality of content.
Furthermore, it is important to have a coherent team and an assertive leadership to accelerate required steps in other projects or cancel them if they are not aligned with the meticulously devised target architecture.
In modern solutions to manage large-scale projects, rightful expectations of such platforms were laid out. Since OCA is in fact a large-scale and complex project, many points apply to its context as well. Depending on the existing IT landscape, tools and options for process and knowledge management may vary. One of the best combinations, however, is using Jira and Confluence equipped with suitable plugins. Jira, reinforced by the apps ScriptRunner, Workflow Essentials, and Rich Filters (plus BigPicture if you need Gantt charts) can be customized to support any necessary PMO (Project Management Office) activities including task management, risk management, time management, reporting, monitoring, communication, etc.
Confluence can then be configured to act as a collaborative knowledge management platform that is happily integrated with Jira. Additional apps such as Draw.io (for collaboratively generating diagrams and charts) and Handy Macros (to increase usability and quality of data) can provide invaluable functionalities for a state-of-the-art knowledge platform and efficient information management.
Other tools such as Slack, Trello and Miro may be used to enhance communication, organization and ideation, respectively. Basically, it does not matter what tools you use, as long as they fulfill your expectations and provide a high degree of customization and usability. There are only two stark warnings: 1) avoid using Excel to manage activities and items in a complex project like OCA, and 2) beware of the fact that SharePoint is simply a file repository and not a knowledge management system.
Since OCA requires extensive documentation of business processes and IT landscape for both as-is and to-be scenarios, it makes sense to have a proper tool to document your Enterprise Architecture (EA). A designated EAM tool is not necessarily a must, as long as you have a collaborative knowledge management platform such as Confluence, where you can draw practically any types of diagrams and link them with one another. However, if such a platform is missing, it is highly recommended to have a professional EAM tool to document as-is and devise to-be architecture on both business and technology layers.
If your company already has an established EAM tool (e.g. Leanix or BlueDolphin), you are in luck and you can surely use them for EA documentation and design. If there are no tools and using web-based platforms is not easily possible due to legal restrictions, you may use Archi. Archi is a desktop open-source modelling tool based on the Archimate modelling language. It is not a web-based and collaborative tool as any tools in 2020 should be; however, using it is still better than having no tools at all.
Methodological market analysis
As mentioned in the previous post, finding the right (set of) solution(s) is a significant success factor for any OCA program. An omni-channel solution is the pivotal point that basically brings everything together. A wrong solution will cost enormous amounts of time and resources in the long run. Considering the number of options in the market, finding The One is only possible with systematic formulation of expectations, comprehensive searching and meticulous evaluation of features and examination of both tools and vendors.
Requirement collection and evaluation cannot be regarded as a standalone step. It means it is not an activity that can be carried out after or before certain phases and be resolved. Evaluation of tools should be performed along with with collecting and refining requirements. Market analysis is nothing but an iterative process that impacts both technical and business architecture and requirements and at the same time is influenced by them.
Iterative requirement analysis in selecting an omni-channel solution
Providing an elaborate description of a methodological market analysis is not within the scope of this post. However, here are a few tips to help you have a frame of action.
Must-criteria as the first step
Preparing a list of must-have criteria is a must to weed out numerous options to a handful qualified solutions (less than 10). Must-have criteria depend on the context and requirements and vary from company to company. Nevertheless, there are a few must-have criteria that apply to almost any modern organization. You may start with this list and then extend it based on specific necessary requirements that suit your situation.
Web-based and cross-browser
Both agents and admins modules of the solution must be web-based and cross-browser, meaning they should be accessible via any browser. In the third decade of the 21st century it is simply not acceptable for any vendor not to have a web-based solution. This is by far the most important must-factor in choosing a selection.
LDAP synchronization of users
It should be possible to synchronize users from a central user repository such as Active Directory or Keycloak. Local administration of users for such an important solution with a vast variety of users contain huge implicit costs and poses security risks.
Low-code implementation technology
An omni-channel solution requires constant customization and development. Low-code platforms have existed for over a decade now and have been proven to have a significantly lower cost in both maintenance and development due to modular development that can be done up to ten times faster than traditional software. Unless you want to adjust your processes to a rigid solution and pay many times more in terms of operation, you should go with low-code solutions. ContentGuru’s Storm and Kiamo are good examples of low-code omni-channel communication platforms.
Weighting formulated criteria
Other criteria should be weighted in order to be able to calculate a quantitative score for the rest of the filtered solutions. The weight should be determined in collaboration with end-users and admins. These weights should be transparent to reduce possible conflicts later. During demo sessions, where the remaining solutions (those that have fulfilled must-criteria) are evaluated, these criteria are rated (e.g. from 0 to 5). These ratings are then normalized based on the determined weight to get a final score for the whole solution of its modules. Remember that some qualitative factors may play a crucial role in selecting a solution. This means that a solution with the highest score may not be the best choice after all. However, having a quantitative approach provides transparency and a frame for discussion and decision making.
Constant refinement of criteria
In each demo session, new approaches, features or technologies may be discovered. These new findings should be incorporated into the list of requirements, so that all solutions are assessed equally. For example, imagine you notice a very useful functionality that you have not put in your requirement list before. This new functionality should be added to the list with a corresponding weight, and its value should be updated for all previously evaluated solutions.
Desisting attractive licensing traps
Some vendors who used to have a good product two decades ago and therefore still have a large market share, may offer attractive licensing models to lure you in despite not fulfilling your must-criteria. It is of utmost importance to desist the temptation of “cheap licenses”. Remember that outdated solutions cost unbelievably more in the long term and often cause user and customer dissatisfaction. Technological maturity should always come first and especially before possible financial benefits.
Planning big and starting small
It is highly recommended to consider all relevant aspects of an omni-channel ecosystem when analyzing the requirements and designing a target enterprise architecture. Having said that, it is also crucial to start small and let the platform grow organically. In other words, design should be done in a global manner and roll-out in a local and step-wise way. For large and historically grown enterprises, the goal is to have a clear vision and a well-thought-out roadmap to be fully omni-channel in 3 to 5 years. This means that necessary side-projects based on the defined SMART expectations do not have to be resolved in a short period of time. This includes initiatives such as replacing an outdated website, migrating a module of a CRM to the omni-channel solution, a new system for pipeline management, retiring an OCR system, etc. All these can be dealt with later. The point is not to ignore or downplay them or compromise on a faulty vision because these projects take time to carry out.
Intensive and target-oriented communication
As in any other contexts such as relationships, political debates or international negotiations, transparent, target-oriented and intensive communication is the key to success. Remember some systems may be retired, some departments may be merged and some positions may be redefined. Without communication and persuasion, the amount of resistance will bring any project to its knees. Important stakeholders and positions, including a working union (Betriebsrat in Germany), management board, department managers, team leaders and employees should be kept up-to-date and consulted with for every change that may affect them or their daily activities. No matter how sophisticated and modern a system is or how meticulous and flawless an architecture is, without the consent and collaboration of important stakeholders it has a small chance of sustainable success. This is why communication, together with leadership support, is the most important non-technical requirement for OCA.