CC BY
74Программная архитектура решений для поддержки омниканальности
см см о см
СП
о ш т
X
<
т о х
X
Царев Андрей Олегович
аспирант, Департамент бизнес-информатики, Финансовый университет при Правительстве Российской Федерации, [email protected]
Омниканальность является сегодня одной из наиболее выигрышных стратегий развития для предприятий различных отраслей, ориентированных на B2B и B2C бизнес. Омниканальный бизнес делает акцент на взаимодействие между каналами и потребителями, уделяя особое внимание интеграции всех цифровых и физических каналов для увеличения количества точек соприкосновения с клиентами, беспрепятственного взаимодействия и получения обратной связи.
Целью данной работы является анализ типовых программных продуктов для поддержки омниканальности, а также формирование требований к омниканальной платформе для крупной холдинговой структуры.
В работе представлено исследование архитектуры омника-нальных решений. Представлен анализ типовых решений, обеспечивающих омниканальность, а также рассмотрена их архитектура. Сформированы требования к омниканальному решению, а также рассмотрен пример верхнеуровневой референтной модели. В ходе исследования были выявление требования к омниканальной системе, а также рассмотрена верхне-уровневая омниканальная архитектура по методологии TOGAF. Был проведен анализ типовых омниканальных систем. Ключевые слова: омниканальность, клиентский путь, клиентский опыт
Введение
Изучение омниканальных систем вызывает внимание со стороны научного сообщества, которое изучает омниканальность как в практико-ориентированном, так и в базисном его проявлениях. Ученые по-разному понимают омниканальность и термины, связанные с ней.
Так, наиболее четкие трактовки обычно включают в себя три измерения системы. В первую очередь -это технологическое измерение, которое способно без потерь объединить различные процессы, происходящие в разрозненных каналах. Уделяется много внимания организационному измерению, в котором отражается внутренние состояние фирмы, её желание менять свои процессы, организовывать свою культуру под совместное управление несколькими каналами. Третье, клиентское измерение отражает отношение клиента к компании и ей деятельности, базируясь на собственно опыте.
Учитывая вышеизложенное, можно трактовать "омниканальность" как способ осуществления клиенториен-тированной стратегии, базирующийся на совместном ведении всех цифровых и физических каналов коммуникации с клиентом, при привлечении внутренних процессов и информационных систем, ведущий к совершенствованию клиентского отношения к продукту и компании в целом.
На практике оказывается, что омниканальность не просто внедрить. Поскольку развитие омниканальности напрямую зависит от уровня зрелости компании. У крупных компаний существует проблема, когда большинство процессов формализовано и внести какое-либо изменение становится затруднительно. На рынке представлено много типовых решений, но отсутствие референтных моделей программной архитектуры затрудняет внедрение таких систем в компаниях с высоким уровнем зрелости, например холдинговых структурах. С другой стороны, небольшие компании активно внедряют элементы омниканальности, поскольку обладают стандартными процессами, поддающимися автоматизации. Те программные продукты, которые подходят для малого и среднего бизнеса являются непригодными для крупных компаний.
Целью данной работы является анализ типовых программных продуктов для поддержки омниканальности, а также формирование требований к омниканальной платформе для крупной холдинговой структуры.
В работе представлено исследование архитектуры омниканальных решений. Представлен анализ типовых решений, обеспечивающих омниканальность, а также рассмотрена их архитектура. Сформированы требования к омниканальному решению, а также рассмотрен пример верхнеуровневой референтной модели.
Популярные омниканальные системы
В настоящее время на российском и мировом рынке программных средств присутствует множество продуктов, осуществляющие сбор, хранение и обработку обращений клиентов, их запросов, собирание и анализ статистической информации, которая позволяет выявить наиболее удачные каналы продаж. Рынок данных ИТ-решений предоставляет широкий выбор готовых решений.
На российском рынке программных средств можно выделить следующее программное обеспечение, предоставляющие возможности в рамках обработки обращений [1]:
- Юздеск;
- ITSM 365;
- Битрикс Открытые Линии;
- Freshdesk;
- Omnidesk;
Каждый программный комплекс обладает базовыми функциями в области обработки обращений и качественной поддержки клиентов во всех каналах. Но в зависимости от решения, если отличия. Рассмотрим их подробнее.
Юздеск [2]. Представляет собой HelpDesk систему обработки заявок из цифровых каналов. Позволяет настроить теги с статусы для обращений, назначение исполнителей, контроль SLA, преднастройка шаблонов ответов и многое другое. Основные цели, решаемые системой:
- позволяет интегрироваться и собирать информацию из 12 различных, цифровых каналов, среди которых мессенджеры, социальные сети, виртуальная телефония, форма обратной связи и т.д.;
- настройка правил автоответов на стандартные вопросы, автоматическая смена статусов, присвоение тегов;
- настройка отчётов продуктивности обработки заявок, SLA, CSI и другие. Возможность отслеживания насколько качественно и быстро формируется ответ в разрезе каждого агента, отдела или всей компании в целом
- возможность создания виджета на сайте: мессен-джеры, онлайн-чат и база знаний. Создание базы знаний, позволяющей клиенту самостоятельно, в считанные минуты, решить вопрос;
ITSM 365 [3]. Сервис для внутренней и внешней поддержки. Представляет собой платформу Naumen Service Desk, преднастроенную для малого-среднего бизнеса. Включает в себя Service Desk, портал самообслуживания, личные кабинеты бизнес-пользователей, каталог услуг (внешних или внутренних), базу знаний, каталог оборудования, программного обеспечения и ИТ услуг, внутренние задачи, а также инструменты для управления изменениями, проблемами и конфигурациями, модуль отчетности. Основные цели, решаемые системой:
- управление клиентами. Сохранение в системе данных о клиентах, сотрудниках клиента, предоставление клиенту доступа в личный кабинет для работы с заявками через портал и мобильное приложение.
- работа с заявками. Автоматическая регистрация любого обращения пользователя, интеграция с почтовыми сервисами и виртуальной телефонией.
- сервисные контракты и биллинг. Возможность настройки для каждого клиента SLA, прайс-листов, учёта денег рабочего времени;
- учёт оборудования. Организация учёта оборудования, принятого от клиентов в рамках выполнения услуг или обслуживания.
Битрикс Открытые Линии [4]. Открытые линие в Битрикс 24 позволяют собирать сообщения со всех каналов взаимодействия, формирование очереди, маршрутизация между сотрудниками. Всё это происходит в режиме реального времени. Основные цели, решаемые системой:
- подключение каналов коммуникации (мессенджеры, социальные сети и др.);
- распределение обращений между сотрудниками. В режиме реального времени обращения сортируются в зависимости от преднастроенных правил распределения;
- автоматические сообщения на действия клиентов. Автоответ на первое сообщение клиента, сообщение по таймауту, настройка времени ответа;
- опрос по лояльности клиентов. Проведение оценки качества обслуживания.
- настройка чат-бота для работы на первой линии поддержки;
- настройка KPI показателей;
Freshdesk [5]. Система поддержки клиентов. Основные функции системы:
- многоканальная поддержка. Позволяет свести воедино общение с клиентами по разным каналам связи и управление ими в рамках одной платформы;
- повышение продуктивности работы команды. Позволяет высвободить ресурсы компании, при автоматизации повторяющихся задач;
- совместное решение заявок. Благодаря совместной работе, агенты быстро и эффективно решаю проблемы клиентов;
- мониторинг обращений. Автоматизация сценариев позволяет автоматизировать повторяющиеся операции, чтобы одним кликом сразу выполнять несколько действий в заявке;
Omnidesk [6]. Сервис для поддержки и общения с клиентами по всем каналам связи. Клиенты сами выбираю канал взаимодействия, а сотрудники работают с удовольствием. Основные функции системы:
- сбор обращений из различных каналов. Клиенты связываются с компанией любым доступным, не важно будет это социальная сеть или письмо, отправленное на e-mail;
- возможность ответа клиента там, где ему удобнее. Обсуждение одного вопроса можно вести через разные каналы. К примеру, клиент может обратиться к вам в Твиттере, а после с легкостью продолжить переписку через центр поддержки или электронную почту, если есть необходимость описать ситуацию подробнее.
- формирование базы знаний. Качественно составленная база знаний значительно облегчает жизнь клиентам, позволяя самостоятельно искать ответ на возникший вопрос;
В целом ИТ-решения имеют схожий функционал. Сравнительная характеристика систем будет осуществляться по каналам взаимодействия клиентом, стоимости за период пользования, возможности ведения клиентов и обработки обращений (таблица 1).
Если говорить о программной архитектуре, то большинство решений предоставляют возможность использовать как SaaS, так и on-premises модели. Freshdesk и Omnidesk распространяются только через облака. Что не подойдет многим компаниям, особенно холдингам, поскольку там серьезно заботятся о безопасности и сохранности клиентских данных.
X X
о
го А с.
X
го m
о
2 О
м м
Таблица 1
es es
0 es
СП
01
о ш m
X
<
m о x
X
Сравниваемые системы Юздеск ITSM 365 Битрикс Открытые Freshdesk Отг^еБк
Критерии Линии
сравнения
Стоимость 24 000р. / 18 000р. / 59 880 р. - 600$ / 1 150$ / 1
владения за 1 сотруд- 1 сотруд- весь пакет сотрудник сотрудник
год ник ник
Канал под-
держки
Почта Да Да Да Да Да
Чат Да Нет Да Да Интеграция
Вконтакте Сообщения + комментарии Нет Нет Нет Сообщения + комментарии
Телеграмм Да Да Да Отдельно Да
Whatsapp Да Нет Нет Да Нет
Viber Да Да Нет Нет Да
Телефония Манго Телеком, Гравител Да Да Да Манго Телеком
Twitter Да Да Нет Нет Нет
Возможности
обработки ти-
кетов
Пересыл сообщений Да Да Да Да Да
Внутреннние Да Да Да Да Да
комментарии
История обра- Да Да Да Да Да
щений
Связанные Да Да Нет Да Да
запросы
SLA Да Да Нет Да Да
База знаний Да Да Нет Да Да
RetailCRM Да Нет Да Нет Нет
Статистика
Отчет по ка- Да Нет Да Да Нет
налу
Отчет по SLA Да Да Да Да Нет
Удовлетво- Да Да Да Да Да
ренность клиентов (CSAT)
Отчет по те- Да Нет Нет Да Нет
гам и доп. по-
лям
Экспорт ста- Да Да Да Да Нет
тистики в таб-
лицу
Интеграция с CRM Да Да Да Да Да
Ограничения До 1000 До 1000 До 3000 До 1000 До 1000
по масштаби- пользова- пользова- пользова- пользова- пользова-
рованию телей телей телей телей телей
Архитектура решения ^М 365 предназначенного для автоматической регистрации инцидентов, показана на рисунке 1.
Сервер Файлов Конфигурации
Мониторинг здоровья ИТ-Инфраструктуры ! (SNMP. WMI. IP SLA. ...)j
Корпоративная ИТ-Инфраструктура
uo
Составлена автором по данным [1], [5], [7], [13]
Таким образом, учитывая особенности рассмотренных систем по организации омниканальной системы взаимодействия, можно заключить, что на рынке представлен широкий перечень программных продуктов с разной степенью оснащения и автоматизации. Как правило такие решения поддерживают не более 1000 пользователей, что не подходит для крупных холдинговых структур, насчитывающих несколько тысяч пользователей и огромную клиентскую базу.
Следующим шагом является рассмотрение архитектуры типовых омниканальных решений.
Архитектура типовых омниканальных систем
Для того, чтобы понять, почему типовые омниканаль-ные решения не подходят для решения задач на крупном холдинговом предприятии, необходимо рассмотреть их архитектуру.
Рисунок 1 - Архитектура омниканального решения ITSM 365 [5]
Агрегатор Информации - это специализированный сервер, выполняющий следующие функции:
• Мониторинг и экспертная оценка здоровья всех компонент ИТ-Инфраструктуры (сетевого оборудования, серверов, каналов связи и т.д.)
• Мониторинг и экспертная оценка производительности бизнес-приложений и Quality of Experience
• Приём Снимков Инцидента, генерируемых компьютерами пользователей, запись их в базу данных и сопоставление со здоровьем ИТ-Инфраструктуры, производительностью приложений, Quality of Experience.
Сервер Файлов Конфигурации обеспечивает автоматическую загрузку Файлов Конфигурации на компьютеры сотрудников. В качестве транспорта могут использоваться HTTP, FTP, файловый обмен. Файлы Конфигурации могут загружаться при старте программы EpM-Agent Plus (функционал HelpMe), по требованию (пожатию специальной кнопки), а также по нажатию «красной кнопки».
Решение также может быть интегрировано с внешними системами Service Desk, такими как HP Service Management, BMC Remedy и др.
При наличии Агрегатора Информации возможны три маршрута передачи Снимков Инцидента в Service Desk:
1. только в Service Desk
2. сначала в Агрегатор Информации, затем в Service Desk
3. одновременно в Агрегатор Информации и Service Desk [7]
Как можно видеть из рисунка, схема архитектурной модели, компоненты системы не изолированы друг от друга. С одной стороны, это плюс, поскольку скорость передачи данных в таком случае позволяет передавать большие объемы информации. Но отсутствие изолированности - плюс только для предприятий малого и среднего бизнеса. В случае, если система будет внедрена в крупную холдинговую структуру, то при сбое одного из компонентов системы другие также станут недоступны. А цена простоя в крупных холдингах слишком высока.
Следующая архитектура омниканального решения «Битрикс открытые линии» представлен в виде веб-кластера взаимозаменяемых серверов. При увеличении посещаемости можно быстро добавить в кластер новые серверы; в случае выхода из строя одного или нескольких серверов кластера все продолжает работать на оставшихся серверах, система продолжает беспрерывно обслуживать клиентов. Поддержка облачных файловых хранилищ решает проблему синхронизации статического контента, а реализация поддержки mastermaster репликации в MySQL позволяет строить географически распределенные веб-кластеры. Архитектура решения представлена на рисунке 2.
Цель технологии «Композитный сайт» - ускорить выдачу страницы пользователю за счёт выделения, последующей обработки и довыдачи зон с динамическим контентом с помощью дополнительного ajax-запроса.
Суть технологии «Композитный сайт» заключается в том, что в шаблонах компонентов, из которых создаётся динамичная страница, размечаются специальные зоны. В этих зонах содержится динамичный контент. При обращении пользователя к странице система создаёт кеш статической части страницы, в которые вставлен специальный JS, обращающийся к серверу за актуальными данными. При повторном обращении пользователя система отдаёт созданный файл кеша, а затем довыдает динамичный контент [8].
Изучив архитектуру решения, можно также прийти к следующему выводу: реляционная база данных будет неэффективна в крупном холдинге. Хранение клиентской базы в одном месте увеличивает стоимость транзакций. Поскольку омниканальная система в крупном холднге будет высоконагруженной, может возникнуть ситуация, когда дальнейшее масштабирование будет невозможно.
Еще один пример - архитектура типового омника-нального решения «Freshdesk», представленная на рисунке 3.
Corporate Network
Рисунок 2 - Архитектура омниканального решения «Битрикс открытые линии» [6]
Один из важнейших приоритетов в «Битрикс открытые линии» - постоянная доступность сервиса и его отказоустойчивость.
В случае аварии на одной или нескольких веб-нодах Load Balancing определяет вышедшие из строя машины и, исходя из заданных параметров группы балансировки (минимально необходимое количество запущенных машин), автоматически восстанавливается нужное количество инстансов.
Если теряется связность между датацентрами, то каждый датацентр продолжает обслуживать свой сегмент клиентов. После восстановления связности данные в базах автоматически синхронизируются.
Если же выходит из строя полностью датацентр, или же, например, происходит сбой на базе, то весь трафик автоматически переключается в работающий дата-центр.
В «Битрикс открытые линии» используется уникальная технология «Композитный сайт», реализованная в платформе «1С-Битрикс». Она объединяет в себе высокую скорость загрузки статического сайта и все возможности динамического сайта.
Страница портала разделяется на 2 составляющие: статическую и динамическую. Статическая часть кеши-руется и отображается мгновенно. Пользователь сразу видит содержимое и может работать с ним. Динамическая часть подгружается в фоновом режиме и кеширу-ется в браузере посетителя. В результате пользователь мгновенно получает контент страницы.
Рисунок 3 - Архитектура омниканального решения «Freshdesk» [7]
Freshdesk — это многопользовательское приложение SAAS с сегментированным уровнем базы данных. Входящие веб-запросы обслуживаются процессами, которые являются однопоточными и в любой момент времени могут обслуживать только один запрос пользователя. Поэтому, в зависимости от хоста, на котором запущено приложение, несколько процессов создаются с помощью копирования при записи, что позволяет одновременно обрабатывать несколько входящих веб-запросов.
Ограничение этой однопоточной модели заключается в том, что в любой момент времени только один пользовательский запрос обрабатывается одним процессом. Создание новых процессов требует дополнительных затрат времени и ограничено ограничениями системных ресурсов. В результате, если доступный пул процессов задерживается, и обработка запросов занимает больше времени, чем ожидалось, это влияет на способность обслуживать запросы. При ~500 000 об/мин даже небольшая процентная разница во времени отклика может привести к возникновению очереди запросов и ухудшению пользовательского опыта для клиентов.
X X
о го А с.
X
го m
о
ю
2 О
м м
CS CS
о
CS СП
о ш m
X
3
<
m о x
X
Таким образом, можно сказать, что типовые решения для внедрения процессов омниканальности в организацию не подходят для крупного холдингового предприятия [9].
Архитектура данных приложений выстроена таким образом, что при большом объеме данных и обработки тысяч клиентов, они не смогут обеспечить достаточный уровень производительности.
Все они представляют собой монолитные решения, которыми тяжело управлять с ростом количество хранимой информации.
Для расширения сетевых ресурсов, чтобы увеличить производительность, как правило приходится тратить слишком много времени. Тем самым время простоя может быть сильно увеличено.
Требования к омниканальным системам
Теперь необходимо сформулировать требования к омниканальной системы для крупного холдинга. Для составления требований использовалась классификация FURPS+
Требования блока продаж являются наиболее важным требованием к омниканальной системе, поскольку продажи приносят бизнесу прибыль. Функции продаж могут помочь максимизировать шансы на успех в закрытии сделок и увеличить количество сделок. Наибольшим спросом пользуются следующие инструменты:
1) Система должна обеспечить бесшовный процесс переключения между каналами: клиент может начать взаимодействовать с компанией в одном канале, а закончить в другом;
2) Обеспечение клиентского пути: система должна позволять предугадывать поведение клиента на основе его предыдущих действий на каждом этапе взаимодействия, начиная от зарождения потребности, до завершения финальной сделки;
3) Система должна предоставлять данные о транзакциях покупателя, как в базе данных, так и с помощью интерактивных дашбордов;
4) Система должна иметь возможность управлять задачами: ответственные сотрудники должны ставить задачи подчиненным и иметь возможность контролировать их выполнение в отчетах;
5) Система должна давать доступ к управлению возможностями (лид менеджмент) в разных каналах;
6) Система должна иметь возможность управления контактами;
7) Система должна иметь возможность настройки каналов взаимодействия с клиентами, хранить историю взаимодействия, показывать предыдущие контакты, подсказывать, какой товар мог бы быть интересен клиенту;
8) Система должна предоставлять возможность анализа воронки продаж и прогнозирования на основе данных о продажах;
9) Управление эффективностью продаж по всем каналам взаимодействия: возможность построения аналитики по каждому каналу;
В случае управления отделом продаж, омниканаль-ная система должна давать информацию для понимания того, насколько менеджеры эффективны, оценить их работу, подсчитать количество успешных сделок в различных каналах, отследить время, которое они тратят на каждый контакт, а также количество отработанных часов.
Кроме того, омниканальная система должна предоставлять возможность просматривать ход своих операций по продажам и понимать, сколько сделок было закрыто с помощью функции воронки продаж.
Маркетинговые инструменты омниканальной системы должны предоставлять следующие возможности:
1) Автоматизация маркетинговых инструментов по всем доступным каналам: возможность управлять маркетинговыми кампаниями, рассылками и акциями и реа-лизовывать их в удобном для клиента канале;
2) Система должна позволять управлять потенциальными возможностями в маркетинге;
3) Система должна позволять управлять электронной почтой и сегментировать потенциальных клиентов;
4) Система должна позволять реализовывать маркетинг событий - продвижение товаров по каналам с помощью акций;
5) Система должна позволять отслеживать взаимодействия с клиентом;
Омниканальная система должна позволять проводить целевые маркетинговые кампании по всем каналам взаимодействия, отслеживать ход каждого взаимодействия и лучше реагировать на потребности клиентов.
Требования к удобству использования:
1. Система должна быть интуитивно понятной, в системе должна содержаться справки и инструкции;
2. Система должна валидировать заполненные поля, если поле не предполагает внесение в него той или иной информации, в системе должно выводится соответствующее сообщение;
3. В случае возникновения ошибки система должна показывать соответствующее сообщение, понятное для неподготовленного пользователя;
Требования к надежности:
1. Частота сбоев системы не должна превышать 1 раза в неделю;
2. Система должна иметь тестовую среду, а также обеспечивать регулярное резервное копирование с полным сохранением текущих данных;
3. Время восстановления после полного отказа системы не должно превышать 15 минуты;
4. Система должна работать в режиме 24 часа 7 дней в неделю;
5. Клиентские транзакции должны появляться в системе в режиме реального времени (не превышать 3х секунд);
6. Аналитические отчеты должны быть доступны за предыдущий день;
Требования к производительности:
1. Пропускная способность омниканальной системы должна составлять 1000 сотрудников, работающих одновременно;
2. Среднее время отклика системы не должно превышать 2 секунд;
3. Архитектура системы должна быть масштабируемой, причем как по горизонтали, так и по вертикали: должна иметься возможность как увеличить серверную мощность текущих машин, так и добавить новые серверы;
Требования к ограничениям:
1. Клиентская часть системы должна работать на операционной системе Windows;
2. Серверная часть системы должна работать на операционной системе Linux и Windows;
3. Система должна обладать интерфейсом API для интеграции с внешними системами: CRM, Телефония, Сайты;
Это позволяет достигнуть высокого уровня маневренности и гибкости предприятия.
Важным моментом в выборе омниканального решения является его архитектура. Разберем пример референтной архитектуры омниканального решения для образовательной сферы.
На рисунке 4 показана структура верхнеуровневой референтной модели омниканальной архитектуры, которая содержит минимальный набор блоков и соответствующих сущностей для реализации омниканальной стратегии [14]. На этой диаграмме объекты понимания клиентов и прогнозирования ИТ-среды фиксируют конкретные требования, для реализации омниканальной стратегии.
АПСШТЕСТиПЕ VISION
IT ENVIRONMENT 5CMMHG
TECHNOLOGIES
-В-
CUSTOMER UNDERSTANDING
CHANNELS
-Ö-7-
REQUIREMENTS AHCHITÏCTUHE
CUSTOMER RELATIONSHIP MANAGEMENT
APPLICATIONS
ВИЯ
I л
INFCmUATigN SVSTËM ARCHITÏCTUR6
Information System Service 1
O Information Sysmm S»™kii J
Information Syriern Soviel pi
Logical Dat¿
-I ) Component
- channel
- CHANNEL 2
I— CHANNEL г
TECHNOUOGV ARCHITECTURE
Physical T"echno1c4H wmponenl 1
Physical Technology companErt 2
Physical Tec hnolciqy component л
Рисунок 4 - Верхнеуровневая референтная модель омниканальной системы [10]
Модель составлена согласно принципам TOGAF. В качестве бизнес-слоя можно привести пример: управление продажами, управление маркентинговыми кампаниями, управление потенциальными возможностями [15].
В качестве слоя-приложений предполагается разделение на микросервисы, согласно паттерну «деление по бизнес-возможностям».
Эти приложения должны быть синхронизированы с бизнес-процессами и структурированы для согласованной обработки информации независимо от того, какой канал использует клиент. Наконец, ИТ-приложения и услуги, которые будут поддерживать каналы или точки соприкосновения, развертываются в технологической
инфраструктуре, представленной в архитектуре объектами технологической архитектуры.
В качестве технологического-слоя крупные предприятия выбирают развертывание на собственных серверах и выстраивание собственный ИТ-архитектуры.
Исходя из озвученной постановки необходимо рассмотреть популярные системы, которые позволяют создать омниканальное взаимодействие, а также рассмотреть их с точки зрения архитектуры.
Выводы
Омниканальность является сегодня одной из наиболее выигрышных стратегий развития для предприятий различных отраслей, ориентированных на В2В и В2С
X X
о
го А
с.
X
го m
о
W
2 О M
to
es es о es
cñ
О Ш
m
X
3
<
m о x
X
бизнес. Омниканальный бизнес делает акцент на взаимодействие между каналами и потребителями, уделяя особое внимание интеграции всех цифровых и физических каналов для увеличения количества точек соприкосновения с клиентами, беспрепятственного взаимодействия и получения обратной связи.
В ходе работы были выявление требования к омни-канальной системе, а также рассмотрена верхнеуровне-вая омниканальная архитектура по методологии TOGAF. Был проведен анализ типовых омниканальных систем. С первого взгляда они обладают необходимым функционалом, но детальное рассмотрение показало, что для холдинговой структуры тех возможностей, которые предоставляют типовые омниканальные решения, будет недостаточно.
Типовые решения созданы без изолирования компонент друг от друга. В случае если откажет один компонент, откажет и вся система, что недопустимо при работе в большой холдинговой структуре.
Также системы спроектированы таким образом, что могут масштабироваться только вертикально, а чем больше данных копится в системе, тем больше нагрузка и соответственно цена транзакции. Когда данные централизованно хранятся в одном месте в определенный момент настанет время, когда дальнейшее масштабирование будет невозможно.
Пропускная способность таких решений ограничена, а холдинг, насчитывающий тысячи сотрудников, а также клиентов, не сможет воспользоваться таким решением.
Кроме того, типовые омниканальные решения в большинстве своем предполагают модель работы SaaS, то есть облачные решения. Когда как холдинговые структуры особо заботятся о безопасности и сохранности персональных данных, поэтому рассматривают только решение на собственных серверах.
Литература
1. Основные принципы омниканальности Шертай Б.М. В сборнике: Приоритетные направления развития науки и образования сборник статей VII Международной научно-практической конференции: в 2 ч. 2020. С. 82-86.
2. Зачем нужна омниканальность, или преимущества комплексного подхода к коммуникациям. [Электронный ресурс]. -Режим доступа: https://www.cossa.ru/Chat2Desk/233950/ (дата обращения 25.06.2022).
3. Рейтинг HelpDesk систем 2021. [Электронный ресурс]. -Режим доступа: crmindex.ru/helpdesk (дата обращения 14.07.2022).
4. Юздеск. [Электронный ресурс]. -Режим доступа: https://usedesk.ru (дата обращения 14.07.2022).
5. ITSM365. [Электронный ресурс]. -Режим доступа: https://itsm365.ru (дата обращения 14.07.2022).
6. Битрикс 24. [Электронный ресурс]. -Режим доступа: https://helpdesk.bitrix24.ru (дата обращения 14.07.2022).
7. Кнопка помощи ITSM. [Электронный ресурс]. -Режим доступа: https://911.prolan.ru/technology/registration.html (дата обращения 15.07.2022).
8. Архитектура Битрикс [Электронный ресурс]. -Режим доступа: https://helpdesk.bitrix24.ru/open/1292927/] (дата обращения 15.07.2022).
9. Scaling the Freshdesk web app for high Availability [Электронный ресурс]. -Режим доступа: https://www.freshworks.com/saas/scaling-the-freshdesk-
web-app-for-high-availability-blog/ (дата обращения 15.07.2022).
10. Hosseini, S., Merz, M., Roglinger, M., Wenninger, A., (2018), Mindfully going omnichannel: An economic decision model for evaluating omnichannel strategies, Decision Support Systems Volume 109, May 2018, Pages 74-8.
11. Luo, Jifeng and Fan, Ming and Zhang, Han, Information Technology, Cross-Channel Capabilities, and Managerial Actions: Evidence from the Apparel Industry (2015). Journal of the Association for Information Systems, Research Paper No. 2016-056.
12. Yadav, V. S., Tripathi, S., & Singh, A. R. (2017). Exploring omnichannel and network design in omni environment. Cogent Engineering, 4(1),
13. Thamm A., Anke J., Haugk S., Radic D. (2016) Towards the Omnichannel: Beacon-Based Services in Retail. Business Information Systems. BIS 2016. Lecture Notes in Business Information Processing, vol 255.
14. Mirsch, T., Lehrer, C., Jung, R., Transitioning to an omnichannel approach: A dynamic capability perspective, 2016 International Conference on Information Systems, ICIS 2016
15. Hartfelder, J., Winkelmann, A., Opportunities and challenges for local retailing in an environment dominated by mobile internet devices - Literature review and gap analysis, Multikonferenz Wirtschaftsinformatik, MKWI 2016 1, pp. 33-44
Software architecture for omnichannel solutions Tsarev A.O.
Financial University under the Government of the Russian Federation JEL classification: B00, D20, E22, E44, L23, L51, L52, M11, M20, M30, Z33
Omnichannel is today one of the most winning development strategies for enterprises in various industries focused on B2B and B2C business. The omnichannel business places an emphasis on interaction between channels and consumers, focusing on integrating all digital and physical channels to increase customer touchpoints, seamless interactions and feedback.
The purpose of this work is to analyze typical software products to support omnichannel, as well as to formulate requirements for an omnichannel platform for a large holding structure. The paper presents a study of the architecture of omnichannel solutions. An analysis of typical solutions that provide omnichannel is presented, as well as their architecture is considered. The requirements for an omnichannel solution are formulated, and an example of a top-level reference model is considered. During the study, the requirements for an omnichannel system were identified, and the top-level omnichannel architecture was considered according to the TOGAF methodology. An analysis of typical omnichannel systems was carried out. Keywords: omnichannel, customer journey, customer experience References
1. Basic principles of omnichannel Shertai B.M. In the collection: Priority
directions for the development of science and education collection of articles of the VII International Scientific and Practical Conference: at 2 o'clock 2020. P. 82-86.
2. Why do we need omnichannel, or the benefits of an integrated approach to
communications. [Electronic resource]. - Access mode: https://www.cossa.ru/Chat2Desk/233950/ (accessed 06/25/2022).
3. Rating of HelpDesk systems 2021. [Electronic resource]. - Access mode:
crmindex.ru/helpdesk (accessed 07/14/2022).
4. Usedesk. [Electronic resource]. - Access mode: https://usedesk.ru
(accessed 07/14/2022).
5. ITSM365. [Electronic resource]. - Access mode: https://itsm365.ru
(accessed 07/14/2022).
6. Bitrix 24. [Electronic resource]. - Access mode: https://helpdesk.bitrix24.ru
(accessed 07/14/2022).
7. ITSM help button. [Electronic resource]. - Access mode: https://911 .prolan.ru/technology/registration.html (accessed 07/15/2022).
8. Bitrix architecture [Electronic resource]. - Access mode: https://helpdesk.bitrix24.ru/open/1292927/] (accessed 07/15/2022).
9. Scaling the Freshdesk web app for high Availability [Electronic resource]. -
Access Mode: https://www.freshworks.com/saas/scaling-the-freshdesk-web-app-for-high-availability-blog/ (Accessed 07/15/2022).
10. Hosseini, S., Merz, M., Röglinger, M., Wenninger, A., (2018), Mindfully going omnichannel: An economic decision model for evaluating omnichannel strategies, Decision Support Systems Volume 109, May 2018, Pages 74 -eight.
11. Luo, Jifeng and Fan, Ming and Zhang, Han, Information Technology, Cross-Channel Capabilities, and Managerial Actions: Evidence from the Apparel Industry (2015). Journal of the Association for Information Systems, Research Paper No. 2016-056.
12. Yadav, V. S., Tripathi, S., & Singh, A. R. (2017). Exploring omnichannel and network design in omni environment. Cogent Engineering, 4(1),
13. Thamm A., Anke J., Haugk S., Radic D. (2016) Towards the Omnichannel:
Beacon-Based Services in Retail. Business Information Systems. BIS 2016. Lecture Notes in Business Information Processing, vol 255.
14. Mirsch, T., Lehrer, C., Jung, R., Transitioning to an omnichannel approach: A dynamic capability perspective, 2016 International Conference on Information Systems, ICIS 2016
15. Härtfelder, J., Winkelmann, A., Opportunities and challenges for local retailing in an environment dominated by mobile internet devices -Literature review and gap analysis, Multikonferenz Wirtschaftsinformatik, MKWI 2016 1, pp. 33-44
X X
o
OD A c.
X
OD m
o
2 O
ho ho
