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

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

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

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

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

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

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

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

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

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

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