Инструменты методики АЦТ, часть 44: обработка данных в реальном времени (Real-Time Data Processing), периферийные вычисления (Edge Computing), добыча данных (Data Mining) и добыча процессов (Process Mining)

Это сорок четвертая статья цикла по инструментам методики «Аккордная цифровая трансформация». Завершаем группу H «Данные и аналитика» подгруппой H3 «Обработка данных» — инструменты H3-01, H3-02, H3-03 и H3-04.

Четыре инструмента этой статьи завершают группу H и показывают, с какой скоростью и в какой точке данные становятся доступными для анализа, а также какую информацию из них можно извлечь. Обработка данных в реальном времени (H3-01) сокращает задержку между получением данных и реакцией на них до минимума. Периферийные вычисления (H3-02) переносят обработку ближе к источнику данных, минуя передачу в центр. Добыча данных (H3-03) выявляет в накопленных массивах закономерности, неизвестные заранее. Добыча процессов (H3-04) представляет собой специализированную форму добычи данных и восстанавливает по цифровым следам в системах фактический ход бизнес-процессов. Трудоемкость составляет 40 часов у обработки в реальном времени и периферийных вычислений, 48 часов у добычи данных и 54 часа у добычи процессов — самого трудоемкого инструмента всей группы H. В сумме — 182 часа.

H3-01 — Обработка данных в реальном времени (Real-Time Data Processing, RTD)

Откуда появился инструмент. Первой коммерческой системой, обрабатывавшей данные в реальном времени в масштабе целой отрасли, стала SABRE — система бронирования авиабилетов, которую с 1953 года разрабатывали American Airlines и IBM. Предпосылкой к ее созданию стал случайный разговор президента авиакомпании Сайруса Смита и торгового представителя IBM Блэра Смита, оказавшихся рядом на одном рейсе. Они обсуждали, что ручное бронирование билетов занимало до девяноста минут на одно место. Формальное сотрудничество началось в 1957 году, а в основу системы легли наработки военного проекта SAGE — системы противовоздушной обороны, впервые применившей обработку данных в реальном времени для слежения за воздушным пространством. К 1964 году SABRE заработала в полном объеме на двух мейнфреймах IBM 7090, обслуживая терминалы по всей стране.

Суть и механика. Обработка данных в реальном времени — процесс анализа и интерпретации данных с минимальной задержкой после их получения. В отличие от традиционной пакетной обработки, когда данные собираются, сохраняются и обрабатываются в отведенное время, RTD позволяет оперативно реагировать на изменения в бизнес-процессах, оптимизировать управление ресурсами и принимать обоснованные решения на основе актуальной информации.

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

Практический эффект перевода операции из отложенного режима в режим реального времени хорошо показывает система, с которой связано становление этого подхода.

Пример. До появления SABRE оформление одного бронирования занимало у сотрудника авиакомпании до девяноста минут: требовалось вручную сверить наличие мест по бумажным карточкам маршрутов и связаться с другими подразделениями по телефону. Разработка системы обошлась в 40 млн долларов — сумму, эквивалентную нескольким сотням миллионов долларов сегодня. К середине 1960-х годов SABRE обрабатывала 7500 бронирований в час, а время оформления одной брони сократилось с полутора часов до нескольких секунд. Вице-президент IBM Т. Винсент Лирсон описывал произошедшее так: система переносит вычислительную машину и все ее возможности за пределы комнаты, в которой она находится, размещая ее фактически рядом с каждым сотрудником, оформляющим бронирование.

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

Границы применимости. Инструмент применим там, где ценность решения напрямую зависит от скорости реакции на поступающие данные: в управлении запасами, обслуживании клиентов, мониторинге оборудования. По методике это сложный инструмент.

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

Обработка данных в реальном времени опирается на периферийные вычисления (H3-02) как на способ сократить задержку передачи данных и поставляет исходный поток для добычи данных (H3-03).

Чек-лист перед внедрением обработки данных в реальном времени:

• Определены решения, для которых задержка реакции критична, и оценена стоимость промедления в каждом случае.

• Оценена готовность вычислительной инфраструктуры к постоянной, а не периодической нагрузке.

• Установлен порядок фильтрации и предобработки данных, совместимый с требуемой скоростью реакции.

