Точно так же, как с производственных линий иногда сходят дефектные продукты, так и операционно-аналитические процессы иногда генерируют дефектные решения. Порой проблема может быть настолько серьезной, что потребуется остановить процесс и «отремонтировать» его. Если частота ошибок достаточно низкая, это следует рассматривать как приемлемые издержки ведения бизнеса. Принять этот факт может оказаться достаточно затруднительным, зачастую приходится вносить изменения в корпоративную культуру.
В свете вышеуказанных различий организация должна быть готова к тому, что иногда операционно-аналитические процессы будут давать сбои. Возьмите такой крайний случай, как «мгновенный обвал» фондового рынка 6 мая 2010 г., о котором мы говорили в третьей главе{49}. Все началось с небольшой ошибки в одном торговом алгоритме. Многие другие алгоритмы раскрутили его действие и, подобно леммингам, разом бросающимся со скалы, устроили огромную заваруху. В автоматических процессах всегда будут возникать сбои, поэтому здесь действия проверяются после их реализации, а не рекомендации выдаются перед совершением действий.
Поначалу с этим трудно будет смириться, и вы можете столкнуться с сопротивлением на уровне корпоративной культуры. Однако если организация ответственно подходит к созданию, тестированию и мониторингу операционно-аналитических процессов, проблемы будут выявляться до того, как они причинят весомый ущерб. Здесь стоит подчеркнуть следующий важный момент: процесс обнаружения данных должен вестись на постоянной основе. С течением времени во всякий аналитический процесс следует вносить необходимые корректировки с учетом новых данных, новых реалий бизнеса или других значимых изменений.
Периодически возникающие проблемы – это неотъемлемые издержки ведения бизнеса. Организация должна спокойно к ним относиться и устранять их в рабочем порядке. Даже «мгновенный обвал» не обанкротил всех трейдеров, использующих автоматические торговые программы. На обычных производственных линиях также время от времени производятся бракованные изделия, разбиваются бутылки и подгорают продукты питания. Это нормальные производственные издержки. Если частота ошибок достаточно низкая, а средний уровень качества остается высоким, производитель будет процветать в долгосрочной перспективе благодаря достигнутому масштабу производства. То же самое верно и в случае операционной аналитики.
Или возьмите подходы, которые используются банками для выявления случаев мошенничества с кредитными картами или используются поставщиками услуг электронной почты для фильтрации спама. Ни одна из этих процедур не работает идеально. Мы по-прежнему получаем спам по электронной почте или можем стать жертвами мошенничества с банковскими картами. Иногда случается, что в папку со спамом отправляются нормальные письма или банк ошибочно блокирует кредитную карту. Тем не менее в целом ситуация намного лучше той, что была бы в отсутствие аналитики.
Организации не должны позволять своим сотрудникам фокусироваться на таких исключениях и пытаться обесценить подход целиком только лишь потому, что в одном-двух случаях аналитический процесс выдал неправильное или неоптимальное решение. Вопрос должен состоять в том, позволяет ли аналитика снизить, например, общий уровень мошенничества, поскольку никакой аналитический процесс не может исключить его полностью. Неизбежно проскальзывающие ошибки не должны затмевать собой весомых преимуществ операционно-аналитических процессов.
Когда сотрудники обнаруживают ошибочные решения, организация должна отстаивать процесс в целом и помочь сотрудникам понять, что определенная доля ошибок неизбежна. Работники на производственных линиях регулярно отбраковывают продукты, которые не соответствуют стандартам качества, но при этом не ставят под сомнение необходимость самой производственной линии. Точно так же операционная аналитика иногда будет генерировать плохие решения, однако это не должно восприниматься как повод ставить под сомнение необходимость процесса в целом.
Мониторинг операционной аналитики
Хотя операционная аналитика встроена в бизнес-процессы, сотрудники все равно должны активно отслеживать результаты принимаемых решений. Как никогда важное значение приобретает предоставление отчетов, сводной статистики, информации с панелей мониторинга и зрительных образов, позволяющих всем заинтересованным лицам в организации отслеживать эффективность операционной аналитики на постоянной основе. Причем, как то было принято и в традиционной аналитике, уровень детализации или агрегирования данных должен зависеть от уровня и роли заинтересованного лица. Это означает, что классические принципы бизнес-аналитики во многом применимы и к операционной аналитике, о чем мы подробнее поговорим дальше.
Как и в случае традиционной аналитики, в отношении операционной должны быть введены четкие правила, прописывающие последующие действия. Кто должен быть извещен и имеет право остановить процесс при обнаружении аномалии? Кто несет ответственность за мониторинг аналитических процессов, за их корректировку и обновление? Какова приемлемая частота ошибок? Какие еще показатели должны отслеживаться помимо частоты ошибок? Контекст операционной аналитики требует решения точно такого же комплекса вопросов, как и любой другой операционный контекст.
Давайте рассмотрим пример с промышленным предприятием, где операционная аналитика активно используется для регулировки оборудования на сборочной линии. Директор завода должен иметь доступ к детальной информации по регулировкам, произведенным на каждой единице оборудования. Он также должен иметь доступ к последним сенсорным данным и к информации о том, работает ли каждый станок согласно спецификации. Региональному же директору может быть достаточно подтверждения того, что в целом все заводы в регионе работают нормально. Наконец, генеральному директору компании нужна только сводная отчетность с указанием основных тенденций по регионам.
Многие старые правила применимы по-прежнемуВажная часть операционной аналитики – текущий контроль за правильностью и эффективностью миллионов решений, принимаемых в автоматическом режиме. При этом сами данные и метрики, которые хотят видеть люди, остаются фактическими теми же, что и в прошлом. Меняется только способ принятия решений, которые ведут к генерации тех же данных и метрик.
Суть в том, что традиционные правила фильтрации, агрегирования данных и составления по ним сводной отчетности для различных заинтересованных лиц полностью применимы и к операционной аналитике. Более того, во многих случаях существующая стандартная отчетность может не потребовать никаких изменений, поскольку сами данные и метрики, которые нужно видеть сотрудникам, остаются прежними. Меняется только метод принятия решений, ведущих к генерации данных и метрик. Несмотря на то что принятие решений отныне осуществляет автоматический процесс, сам характер решений и их цель могут оставаться такими же, что и в прошлом. Например, операционно-аналитический процесс, предлагающий оптимальные решения для сотрудников колл-центров, делает то же самое, что раньше сотрудники делали сами. Успешность решений с точки зрения содействия дополнительным продажам может отслеживаться традиционным способом, поскольку прежней осталась суть решений – делать предложения, вызывающие или не вызывающие отклик.
Физическая платформа и логическое окружение
Однажды ко мне обратился клиент, который осуществил очень успешный проект по обнаружению данных. (Проект был конфиденциальным, поэтому я не могу назвать имя клиента.) Он нашел ряд ценных инсайтов и захотел применить их на практике и внедрить в операционные процессы. Однако возникла проблема. Корпоративная политика компании, где он работал, предписывала, что любой компонент инфраструктуры, ставший частью даже одного технологического процесса, должен полностью соответствовать всей технологической политике. Другими словами, если бы мой клиент использовал платформу для обнаружения данных в составе любого технологического процесса, то он лишился бы той гибкости, которая необходима для обнаружения дополнительных инсайтов. К сожалению, одну из частей нового процесса имело смысл реализовать только на поисковой платформе. Клиент спросил у меня, как можно решить эту проблему.
Мы начали с изучения того, можно ли закодировать завершающий процесс иначе, чтобы выполнить его на технологической платформе. Часто такое можно сделать после того, как определена точная логика процесса. В данном случае это было невозможно, поскольку на поисковой платформе использовался собственный алгоритм, недоступный для использования где-либо еще, а дублировать его на других платформах оказалось бы слишком накладно. Клиент также справедливо заметил, что даже если бы удалось придать необходимую функциональность технологической платформе на сей раз, то в дальнейшем обязательно возникнут ситуации, когда сделать это будет невозможно. Таким образом, нам предстояло найти более универсальный подход к решению проблемы.
