Кейс, который мы рассмотрим, целиком придуманый и во многом упрощённый, данные я сгенерировала случайным образом, специально заложив туда некоторые закономерности. Но, на мой взгляд, он хорошо отражает класс реальных задач, с которыми сталкиваются аналитики и для решения которых можно использовать алгоритм Δλ.

Предположим, что к аналитику поступает вот такой датасет и запрос «Проанализировать ситуацию с очередями в отделениях Банка».

Наш специалист запрашивает описание полей и получает информацию о каждом:

После чего он готов приступать к созданию дашборда, на котором будет графиками отвечать на вопросы заказчика. Заказчик, в свою очередь, скорее всего попросит вывести среднее время ожидания по всем отделениям, список отделений с самыми большими очередями. Возможно, он ещё захочет понять, в какое время чаще всего появляются очереди. Чтобы дашборд не выглядел пустым, решено будет добавить на него карту с отделениями. Получится что‑то в этом роде:

Этот дашборд вроде бы освещает тему очередей и отвечает на вопросы заказчика. Но по факту является совершенно бесполезным: на нём видна средняя температура по больнице, какие‑то общие значения, которые не позволяют ответить на главные вопросы: где в пространстве и во времени локализована проблема с очередями, почему они возникают и как можно на них повлиять с точки зрения бизнеса.

Я убеждена, что применение алгоритма Δλ в целом и описание реальности данных в частности качественно меняет глубину погружения в задачу и результат. Давайте попробуем описать реальность данных для этого кейса.

Напомню, что реальность данных — это совокупность процессов, порождающих данные. Начнём с «приземления», то есть с описания контекста.

Одной фразой мы сформулировали и где происходит дело, и каким образом собраны данные, которые мы будем визуализировать. Пришло время добавить действующих лиц и глаголов действия.

Когда мы думаем о посетителях, которые приходят в отделение банка, мы уже не можем развидеть, что у них есть цель, задача, которую они хотят решить — или несколько. Но в данных это никак не отражено? Почему? И нельзя ли добавить в датасет информацию по типу услуги?

Дальше опишем то, что происходит после того, как посетитель пришёл в банк.

Реальность данных подсветила ещё две важные сущности: окно и оператор. Не факт, что они обязательно должны добраться до дашборда, но факт в том, что количество доступных окон и скорость работы операторов напрямую влияет на размер очереди и время ожидания.

О чём ещё мы не сказали? Если мы действительно вообразим ситуацию в очереди, то поймём, что часть клиентов не дождётся приглашения. На одном из курсов участница сформулировала этот момент очень выразительно и метко: «Клиент получает услугу. Или не дожидается, бранится и уходит.» Вот это классная работа с реальностью данных (Даша, привет!) Но давайте скажем покороче.

Сейчас в данных у нас совсем нет об этом информации, но её можно понятным образом получить, если посчитать талоны со статусом «Обслужен».

Соберём все кусочки воедино:

В этих четырёх предложениях датасет оживает, мы оперируем не полями, а сущностями, которые понятным образом связаны друг с другом и влияют друг на друга. Это только первый шаг, но, пройдя его, мы совсем иначе смотрим на данные. А ещё запросили у заказчика и получили расширенный датасет:

Благодаря реальности данных мы будем визуализировать более целостную, полную и многогранную картину.