• Проверено, что качество источников данных достаточно для решений, принимаемых без длительной проверки.

• Определены показатели, по которым измеряется фактическое сокращение задержки между событием и реакцией.

• Оценена соразмерность задачи: действительно ли требуется реакция в реальном времени, а не периодическое обновление.

Типовые ошибки:

• Реальное время там, где не требуется. Систему строят для задач, где было бы достаточно периодического обновления. → Оценивать соответствие скорости реакции реальной потребности задачи.

• Недостаточная проверка входных данных. Скорость обработки достигается за счет сокращения контроля качества данных. → Встраивать проверку данных в сам процесс с сохранением требуемой скорости.

• Инфраструктура без резерва. Система рассчитана на обычную нагрузку и не выдерживает пиковых значений. → Закладывать запас мощности на случай всплесков нагрузки

• Отсутствие измерения задержки. Систему внедряют, не отслеживая фактическое сокращение задержки. → Устанавливать конкретные показатели задержки и контролировать их после внедрения.

H3-02 — Периферийные вычисления (Edge Computing)

Откуда появился инструмент. Подход зародился в 1998 году, когда профессор Массачусетского технологического института Том Лейтон и его аспирант Дэнни Левин искали решение проблемы перегрузки интернета: сайты, размещенные на одном центральном сервере, замедлялись до неприемлемого уровня при резком росте числа обращений. Основанная ими компания Akamai в 1999 году запустила сеть серверов, размещенных по всему миру ближе к конечным пользователям, — так называемых периферийных серверов, кэширующих содержимое сайта и доставляющих его из ближайшей точки вместо единственного удаленного источника.

Идея обработки данных ближе к месту их возникновения впоследствии получила отдельное название — периферийные вычисления. С распространением интернета вещей подход стал применяться далеко за пределами доставки веб-контента, в том числе на производстве.

Суть и механика. Периферийные вычисления — подход к обработке данных, при котором большая часть вычислений выполняется максимально близко к источнику их появления, «на краю сети». В отличие от традиционных облачных вычислений, где данные отправляются в централизованные дата-центры, Edge Computing позволяет обрабатывать информацию локально, непосредственно на устройствах или вблизи них.

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

Пример. Обзор внедрений периферийных вычислений на нескольких производственных предприятиях показал, что задержка обработки данных сократилась с типичных для облачной архитектуры 150–200 миллисекунд до в среднем 15 миллисекунд. Такое сокращение особенно важно для задач с жесткими требованиями к скорости реакции: управления роботизированными манипуляторами, контроля качества методом машинного зрения и защитных блокировок оборудования, где требуются задержки на уровне миллисекунд. Наибольший эффект такие внедрения показали в дискретном производстве, где требования к скорости реакции на отклонение особенно жесткие.

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

Границы применимости. Инструмент применим там, где задержка передачи данных в центр обработки недопустима для самой задачи: в управлении роботизированным оборудованием, системах безопасности, контроле качества в реальном времени. По методике это сложный инструмент.

Первое ограничение — стоимость распределенной инфраструктуры: вычислительные мощности приходится размещать в каждой точке сбора данных, а не в одном центре, что увеличивает совокупные затраты на оборудование. Второе — ограниченность локальных ресурсов: устройства на периферии обычно уступают по вычислительной мощности централизованным дата-центрам, что ограничивает сложность задач, решаемых на месте. Третье — согласованность с центральной системой: данные, обработанные на разных периферийных узлах, впоследствии необходимо сводить в общую картину, а рассогласование между узлами создает новый вид ошибки, отсутствовавший при централизованной обработке.

Периферийные вычисления служат инфраструктурной основой для обработки данных в реальном времени (H3-01) и опираются на облачные вычисления (G3-01) как на дополняющую архитектуру.

Чек-лист перед внедрением периферийных вычислений:

• Определены задачи, для которых задержка передачи данных в центр критична для результата.

• Оценена стоимость размещения вычислительных мощностей в каждой точке сбора данных.

• Проверено, достаточно ли вычислительной мощности периферийных устройств для решаемых на них задач.

• Установлен порядок сведения данных с разных периферийных узлов в единую согласованную картину.

• Определено разделение задач между периферией и центром: что решается локально, а что передается дальше.

