Оператор берёт трубку. Пока говорит с клиентом, он держит открытыми четыре окна: CRM, телефонию, почту и таблицу с заявками. Номер клиента живёт в телефонии, история покупок - в CRM, договор - в папке на диске, статус заявки - в таблице. Человек копирует данные из одного окна в другое и всё равно переспрашивает клиента о том, что уже спрашивал кто-то другой.
Рано или поздно приходит мысль: собрать всё это в один экран. Мысль верная, и дело не в красивой картинке: важно, откуда окно берёт данные, кто из систем считается главным и что делать, когда две системы отвечают по-разному. Ниже - разбор, когда один экран окупается, а когда за него не стоит платить.
Пример того, как рабочий экран оператора устроен в проекте, - в кейсе платформы для банков, который мы спроектировали. По проекту оператор видит всю историю по должнику в одном окне: кто звонил, что обещали, когда следующий контакт.
Что такое «одно окно» и чего оно не делает
Коротко: одно окно - рабочий экран, куда сведены данные из нескольких систем. Это не отчёт для начальника и не замена самим системам.
Одно окно (единое окно, рабочий экран оператора) - это интерфейс, который показывает данные из нескольких систем на одном экране, без переключения между вкладками. Системы при этом никуда не исчезают. CRM продолжает хранить клиентов, телефония - записи разговоров, учётная система - документы. Окно только читает их и показывает нужное в одном месте.
Отчёт решает другую задачу. Он отвечает на вопрос «как у нас дела» и нужен руководителю раз в день. Рабочий экран отвечает на вопрос «что мне сделать прямо сейчас по этому клиенту» и нужен оператору каждую минуту. Витрину показателей для руководителя мы разбирали в статье про дашборд отдела продаж - это другая задача, хотя данные у неё и у окна бывают общие.
И окно не заменяет системы, которые под ним. Соблазн «давайте всё перенесём в одно место и выключим лишнее» почти всегда заканчивается дорого: работающие системы придётся переписывать, а данные - переносить с рисками. Окно решает задачу чтения, а не хранения.
Как понять, что оператору правда нужен один экран?
Коротко: считайте переключения за смену и потери контекста. Число систем тут ни при чём, и если человек редко заходит в соседнюю систему, окно ему не нужно.
Начните с наблюдения. Техническое задание подождёт. Посчитайте, сколько раз за смену оператор переключается между системами и сколько раз переспрашивает клиента о том, что уже есть в записях. Это и есть цена, которую вы платите сейчас.
Тревожные признаки выглядят так. Человек держит открытыми больше трёх систем одновременно. Он копирует номер клиента из телефонии в CRM руками. Он переспрашивает, о чём договорились в прошлый раз, потому что история разговоров лежит отдельно от карточки. После звонка он идёт в третью систему проставлять статус.
Есть и спокойные признаки, при которых окно не окупится. Оператор заходит в соседнюю систему раз-два за день. Данные из разных мест нужны разным людям, каждому по отдельности. Переключения редкие, потому что задачи редкие.
Когда одного окна не нужно и хватит выгрузки?
Коротко: если вопрос «как у нас дела» встаёт раз в день, дешевле сводный отчёт или выгрузка.
Не всякую боль лечит разработка. Если данные из нескольких систем нужны руководителю для решения раз в день или раз в неделю, то сводный отчёт закрывает задачу за малую часть стоимости окна. Тот же результат даёт выгрузка в таблицу: она некрасивая, но вопрос «сколько заявок без ответа» решает.
Окно оправдано там, где данные нужны в момент разговора. Оператор говорит с клиентом сейчас и хочет видеть его историю сейчас. Отставание на день здесь недопустимо, потому что за день клиент успевает позвонить снова и получить другую версию ответа.
Скажем прямо: иногда самое честное решение - сначала навести порядок в двух системах. Если половина данных дублируется вручную, а статусы расходятся, стоит договориться, какая запись верна. Иначе окно покажет вам весь этот беспорядок, только на одном экране.
Какие данные попадают в окно оператора?
Коротко: карточка клиента, история контактов, текущий статус, документы и следующий шаг. Всё остальное держите по ссылке в исходной системе.
Не тяните в окно всё, что есть в системах. Экран, забитый полями, работает хуже, чем четыре отдельных окна: оператор снова ищет нужное, только теперь взглядом. Разумный минимум выглядит так.
- Карточка клиента и его контакты.
- История обращений: кто звонил, когда, чем закончилось.
- Текущий статус по сделке или заявке.
- Документы, которые нужны в разговоре: договор, счёт, заявка.
- Следующий шаг: что оператор должен сделать по этому клиенту.
Остальное - детали, редкие поля, длинные справочники - лучше оставить по ссылке, которая открывает запись в исходной системе. Так экран остаётся читаемым, а система хранения - прежней.
Если вы решаете задачу с данными из нескольких систем, опишите задачу - разбираем требования до конца, состав работ и смету присылаем за 24 часа.
Что такое мастер-система и почему без неё будет две правды
Коротко: мастер-система - источник, чьи данные считаются верными. Без неё окно покажет разные ответы на один вопрос.
Данные об одном клиенте обычно живут в нескольких местах. Телефон есть и в CRM, и в телефонии. Статус заявки - в таблице и в CRM. Документ - в учётной системе и в папке. Пока вы смотрите в одну систему, вопросы не возникают. Как только окно показывает данные из двух систем рядом, становится видно, что они расходятся.
Мастер-система (система-источник, система-владелец записи) - это та, чьи данные считаются верными по конкретному полю. Телефон берём из телефонии, потому что он фиксируется в момент звонка. Статус заявки - из CRM, потому что там его меняет оператор. Договор - из учётной системы, потому что он там подписывается.
Правило задаётся по каждому полю отдельно. Одна и та же CRM может быть главной для статуса и не главной для телефона. Без такого правила окно честно покажет вам оба варианта - и оператор сам решит, какому верить. Это и называется «две правды на одном экране».
Что делать, когда данные в двух системах расходятся?
Коротко: правило «кто главный» для каждого поля, журнал расхождений и человек, который разбирает спорные.
Расхождения не исчезают после сборки окна. Они были и раньше, просто их никто не видел, потому что данные лежали в разных местах. Когда системы показывают одно рядом с другим, расхождения становятся заметны, и это скорее плюс.
Порядок такой. Сначала вы записываете, какое поле в какой системе главное. Дальше окно показывает по каждому полю только значение из главной системы. Если значение в другой системе отличается, окно помечает расхождение и не пытается вывести среднее.
Потом кто-то должен эти расхождения разбирать. Обычно это ответственный за данные: он смотрит спорные случаи и решает, где ошибка. Без человека в этой роли окно накапливает расхождения молча, и через месяц никто не скажет, какие данные верные.
Почему «выгрузка раз в сутки» и «реальное время» - разные экраны?
Коротко: свежесть задаёт источник. Без способа спросить систему напрямую окно честно покажет данные на вчера.
Свежесть окна задают системы, из которых оно берёт данные. Если система умеет отвечать на запросы в момент обращения (это и есть API), окно покажет данные сейчас. Если система отдаёт данные только ночной выгрузкой, окно покажет то, что было вчера вечером.
Отсюда практический вывод. Прежде чем обещать «реальное время», проверьте, может ли каждая система отвечать на запросы. Часто выясняется, что половина систем умеет отвечать на запросы, а вторая - старая учётная программа, которая умеет только выгрузку раз в сутки. Тогда часть окна будет свежей, а часть - вчерашней, и это надо честно показать оператору.
Что значит «сейчас, а не завтра утром», видно в кейсе аналитики интернет-магазина, который мы сделали в продакшене.
Как окно достаёт данные и от чего зависит свежесть
Коротко: способов три, и различаются они свежестью. Выбор зависит от того, что умеют ваши системы.
Первый способ - окно спрашивает систему в момент обращения. Это самый свежий вариант, но система должна уметь отвечать на вопросы.
Второй - система отдаёт данные по расписанию, раз в час или раз в сутки. Так работают старые учётные программы: данные всегда с задержкой.
Третий - система сама сообщает об изменении: заявка закрыта, оплата прошла. Окно узнаёт сразу, но умеют так не все системы.
На практике окно собирают из всех трёх сразу. Важно другое: не обещать оператору свежие данные там, где система отдаёт их раз в сутки. Как связывают системы между собой, мы разбирали на примере интеграции Битрикс24 с 1С.
Своё окно, доработка текущей CRM или готовый сервис?
Коротко: три пути расходятся по контролю над данными, свежести, связи с системами и ответственности за расхождения.
Прежде чем писать код, стоит понять, куда вы идёте. Разница в том, кто отвечает за результат и насколько окно подстроено под ваши системы.
| Критерий | Своё окно | Доработка текущей CRM | Готовый сервис |
|---|---|---|---|
| Контроль над данными | Полный: данные живут у вас | Внутри CRM, часть полей закрыта | У поставщика сервиса |
| Свежесть | Какая нужна от систем | Что умеет CRM | Зависит от тарифного плана |
| Связь со своими системами | Любые, включая старые | Только то, что поддерживает CRM | Обычно по готовым коннекторам |
| Кому подчиняется вид экрана | Вам | Логике CRM | Шаблону сервиса |
| Кто отвечает за расхождения | Ваш подрядчик | Иногда вендор CRM | Сервис, в пределах тарифа |
Выбор между готовой CRM и своей разработкой мы разбирали отдельно в статье про разработку CRM на заказ. Здесь важен другой вопрос: если системы уже работают, чаще дешевле построить окно поверх них, чем менять сами системы.
Таблица решения: одно окно, сводный отчёт или выгрузка руками
Коротко: три пути по одинаковым критериям - сколько систем, как часто переключается человек, готовы ли системы к связи.
| Признак | Сводный отчёт | Выгрузка руками | Одно окно |
|---|---|---|---|
| Как часто нужны данные | Раз в день или реже | Редко, для разбора | В каждом обращении |
| Сколько систем | Одна-две | Одна | Три и больше |
| Кто смотрит | Руководитель | Аналитик | Оператор |
| Готовы ли системы отдавать данные | Через выгрузку | Через файл | Через API или события |
| Что делать при расхождении | Заметить в отчёте | Разобрать вручную | Нужна мастер-система |
Если вам подходит первый или второй столбец, окно вам пока не нужно. Это экономия, а не отказ от задачи.
Как проверить, что окно показывает правду
Коротко: сверяйте окно с системами-источниками на наборе известных случаев.
Приёмка окна - это сверка. Демонстрация ничего не доказывает. Заранее возьмите набор клиентов или заявок, по которым вы точно знаете, как должно быть. Например, десять заявок с разными статусами и два клиента, у которых менялся телефон.
Дальше сверяете окно с системами по каждому случаю. Совпадает ли статус со статусом в CRM. Тот ли телефон, что в телефонии. Появился ли документ из учётной системы. Показывает ли окно расхождение там, где вы его специально оставили. Если всё совпало на известных случаях - окно можно принимать.
Отдельно проверьте свежесть. Заведите тестовую запись и измените её в системе-источнике. Окно должно показать изменение в тот срок, который вы заложили в требования: сразу, через час или на следующее утро. Если окно показывает свежие данные только у разработчика на демонстрации, а на ваших системах нет - это и есть главный риск приёмки.
Что записать в задачу подрядчику
Коротко: список систем и их владельцев, какие данные нужны, где мастер-запись, свежесть по каждому полю и критерии приёмки.
Задача на окно без этих пунктов превращается в долгий спор, потому что каждый понимает «всё в одном месте» по-своему. Впишите в неё следующее.
- Список систем, из которых берём данные, и кто отвечает за каждую на вашей стороне.
- Какие данные нужны оператору на экране, а какие остаются по ссылке.
- Для каждого поля - какая система считается главной.
- Свежесть по каждому источнику: сейчас, раз в час или раз в сутки.
- Что окно делает при расхождении: помечает, скрывает или показывает оба значения.
- Как принимается работа: набор известных случаев и способ проверить свежесть.
Когда эти пункты записаны, подрядчик может назвать состав работ и срок. Это ровно то, чего мы добиваемся на разборе требований: у каждого пункта появляется критерий приёмки, и цена фиксируется до первой строки кода.
Что ломается на практике
Коротко: чаще всего ломается доверие к экрану. Один раз показал вчерашнее - оператор вернулся к старым окнам.
Первое, что ломается, - привычка. Окно меняет работу: раньше оператор держал контекст в голове, теперь он должен доверять экрану. Если экран хоть иногда показывает неверное, доверие уходит быстро, и человек возвращается к старым окнам. Поэтому проверка свежести и расхождений не заканчивается приёмкой, её нужно вести постоянно.
Второе - ожидания. Само по себе одно окно оператора не ускоряет. Оно убирает переключения и потери контекста. Если проблема была в другом - в мотивации, в скриптах, в лишних этапах согласования - окно её не решит, а деньги и время уйдут. Иногда выясняется, что задача решается без всякой разработки и втрое дешевле, и это тоже результат.
Источники
- Microsoft Learn. «Overview of Copilot Service workspace» - https://learn.microsoft.com/en-us/dynamics365/contact-center/use/ccw-overview
- Microsoft Learn. «Gateway Aggregation pattern» (Azure Architecture Center) - https://learn.microsoft.com/en-us/azure/architecture/patterns/gateway-aggregation
- Microsoft Learn. «Describe unified customer profiles» (Dynamics 365) - https://learn.microsoft.com/en-us/training/modules/describe-sales-account-management-dynamics-365/3-describe-unified-customer-profiles
- Microsoft Learn. «Batch vs. streaming data processing» (Azure Databricks) - https://learn.microsoft.com/en-us/azure/databricks/data-engineering/batch-vs-streaming
- AWS Prescriptive Guidance. «Integrating microservices» - https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-integrating-microservices/introduction.html
- MDN Web Docs. «Push API» - https://developer.mozilla.org/en-US/docs/Web/API/Push_API
- Hohpe G., Woolf B. «Enterprise Integration Patterns» - https://www.enterpriseintegrationpatterns.com/
- IBM. «What is Single Pane of Glass?» - https://www.ibm.com/think/topics/single-pane-of-glass
- IBM. «What is a System of Record?» - https://www.ibm.com/think/topics/system-of-record
- IBM. «What is Master Data Management?» - https://www.ibm.com/think/topics/master-data-management
- Google Cloud. «Manage data freshness» (Looker Studio) - https://docs.cloud.google.com/looker/docs/studio/manage-data-freshness
- Habr. «Интеграция без боли: как мы надстроили "зонтик" над 40 существующими источниками данных в энергетике» - https://habr.com/ru/articles/1009776/
- Habr (Magnit Tech). «Лучшие практики при работе с мастер-данными» - https://habr.com/ru/companies/magnit/articles/728676/
- IIBA. «BABOK Guide» (стандарт бизнес-анализа) - https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/
Если задача похожа на вашу, опишите задачу - пришлём состав работ и смету за 24 часа. Про то, как мы разбираем требования до первой строки кода, есть страница проектов.