Один раз выучил, затем для самых разных “путешествий” думаешь одинаково
Вырисовывается некоторая онтология путешествия чего угодно, которая везде излагается разными словами, но для нас это изложение в терминах мета-мета-модели (считайте это кратким содержанием предыдущих серий постов про клиентоориентированность – NPD, JTBD в Клиентоориентированность в методологиях разработки. NPD, JTBD.: ailev — LiveJournal, CEM/CXM в Клиентоориентированность. CEM/CXM.: ailev — LiveJournal):
– в типах мета-мета-модели: есть альфа как предмет инженерного процесса (в каждой предметной области называется по-своему, предмет особого внимания в ходе работ какого-то проекта/кейса (предмет кейса – эта самая альфа, кейс можно считать закрытым после приведения альфы в конечное состояние). Есть создатели в графе создания, которые двигают альфу по её состояниям, пытаясь как-то в этом скоординироваться. Есть инженерный процесс, разложение которого на методы и определяет, что::метод и кем::роль будет делаться с альфой. Есть поток работ, который определяет, что::работа и кем::оргзвено, а ещё и когда::время будет делаться с альфой. По факту же действия идут с рабочими продуктами (ибо альфы всё-таки ментальные объекты). Инженерный процесс дальше мы раскладываем на отдельные методы во много уровней – и это больше похоже на функциональное программирование, а не “пошаговое императивное программирование”. А потом у нас кейс-менеджент, чтобы проуправлять оптимальным временем работы и задействованием ресурсов для затаскивания предмета кейса (он же – предмет метода) в нужное состояние. Для отслеживания состояния альфы для рабочих продуктов используем коллективный экзокортекс: систему версионирования, а для отслеживания кейсов – issue tracker. В экзокортексе держим описания как предмета метода (необязательно даже системы как вещи, могут быть и описания, а ещё альфа как объект внимания может перескакивать между объектами разной онтологической природы по ходу работ с ней), так и описания графа создания (хотя тут могут создаваться и не системы, но мы широко протрактуем тут граф создания – агенты, которые меняют состояния предметов метода, ибо для методов со сложным многоуровневым разложением может быть довольно-таки разветвлённый граф создания).
– в машиностроении: есть гравицапа, для которой мы применяем процесс “scaled грави-agile с поправками для цап”. Наши самые разные инженеры (архитекторы, проектировщики, технологи и т.д.) двигают гравицапу по её состояниям от “задумано”, через “спроектировано” и “изготовлено” до “используется”, пытаясь как-то скоординироваться. Гравицапа находится в состояниях “как проект”, “в виде сырья”, “готовая” и когда-нибудь “мусор”. Чтобы не запутаться, версии проекта храним в PDM, работы и прохождение состояний – в issue tracker (а поскольку мы современны, то это вместе называем PLM), версии в ходе изготовления храним в ERP, версии в ходе эксплуатации в EAM (enterprise asset management).
– есть автономные интеллектуальные агенты, которые могут запросто сами что-то задумать и сделать. Обычно это люди, но могут быть сегодня и какими-нибудь AI-системами, а также коллективами из них всех (при этом коллективы вроде организации, “лица” мы ещё признаём как-то с натяжкой агентами, иногда даже государства признаём такими “лицами”, но вот сообщества и общества, даже клиентуры и даже инвестуры – тут проблема). Если создатели с ними работают, то возникает проблема: они ещё и сами себе создатели, поэтому нельзя планово переводить их из одних требуемых состояний к другим – “лошадь можно подвести к воде, а заставить попить – нельзя”. Ещё они могут быть сразу в двух или больше состояниях (выделяются подальфы) и появляться у провайдеров разных обработок в заранее неизвестном порядке (ибо ещё и сами ходят, а не их за ручку водят). И ещё у них есть свои впечатления от происходящего, и если они становятся отрицательными – всё, можно списывать все предыдущие потраченные на них силы. Впрочем даже гравицапу можно испортить на любом шаге обработки, это не является чем-то особенным. Тем не менее, понятно, что надо отслеживать experience (впечатления) таких агентов-людей в ходе контактов/touches (и тут много чего может быть разного в ходе контакта-как-процесса: вовлечение, обучение, формирование впечатлений, взаимодействие и т.д.) с нашими создателями/местами-обработки/местами-контакта/touchpoints.
Поэтому мы получаем попытки работать с людьми “как в машиностроении” – и мало что получается. Основные признаки “как в машиностроении”:
– “колбаски водопадов”, линейки “прохода по состояниям”. Если в учебнике все эти “стадии” и “фазы” выглядят красивыми, то в жизни всё будет ни разу не по учебнику, причём точек контакта заведомо больше, чем мы проектируем. Поэтому вместо всяких там “жизненных циклов” или “стадий-этапов” мы вводим метафору “путешествия” и говорим, что маршрут совершенно необязательно линеен. При этом да, хорошо бы иметь карту с этими touchpoints и как-то отслеживать типовые маршруты и выявлять незапланированные точки контактов. В конце концов, договариваемся, что вообще неплохо бы иметь бесконечное путешествие – и продавать, продавать, продавать всю жизнь, а также если и не продавать, то вербовать в создатели (делать touchpoint – загонять в сообщество, предлагать рекомендовать продукт знакомым и т.д.). Это всё было “управление жизненным циклом”, теперь это “управление путешествиями” (customer journey management). Важно, что “путешествие” – это процесс, поэтому формально это управление кейсами, управление процессами и всё вот по этой линии операционного менеджмента в его стыке с методологией. Типовой софт – “оркестровщик процессов” (координация и синхронизация работ/touches по выполнению одного кейса – работы с одним “обрабатываемым человеком”), но перед этим ещё надо нарисовать карту местности путешествия, чтобы на ней обозначить места контактов, спроектировать сами эти точки контакта и происходящее в них. Управление путешествием (customer journey management) тут. И именно тут проектирование товара или сервиса или даже развлечения, или обучения, или маркетинга и т.д. (сервиса по приведению во впечатлённое состояние), Journey design, кастомизация и т.д., а поскольку часть использования тоже входит в путешествие, то JTBD как job-process входит сюда.
– обработки людей не гарантированы (см., наример, про иммунитет к маркетингу в Иммунный ответ мокрой нейросетки на "маркетинг": ailev — LiveJournal). Мозги промыть кому-то или удаётся после множества контактов (touches), и нельзя сказать заранее, сколько их будет надо. А ещё надо всё-таки как-то направлять людей, чтобы они добирались до конца маршрута и там оказывались в нужном состоянии, ибо если их не подталкивать – так и могут путешествовать вечно по контактам самого начала маршрута. Там несколько альф, которые надо отслеживать:
- Клиентоориентированность как смещение референтного индекса с “удобно и важно создателю” на “удобно и важно обрабатываемому человеку” – вот это и называют “клиентоориентированность”, надо моделировать не только то, что делает с целевым человеком какой-то сотрудник компании, но главным образом моделировать по результатам актуальных замеров происходящее в самом человеке с точки зрения самого этого человека: чему он научается (а не только чему мы хотим научить), например, есть ли у него мастерство лояльности, мастерство пользователя, мастерство хотя бы покупателя товара. И ещё нужно моделировать по реальным замерам его впечатления, а не только иметь проект впечатлений, которые хотят дать сотрудники.
- Впечатления, оценка реального состояния которых по сравнению с ожиданием должна оказываться положительной. Это и есть experience management, управление впечатлениями по мере путешествия по точкам контакта, оценку надо удерживать положительной, “превосходить ожидания”. Про мастерство пользователя, покупателя, лояльности, помощника рекламиста (идеал – MLM для каждого продукта!) и как его оценивать – это отдельная история, пока её умолчим.
Не всё так просто. Например, рассмотрим впечатления клиента “качалки”, где на тренировке его встретили, усадили в кресло, вместо него покачались-поотжимались-поподтягивались и даже толкнули штангу, а ему в это время предложили попить апельсиновый сок, затем помогли одеться – и тренировка окончена. Или его встречает тренер и он на полусогнутых выползает из этой качалки, думая, что “хорошо, что не надо было скорую вызывать” и “никогда не думал, что я столько подниму”. Что там с впечатлениями от этого touch? Тренировка-развлечение или тренировка-обучение? А если речь идёт о высшей математике? А если речь идёт о системном мышлении? Всё не так однозначно, существенно зависит от культуры той или иной предметной области. Опять же, если у вас не b2c, а b2b – то всё существенно усложняется, ибо разговор остаётся тот же самый “про людей”, но там этих людей внутри b2b будет не один customer и он же user, а много – и ещё разных видов, убалтывать надо будет на разное.
Поэтому мы понимаем, что экзокортексы для “клиентоориентированности” будут предлагаться самые разные, часть из них будет поддерживать “водопад” (по старинке, “классическое проектное управление”), часть – кейс-менеджент (по-современному это и будет “проект”), часть будет поддерживать “процессное управление” (где 95% экземпляров процессов проходят по стандартному маршруту, а 5% становятся дикой головной болью и занимают 95% времени на внимание к себе). Всё то же самое, но поскольку предметная область другая, то и названия будут другие. Наши материалы нужны, чтобы во всём это быстро ориентироваться. Скажем, только в области маркетинга вам в 2024 будет предложено 14106 софтверных продуктов самых разных типов (MarTech – маркетинговые технологии). Что из них вам надо? Что не надо? Что из них поддерживает допотопные способы мышления? Что заведомо не сработает? Вот (2024 Marketing Technology Landscape Supergraphic — 14,106 martech products (27.8% growth YoY) – Chief Marketing Technologist):
Понятно, что таксоны в этой классификации взяты “исторически” и ничему осмысленному не соответствуют, легко найти множество других классификаций (ни один термин в них не повторяется! хотя слова повторяются: marketing, experience, customer, channel, journey и т.д.), да ещё это всё “платформы” (давно не “приложения” и не “комплекс/suite”, это ж ранг пониже – а “платформа” звучит гордо!), которые необъятны в числе своих модулей – управление маркетингом ведь эквивалентно какой-то ERP, учитывающей движение клиентуры по сложной сети touchpoints, только enterprise client resource planning (планирование клиентских ресурсов предпрятия, пошутим так) не так-то просто – на склад полуфабрикаты не положишь, сырьё на условиях just-in-time не закупишь.
Поэтому придётся каждый раз разбираться, но не с нуля, в этом и выигрыш! Речь идёт об агентах в самых разных внутренних и внешних ролях/stakeholders, о которых думают сегодня примерно одинаково – и это “одинаковое думание” возможно ещё до знакомства с конкретной предметной областью, её методами, софтом и другими инструментами, которые поддерживают эти методы. Причём это всё важные объекты, которые должны быть как-то отражены в чеклистах, это всё “чеклист в голове” в тот момент, когда вы изучаете новую ситуацию (а ситуация каждый день будет новой даже в старом проекте, жизнь не остановишь):
– employee journey тут идёт по примерно такой же линии рассуждений, только тут не клиентоориентированность, а сотруднико-ориентированность. И тут тоже отход от “водопада” к разным траекториям/путям/маршрутам путешествия по организации, и это тоже надо отслеживать. И там тоже experience, вовлечение, мотивирование, попытки проектирования маршрута и неожиданные места контакта (touchpoints) с неожиданными результатами этих контактов в конечном итоге (outcomes, хотя каждый раз будет вроде понятный output от известных нам контактов – но есть же и неизвестные!). И кастомизация, индивидуальные карьерные планы.
– learner journey – тут всё то же самое, и тоже индивидуальные учебные программы при понимании, что без автоматизации ничего хорошего из индивидуализации обучения не получится, а автоматизация часто невозможна.
– community member journey, и тут тоже полно всяких platforms, и тоже полно “проблем из жизни”. Софт, конечно, который поддерживает только решение тех проблем, о которых у него есть модель данных. AI это вроде должен менять, но пока это всё только в далёких планах.
– … много всего такого, называемого очень по-разному, и хорошо бы экономить мышление и понимать, что это всё одно и то же, в ходе своего исторического развития ползущее от первого к третьему поколению системного мышления, от “водопадов” к разным “спиралям”, а затем “путешествиям”, да ещё и с необходимостью выявлять некоторые места контакта с создателями, ибо не всегда внутренняя инженерная платформа (internal engineering platform, разработчики “конвейера” с местами контакта software engineers с будущим софтом и дальше с его пользователями – вот так это называется для софта) соответствует описаниям, и надо быть всегда начеку, чтобы отслеживать вторжения. Да, на производстве даже не очень живых продуктов надо выявлять эти “путешествия”. Например, вы отдаёте на завод информационную модель, завод раздаёт её фрагменты “по кооперации”, там “улучшают” части информационной модели, делают круглое квадратным и наоборот, а потом всё это превращается в металл – и банально не может собраться вместе. Почему?! Неучтённый в internal engineering platform внешний touchpoint (а теория говорит, что обработки предметов метода могут происходить и в незапланированных точках), где информационная модель изменяется подрядчиками завода по каким-то своим соображениям. Или та самая “пропитка” из курса “Системный менеджмент”: решения принимаются не теми, с кем вы разговаривали и кого уговаривали, а какими-то их влиятельными друзьями. Поэтому убалтывать надо этих друзей, а поскольку вы их не знаете, то хорошо бы уболтать вообще всех – и тогда нужное решение не встретит скрытого сопротивления. Это всё экземпляры общего рассуждения, customer experience management и customer journey тут только примеры. Ровно как job-to-be-done – пример рассуждения о методе и роли вместо рассуждения о персоне агента, это тоже пример общего рассуждения.
Customer relationship systems, которые стали customer journey management systems и customer experience platforms.
Трудно поверить, но ещё до информационных систем CRM (customer relationship management), то есть ещё в далёких 80х годах гуляли слова database marketing (Database marketing - Wikipedia – это “официальные спамеры”, которые вели списки рассылки direct marketing, но гордились тем, что рассылали не всем подряд, а делали “выборку из базы данных”), и relationship marketing (Relationship marketing - Wikipedia – для которого важней было удержать отношения, “никакая продажа не является последней”). Relationships/отношения – это когда у вас не одномоментная сделака, а длящиеся во времени отношения, и хорошо бы накапливать об этом информацию, иметь память о том, с кем ты в каких отношениях, как эти отношения развивались, какие есть планы по дальнейшему развитию отношений (это эвфемизм для “что мы можем туда ещё продать”), поэтому нужна была для этого всего база данных, “экзокортекс”. База данных (свежий ещё термин в 80х) как раз и должна была быть такой памятью о клиенте.
Дальше для целей маркетинга и взаимодействия с клиентами развивались content management systems (CMS), монстрообразные системы сначала просто документооборота, которые главным образом хранили документы – в том числе договорную документацию по каким-то клиентам, но могли хранить и протоколы совещаний и всё остальное, что касалось продаж и маркетинга. Но потом это стало content management, перестало быть document management, ибо маркетинг часто и с картинками работал, и с видео и даже потом вебсайты там уже были с середины 90х. Но вот в CMS не было ориентации на клиента, скорее это была ориентация на “неопределённо широкий круг лиц”. Деньги были большие, но, как любил подчёркивать Jensen Huang, самые большие деньги – в специализации. Никому не нужны “чипы для искусственного интеллекта”, но вот “чипы для серверов в датацентрах”, “чипы для видеоигр”, “чипы для обработки медицинских изображений” – это совсем другое дело, хотя это всё один и тот же чип, только в немного другой обёртке. Content management system была роленезависимой, она не была настроена на какое-то “путешествие”, на то, чтобы быть internal development platform для какой-то внешней или внутренней роли (stakeholder), например, для роли customer – причём особенность в том, что агента для этой роли customer надо было поймать, затем обучить роли, затем удержать, затем доить вечно (ой, что это я такое пишу? У маркетинга же нейтральный язык, там даже спам называют не спамом, а direct marketing. Тут это “обеспечивать лояльность и повторные покупки по линиям cross-sale и up-sale”).
Эта база данных для database marketing и relationship marketing, которая по виду, цвету, запаху и архитектуре ничем не отличалась от типичной CMS системы, но имела в схеме данных и своих отчётах главную сущность customer, получила с середины 90х название customer relationship management, CRM – новый класс информационных систем (который, конечно, ни разу не был новым) для служб продаж. Это была не столько менеджерская или айтишная идея, сколько айтишный “голимый маркетинг” своих “универсальных баз данных” с какой-то моделью данных событий, происходящих в ходе account-based marketing и account management. Account – это как раз реестр данных о контактах с клиентом. Там и контакты клиента для связи с ним – ах, ещё одно значение слова “контакт” (кроме места контакта и процесса контакта): “адрес канала клиента”, а канал (и даже омниканальность) мы уже определяли в этой серии постов. Этот account-based marketing cам по себе отдельная методология маркетинга – Account-based marketing - Wikipedia. И вот в 1993 году Tomas Siebel покинул Oracle Corporation, чтобы основать Siebel Systems, которая стала одним из ведущих поставщиков программного обеспечения CRM. Компания Siebel сыграла значительную роль в популяризации этого термина. Примерно в это же время другие компании-разработчики корпоративного программного обеспечения, такие как SAP и Oracle, также начали разрабатывать и продвигать решения CRM, главным образом для служб продаж (а не для использования всеми остальными службами с их touchpoints).
И тут приходит experience management, который говорит, что клиент взаимодействует не только со службой продаж, но и с результатами работы чуть ли не всех служб компании, и речь идёт не только о ключевых клиентах, но и вообще всех клиентах, и всю информацию по самым разным местам контакта и взаимодействиям надо собрать и накопить – мы должны иметь базу данных по впечатлениям (eXperience), которая будет использоваться всеми (platform, а не просто какая-то там system). Родился термин customer eXperience platform-- погуглите, у всех провайдеров есть своя страничка рассказа, что это такое. И вот тут огромное разнообразие похожих продуктов – кто-то продавал journey management как internal engineering platform, и был крайне успешен. Там главный объект – это journey map, список touchpoints, проектирование маршрута по этой map, кастомизация маршрута. Такой вот issue tracker и методолог, который вещает, как бы нам организовать обработку непослушных клиентов. Почему Platform? Потому что CRM и прочие “менеджменты” предполагалось использовать в рамках какого-то одного подразделения, а вот platform – бери выше, это для всего предприятия, полный конвейер “от и до”, для всех служб. Internal development plaftform, только по конвейеру идёт путешествие customer.
CXP имеет особенность: там важен сбор откликов того, что происходит с клиентом, главное там не journey, а тот самый experience – съём показателей. Конечно, внутри там вполне себе нормальный движок для customer journey management, но акцент всё-таки на outcome: надо знать, какие там у клиентов впечатления, какова их лояльность – и где там на маршруте возникают проблемы. А у CJM движков как “процессных движков”, issue trackers – всё в порядке с eXperience, но задачи такие другие. И иногда одной системы хватает, а иногда не хватает. А иногда они используются так, что клиент взвывает – и уходит куда-нибудь туда, где к нему не подскакивает каждые 10 секунд очередной робот со словами “чем могу помочь, не заполните ли вы наш опросничек?” (см. ещё раз про иммунный ответ на маркетинг Иммунный ответ мокрой нейросетки на "маркетинг": ailev — LiveJournal).
Digital eXperience platform
Touchpoints согласно общей концепции customer experience оказались не только ловушками для завлечения и в конечном итоге продажи, но с учётом общей концепции customer eXperience как “все места контакта” ещё и с переходом на сервис-ориентированную экономику (об этом чуть позже) и цифровые сервисы – местами оказания услуг. И был сделан последний шаг: CXP как customer eXperience platform становится DXP – digital eXperience platform, и там уже create, manage, optimize, and deliver seamless and consistent digital customer experiences across multiple channels and touchpoints. Вот тут один из многочисленных списков “десятки лучших” DXP, на июнь 2024 – https://expertinsights.com/insights/the-top-digital-experience-platforms-dxp/
Но eXperience у программистов становится больше “взаимодействием” (interaction), которое хорошо протоколируется – ибо “впечатление” маркетологов не запротоколируешь. Но, понятно, это “великолепные взаимодействия/experiences”, которые маркетологи трактуют как “великолепные впечатления/epxerience” – и все счастливы.
Customer и digital при этом заменяется на что угодно. Например, Dassault Systemes выпускала:
– PDM систему (product data management – идея перевого поколения системного мышления: собрать все данные, тогда это были главным образом чертежи с выходом на сводно-заказную спецификацию о продукте). У Dassault Systemes это была ENOVIA PDM, 1998 год (и это было приобретение продукта, никакой особой интеграции с CAD от Dassault Systemes даже не было).
– PLM систему (product lifecycle management – идея, что кроме данных о продукте надо собирать данные о создателях, не только то, что там с системой, но и кто что делал с системой. До полного жизненного цикла так и не добрались, но хотя бы стадию проектирования закрыли – обслуживался водопад, постадийно, каждая стадия – своим видом систем). Это было буквально через год-другой после старта PDM – в 1999-2000 годах, ENOVIA как PLM Solution. Помним, что PLM формально определяется как “база данных, в которой кроме данных о продукте лежат ещё какие-то данные”, и там лежали данные о создателях – кто что с этими описаниями продукта делал, там внутри был issue tracker, то есть “данные о работах”, это было главное отличие.
– DXP систему (digital experience platform) Dassault Systemes запустила в 2012, это была 3DEXPERIENCE. Слоган там был – integrating all aspects of a business into a single platform. Но слоган для PLM системы был для большинства инженеров неотличим: данные о продукте и всём остальном, что происходит. Что же было нового по сравнению с ENOVIA? То, что окончательно перешли от 2D проектирования к 3D проектированию? It provides a holistic, real-time view of business activity and ecosystem, fostering innovation and collaboration not just within engineering teams but across the entire organization, including marketing, sales, and external partners. The platform enables companies to create unique customer experiences by leveraging virtual universes to simulate and optimize products and processes before actual production. – то есть мы видим ровно реализацию тренда customer experience management, в которой идеи “из маркетинга” съели инженеров с их PLM и эккаунт-менеджеров с их CRM как небольшую часть. Если вспомнить, чем там хвасталась Dassault Systemes при запуске своей DXP, так это всякими интеграциями вовне фирмы: и как выложить информационную модель для какого-то каталога комплектующих, и как показать виртуальную модель изделия клиентам, и как подключить каких-то внешних инженеров. Все это понятно объяснялось через touchpoints и каналом, по которому шли и документировались взаимодействия, тут выступала как раз 3DEXPERIENCE platform. Инженеры традиционнно это называли “интеграциями”, рассматривая только часть проблемы с “интеграцией разных софтов”. Но для “бизнесОв” это был связный рассказ о том, как платформа фирмы Dassault Systemes помогает им в customer experience design. И деньги на покупку выделялись много проще, эти объяснения были понятны главным образом менеджерам, которым важно было не только произвести, но и продать.
These developments reflect Dassault Systèmes’ commitment to evolving their software solutions to meet the changing needs of engineering and enterprise environments, from managing product data to encompassing the entire product lifecycle and delivering comprehensive digital experiences – инженеры дочитывали до слова delivering и дальше ничего уже не понимали. Правильно не понимали, слово experience пришло по линии маркетинга.
DXP можно рассматривать и как “связку PLM для продукта с CRM” и как “связку CRM с PLM для продукта” и заодно потом как поддержку каталога продуктов или сервисов, и выход на биллинг, и выход на колл-центр, и даже выход на рекламу. Были бы продукты и сервисы (их много) и были бы клиенты (их много), а далее надо учесть все их взаимодействия/experiences, чтобы эти впечатления/experiences превосходили ожидания, то есть были позитивными. И да, эти впечатления надо бы оценить и записать.
Это транслировалось в самые разные бизнесы, например, LMS (learning management system, аналог PLM для обучения, Learning Management Systems | Expert Insights) по большей части тоже пытались перейти к LXP (learning eXperience platform). Но в вузах и даже корпоративных университетах, где использовались LMS, идеи маркетинга и экономики впечатлений (о чём позже) были не очень распространены, поэтому к LXP перешли не все поставщики LMS. Некоторые вендоры хотели сохранить название типа LMS, им не надо было интегрироваться по захвату данных всего учебного заведения и не надо было напирать на то, что у каждого студента learning journey уникально, а не представляет собой универсальный для всех предписанный учебным планом “водопад”. Маркетинг LXP шёл поэтому не по линии CRM (привлечь ученика/learner, хотя для онлайн-провайдеров обучения это оказалось ключевым – объединение LMS и CRM), не по линии интеграции данных по всем experience в понимании айтишников, то есть experience как процесс, а не как впечатления от процесса. С LMS процесс добавления новых видов данных от разных touchpoints в хранимые данные шёл медленно, а затем время от времени разные поставщики таких систем и сервисов делали ребрендинг их как LXP, но этот новый тип системы поддержки learner journey заявляли не все поставщики. А уж если там внутри было что-то с “искусственным интеллектом” и “большими данными”, то тут чаще всего и отказывались от термина LMS и переходили к platform, то есть LXP. Вот списочек 20 таких платформ – The 20 Best Learning Experience Platforms (LXPs) in 2024. Табличка по этой ссылке показывает, что content management как ключевое для LMS с ориентацией LMS на работников учебного заведения заменился experience management, та самая “клиентская ориентация” – только клиентом тут learner.
Не забываем про employee, где всё то же самое, про community member, и даже про user (который сегодня понимается и как связанный с ролью customer на стадии эксплуатации, и как community member). Везде мы наблюдаем что-то похожее: есть journey, которое раньше понималось как “проход по маршруту”, потом оказалось, что там “брожение между павильонами на выставке – путешествие, а маршрут определяется не только нами, павильоны не только наши, а ещё надо, чтобы агент был доволен”, и всё это хорошо бы спроектировать, а потом отследить для каждого человека.
Дальше этот тренд, конечно, перешёл к data-driven enterprise, big data analytics, а маркетинг там не по-старинке database marketing, а сразу big data marketing, AI-driven marketing, иногда отдельно продают analytics (а уж управлять – это вы сами как-нибудь), и т.д. Но это всё про айтишников, а мы тут про идеи из области клиентоориентированности, которые айтишники исправно обслуживали, чтобы о них сложились хорошие впечатления (pun intended). Рассуждения по линии менеджмента и маркетинга, затрагивающие общую организацию работы с клиентом не так уж сильно меняются от того, что бизнес “ушёл в онлайн”. Все эти механизации, автоматизации, цифровизации, интеллектуализации, роботизации – да, конечно, слова меняются. Но что там outcome и что там process для клиента таки придётся обсудить – независимо от того, какая там роль информационно-коммуникационных технологий и через какой интерфейс получает информацию клиент о компании (или, симметрично – через какой интерфейс получает компания информацию о клиенте).