• Предусмотрен план обслуживания и обновления распределенной инфраструктуры на местах.

Типовые ошибки:

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

• Недооценка ограниченности локальных ресурсов. На периферийные устройства возлагают задачи, для которых их мощности недостаточно. → Проверять соответствие мощности устройства сложности задачи.

• Рассогласование между узлами. Данные с разных периферийных точек не сводятся в общую картину. → Устанавливать порядок согласования данных между узлами и центром.

• Отсутствие плана обслуживания. Распределенную инфраструктуру внедряют без заранее установленного порядка ее обновления и ремонта на местах. → Планировать обслуживание периферийных устройств до внедрения.

H3-03 — Добыча данных (Data Mining, DM)

Откуда появился инструмент. В 1989 году специалист по анализу данных Григорий Пятецкий-Шапиро предложил для первого профильного семинара термин «извлечение знаний из баз данных», сознательно избегая словосочетания «добыча данных». Статистики к тому моменту уже использовали его как уничижительное обозначение бесконтрольного перебора данных в поисках любых, в том числе случайных, совпадений.

Академическое сообщество приняло предложенный им термин, однако в деловой среде и прессе закрепилось словосочетание «добыча данных», которого автор первоначально старался избежать. В практической среде менее строгий термин оказался понятнее за пределами исследовательских кругов.

Суть и механика. Добыча данных — процесс извлечения полезных, ранее неизвестных закономерностей и знаний из больших объемов данных с использованием алгоритмов статистики, машинного обучения, искусственного интеллекта и баз данных.

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

Значение сегментации, сформированной на основе алгоритмического анализа данных, показывает пример перестройки работы с клиентами в игорном бизнесе.

Пример. Компания Harrah’s Entertainment, управлявшая сетью казино в США, в конце 1990-х годов под руководством генерального директора Гэри Ловмана пересмотрела принцип работы с клиентами: вместо крупных единовременных вложений в привлечение узкого круга высокостатусных игроков компания применила добычу данных к массиву сведений о поведении всех участников программы лояльности. Анализ выявил сегмент клиентов, ранее считавшихся второстепенными: людей среднего достатка, регулярно посещавших казино и игравших на небольшие суммы, чья совокупная ценность для компании оказалась выше, чем у немногочисленных крупных игроков, на которых прежде концентрировались основные усилия. Компания перестроила маркетинговые предложения под этот сегмент, и подход впоследствии описывался в деловой литературе как один из показательных примеров применения анализа данных для пересмотра сложившейся практики отрасли.

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

Границы применимости. Инструмент применим там, где накоплен достаточный объем разнородных данных, а закономерность, которую предстоит найти, не сформулирована заранее: в маркетинге, управлении качеством, обслуживании оборудования. По методике это сложный инструмент.

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

Добыча данных получает поток от обработки данных в реальном времени (H3-01) и служит основой для специализированной формы этого же метода — добычи процессов (H3-04).

Чек-лист перед внедрением добычи данных:

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

• Проверено качество и полнота исходных данных перед началом анализа.

• Предусмотрена проверка найденных закономерностей на предмет статистической случайности.

• Установлен порядок интерпретации результатов специалистом до их практического применения.

• Оценена применимость найденной закономерности к новым, еще не проанализированным данным.

• Определены показатели, по которым оценивается практическая польза от найденных закономерностей.

Типовые ошибки:

• Ложные закономерности. Найденную статистическую связь принимают за содержательный вывод без проверки. → Проверять устойчивость закономерности на независимых данных.

• Анализ без интерпретации. Результаты алгоритма применяют напрямую без анализа их содержания. → Привлекать специалиста для интерпретации найденных закономерностей.

• Анализ на некачественных данных. Закономерности ищут в неполных или искаженных источниках. → Проверять качество данных до начала анализа.

• Отсутствие практического применения. Закономерности находят, но решения на их основе не принимаются. → Связывать результаты анализа с конкретными управленческими решениями.

H3-04 — Добыча процессов (Process Mining, PM)

Откуда появился инструмент. Метод разработал нидерландский ученый Вил ван дер Аальст, начавший исследования в 1999 году в Эйндховенском технологическом университете. Занимаясь моделированием рабочих процессов, он обнаружил, что традиционные способы описания бизнес-процессов — интервью с сотрудниками и рабочие совещания — дают неполную и неизбежно субъективную картину, основанную на представлениях участников о процессе.

Ван дер Аальст предложил анализировать журналы событий, которые информационные системы формируют в ходе штатной работы, и восстанавливать по ним фактический ход процесса. По его собственным словам, коллеги сначала считали эту идею странной; сегодня метод применяют такие компании, как Siemens и BMW, а сам автор получил прозвище «крестный отец добычи процессов».

Суть и механика. Добыча процессов — специализированная форма добычи данных, которая анализирует бизнес-процессы на основе журналов событий из информационных систем предприятия, таких как системы планирования ресурсов или управления взаимоотношениями с клиентами. Метод позволяет моделировать процессы в их фактическом исполнении, выявлять отклонения, узкие места и неэффективности и предлагать улучшения.

Фокус добычи процессов находится именно на фактическом ходе процесса. Метод часто применяется для выявления расхождений между установленным регламентом и реальным выполнением операций.

Масштаб такого расхождения показывает пример анализа процесса обработки заказов крупного промышленного производителя.

Пример. Компания Siemens применила добычу процессов для анализа собственного цикла обработки заказов клиентов — от поступления заявки до получения оплаты, — который ежегодно охватывает миллионы заказов и около семидесяти различных операций. Восстановленная по журналам систем модель показала, что фактический ход процесса заметно отличается от регламентированного: часть операций дублировалась, часть выполнялась вручную там, где регламент предполагал автоматическую обработку. По данным компании, устранение выявленных отклонений в процессе снабжения и оплаты позволило сократить время обработки отдельного заказа на поставку до тридцати минут, а по направлению обработки клиентских заказов — сократить общее число операций более чем на десять миллионов в масштабе всей компании.

Регламент бизнес-процесса и его фактическое исполнение расходятся практически всегда. Добыча процессов делает это расхождение видимым, опираясь на события, которые информационные системы зафиксировали автоматически, вместо субъективного описания процесса его участниками.

Границы применимости. Инструмент применим там, где бизнес-процесс проходит через информационные системы, оставляющие цифровой след: обработка заказов, снабжение, финансовые операции, логистика. По методике это очень сложный инструмент, самый трудоемкий во всей группе H.

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

Добыча процессов продолжает добычу данных (H3-03) как специализированная форма этого метода и связана с моделированием процессов через нотацию BPMN и сети Петри, изученные в предыдущих статьях цикла.

Чек-лист перед внедрением добычи процессов:

• Определен процесс, для анализа которого имеются достаточно полные и корректные журналы событий.

• Проверено качество данных в журналах: полнота фиксации шагов, точность меток времени.

• Оценена готовность организации к обнаружению и обсуждению расхождений между регламентом и практикой.

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

• Определены показатели, по которым измеряется сокращение узких мест после внесения изменений.

• Установлен порядок повторного анализа процесса после внесения изменений для проверки их эффекта.

Типовые ошибки:

• Анализ на неполных журналах. Модель строят по данным с пробелами в фиксации событий. → Проверять полноту и качество журналов событий до анализа.

• Диагностика без изменений. Расхождения между регламентом и практикой находят, но процесс не меняют. → Переводить результаты анализа в конкретные изменения процесса.

• Игнорирование сопротивления. Изменения вводят без анализа причин сложившейся неформальной практики. → Разбирать причины расхождений с исполнителями процесса.

• Отсутствие повторной проверки. После внесения изменений не проверяют, действительно ли они устранили узкие места. → Проводить повторный анализ процесса после внесения изменений.

Резюме

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

Примеры SABRE и Siemens показывают общий принцип: практическая ценность этих инструментов связана с сокращением задержек и искажений между фактическим событием и информацией, на основании которой принимается решение. Кейс Harrah’s Entertainment дополняет этот вывод: закономерность, найденная алгоритмом в данных, способна изменить распределение приоритетов, которое в течение многих лет воспринималось как обоснованное.

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

В следующей статье цикла переходим к группе I «Кибербезопасность и управление рисками» и разберем первые инструменты этого направления: осведомленность о безопасности, управление рисками и соответствие требованиям.