Цифровая трансформация

Инновации — важный драйвер роста, и многие технологические лидеры стремятся создать условия для устойчивого проведения инноваций. Но для этого им порой приходится преодолевать очень серьезные препятствия. Четверть ИТ-директоров, принимавших участие в недавнем опросе Deloitte, заявили, что возможности для внедрения инноваций у них отсутствуют. И только 11% оценили свой инновационный потенциал как отличный и позволяющий удерживать лидерство.

А теперь перечислим десять причин, по которым инновации буксуют, и расскажем о том, что могут сделать ИТ-директора в такой ситуации.

1. Оборонительная позиция

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

2. Отсутствие спонсоров и подотчетности

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

3. Нехватка ресурсов

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

4. Чрезмерный акцент на технологии

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

5. Отсутствие единого владельца

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

6. Синдром «изобретенного не здесь»

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

7. Отсутствие синхронизации

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

8. Фокус на процессы, а не на скорость

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

9. Ожидание разных результатов от одних и тех же людей

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

10. Ошибки измерения результатов

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

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

Консервативность, в которой часто упрекают российский бизнес, не является его уникальной особенностью — зарубежные компании также не горят желанием использовать инновационные технологии. Как отмечает Сергей Золотарёв, генеральный директор Arenadata и член экспертного совета CDO Award, на самом деле российские компании даже быстрее идут на внедрение инноваций по сравнению с западными коллегами. Мы побеседовали с ним о потребностях и проблемах, с которыми сталкивается бизнес на пути к цифровизации, и выяснили, в чем заключается роль CDO.

- Каков типичный портрет компании, кладущей данные в основу своих процессов и становящейся data-driven?

На мой взгляд, к подходу data-driven компании приходят двумя путями. На первый ступают те, кто об этом даже не задумывается, с самого старта выстраивая бизнес на данных. Это может быть какой-нибудь новый сервис или проект, в основе которого лежит работа с данными. Тогда подход data-driven заложен в ДНК таких компаний, и они не испытывают сложностей или проблем в связи с этим.

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

- Какие при этом появляются задачи, перед какими проблемами встают компании?

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

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

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

- Как изменяются потребности и запросы компаний в последнее время, какая наблюдается динамика?

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

- Что является драйвером такого интереса компаний?

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

- Есть ли какая-то особенность подходов к цифровизации, типичная для российских компаний?

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

- Каковы типичные ошибки в подходах к управлению данными? Чему компании уделяют много внимания, а чему — недостаточно?

Управление Big Data — достаточно новая область знания. У многих наших компаний накоплено недостаточно комплексной экспертизы в отношении того, как с этим жить. Поэтому, собираясь внедрять новую технологию, компании оценивают ее не всесторонне — видя лишь явные плюсы, которые она принесет, и игнорируя недостатки. Чтобы избежать этой ошибки, важно иметь набор вопросов и задавать их, анализируя необходимость внедрения инновации.

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

- Как вы оцениваете важность роли директора по данным (CDO)? Как эта роль соотносится с владельцами данных?

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

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

- Куда будут двигаться компании, как будут меняться их запросы в обозримом будущем?

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

Бизнес-руководителям нравится идея средств разработки, которые требуют минимального объема написания кода (Low-Code) или даже совсем не требуют (No-Code). Меньше кода, значит — меньше работы, проекты реализуются быстрее за меньшие бюджеты, а в конечном счете топ-менеджеры быстрее получают премии. Кому такое не понравится?

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

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

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

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

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

1. Проблемы сопровождения и развития

Самая сложная часть работы с решением категории Low-Code обычно ждет вас через несколько лет после внедрения созданной в нем системы. Она прекрасно работает, но постепенно накапливаются запросы на исправления и усовершенствования. Нередко эти доработки выходят за пределы возможностей системы с минимумом кодирования, в связи с чем выполнить их непросто. Если бы в вашем распоряжении был исходный код, его можно было бы частично переписать, но его нет. И если бы разработчики знали, что в дальнейшем понадобится такая-то возможность, они бы, вероятно, изначально приняли другие решения, например воспользовались бы совершенно иным фреймворком. Но этого не произошло и теперь вы — в тупике.

2. Все получают одно и то же

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

Так и системы, созданные при помощи одного и того же инструментария Low-Code, выглядят сделанными «под копирку». Имея минимальный опыт, разработчик может беглым взглядом определить, какой именно инструмент использовался для разработки системы — движок «проглядывает» сквозь нее независимо от настроек, заставок и CSS-«обложек». Часть пользователей это устраивает, если для них лучше, чтобы интерфейс выглядел привычным, но другим нужен элемент новизны.

3. Универсальных инструментов не бывает

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

Решения Low-Code просты в использовании, но одинаковы в своей ограниченности. Вам доступно мало возможностей изменения, настройки и написания кода — вам приходится работать с тем, что есть, и с этим ничего не поделаешь. В итоге недовольны и программисты, и пользователи.

4. Иногда написать код проще, чем выполнить настройку

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

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

5. Полет вслепую

Программисты привыкли пользоваться средствами отладки, которые позволяют остановить выполнение программы в любой точке, чтобы просмотреть состояние переменных и уточнить, что происходит внутри алгоритма. Инструменты Low-Code же для «простоты» скрывают внутренности программы от разработчика.

Если решения на базе Low-Code ведут себя, как ожидалось, проблем с этим нет. Но часто бывает так, что при минимальных неполадках работа застревает, так как нет возможности уточнить, что происходит внутри «черного ящика» — вы словно ведете самолет без приборов, летя наудачу.

6. Нельзя добавлять функции корректировки данных

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

В системах Low-Code для подобных задач могут быть предусмотрены фильтры или переключатели, и обычно этого достаточно. Но когда нет, вам не повезло. Для поставщиков малокодовых сред это тоже непростая ситуация. Некоторые из них экспериментировали с возможностью добавления произвольных фрагментов кода, но это чревато дырами безопасности, если кто-то находит способы злоупотребления. К примеру, из Drupal убрали возможность включения фрагментов кода PHP, чтобы закрыть потенциальную брешь безопасности и улучшить производительность кэширования.

7. Cистемы Low-Code, как правило, неэффективны

Инструменты Low-Code сулят возможность «понимать», чего вы хотите, и волшебным образом исполнять ваши желания. Но цена этого «чтения мыслей» — увесистый стек кода, в котором предусмотрены варианты на все случаи жизни.

Допустим, ваша компания хранит все данные только в CSV-файлах. Но разработчики среды Low-Code должны все предусмотреть и также обеспечить поддержку JSON, YAML, XML версий 1.0 и 1.1 и т. д. Существует масса всевозможных форматов данных, и отдел маркетинга поставщика среды Low-Code будет настаивать на том, чтобы она поддерживала все из них — ведь нужно как можно больше галочек в таблице функциональности.

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

Как следствие, созданный продукт работает медленнее и менее эффективно, чем могла бы. Если вы стеснены жесткими сроками и обрабатываемый вашей системой набор данных не слишком велик, неэффективность можно замаскировать, добавив мощностей. Но рано или поздно «счет» за излишки в коде вам будет выставлен в любом случае.

8. Нужны специальные навыки

Многие платформы с открытым кодом разработаны на популярных языках программирования, широко преподаваемых в университетах. Есть немало специалистов, которые способны разобраться в коде стеков, реализованных на Java, JavaScript, Python, PHP и т. д.

Но работе с инструментариями Low-Code студентов не учат, поскольку в теории это и не нужно. Конечно, подобные инструменты нередко тоже написаны на распространенных языках, но проблема не совсем в этом, а в сложности структуры фреймворков Low-Code. Вы платите не только за саму систему — в дальнейшем, если ее нужно будет доработать или расширить, членам вашей команды придется потратить дополнительное время на изучение ее устройства.

9. Зависимость

Внедрение платформы Low-Code напоминает попадание в толпу — присоединиться легко, а выбраться непросто. Цена уменьшения объема выполняемой вами работы — зависимость от гигантов, которые подпирают своими плечами ваши системы. Пока гиганты двигаются, вы двигаетесь вместе с ними. А если они останавливаются или падают, вас ждут проблемы.

В спортивной индустрии большие данные имеют огромный потенциал, считают в Ассоциации менеджеров. Сегодня объем рынка систем мониторинга и аналитики в спорте оценивается Forbes в 764,3 млн долл., а к 2023 году ему прочат резкое увеличение — до 15,5 млрд долл. В большом спорте, как и в большом бизнесе, цели применения технологий больших данных самые разные — от разработки игровой стратегии до увеличения продаж. Весьма интересный опыт в этой области получила за последние пару лет, к примеру, испанская футбольная LaLiga (ранее — Primera Division).

Озеро данных о фанатах

LaLiga продает права на трансляцию матчей испанских футбольных клубов и распределяет деньги между клубами. То есть детальное знание аудитории трансляций — ее хлеб. C 2017 года аналитики LaLiga применяют BI-инструменты Microsoft для персонализации и улучшения клиентского опыта — опыта фанатов. При этом используются все данные как о зарегистрированных, так и о незарегистрированных пользователях канала LaLiga, представляющего собой своего рода «спортивный Netflix», а также о пользователях мобильного приложения. Даже если пользователь не отвечает на опросы на сайте и в приложении, нужные аналитикам данные все равно получают из других источников и загружают в озеро данных. Ведь правильная сегментация болельщиков — ключ не только к таргетированной рекламе, но и новым спонсорским соглашениям.

«Доступ к информации, предоставляемой LaLiga, очень помогает небольшим клубам заключать спонсорские контракты», — сообщил Даниэль Cерехидо, руководитель развития бизнеса и стратегии LaLiga в России и Белоруссии. Еще одно пока слабо развитое, но весьма перспективное направление — сбор информации с голосовых помощников. Вся информация стекается в озеро данных, к которому применяется аналитический инструментарий. Например, зная, какого игрока любит конкретный зритель, ему будут предлагать билеты именно на матчи с его участием и расписание соответствующих турниров.

На основе собранных данных о поведении болельщиков, о туристических потоках и о погоде разработанный компанией алгоритм прогнозирует количество зрителей и оптимизирует расписание матчей, позволяя в итоге максимизировать и посещение фанатами стадионов, и число посмотревших трансляцию в разных странах мира. Практика показывает, что ошибки предсказательной аналитики совсем невелики: реальные показатели отличаются от прогнозных всего на 1% для TB аудитории и на 3,4% для посетителей стадионов.

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

Клубам нужны аналитики

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

«Печально, но данные выпадают из фокуса менеджмента, это не предмет интереса, — констатировал он. — Кроме того, это чертовски дорого, а эффект, который можно получить, для людей непонятен».

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

Кирилл Лата: «Мы все субъективны и видим то, что хотим видеть; для объективности нам нужны данные»

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

«Большие данные подталкивают к трансформации наших продуктов в Life Style, как это произошло с банковскими продуктами, — отметил Лата. — Мы стремимся узнать про болельщиков все, каждый их шаг, найти взаимозависимости, сравнить их с общими тенденциями и придти к эффективности продаж».

Пример двух клубов Лиги уже подтвердил высокий потенциал работы с данными: только за счет настройки рекламной компании затраты на продвижение матчей сократились с 10 до 5,5% от выручки.

Однако не очень понимая как монетизировать данные, клубы, тем не менее, не очень охотно с ними расстаются. Еще один немаловажный нюанс: постоянно бывая на стадионах, менеджеры часто пребывают в уверенности, что и так прекрасно знают своих болельщиков. «Мы все субъективны и видим то, что хотим видеть, для объективности нам нужны данные», — напомнил Лата.

Многообещающим примером работы с данными в российской спортивной индустрии служит футбольный клуб «Зенит», который помимо привычной CRM-системы первым в отрасли внедрил решение SAP Marketing и начал создавать модели поведения болельщиков и строить на их основе свои взаимоотношения с ними. Сегодня 95% билетов на матчи этого клуба продаются через сайт, где еще до регистрации пользователя определяются его личность и интересы, так что в момент регистрации его модель поведения только фиксируется, а затем дополняется открытыми данными соцсетей, чтобы сделать ему наиболее адекватное, и что немаловажно — своевременное предложение. Эффективность рекламных кампаний «Зенита» выросла на 27%, и этот проект продолжает активно развиваться.

Управление бизнес-процессами считается важной, если не обязательной, составляющей цифровой трансформации. Действительно, как поговаривали еще во времена увлечения первыми ERP, «нельзя автоматизировать хаос». Невозможно построить цифровое предприятие, опираясь на «аналоговые» бизнес-процессы, однако, как продемонстрировала конференция «BPM 2019. Процессы цифрового предприятия», организованная издательством «Открытые системы» в конце октября, подход к ВРМ может быть разным. Можно начинать со строгого описания текущих бизнес-процессов и затем цифровизировать все подряд как есть, а можно стартовать с внедрения системы BPMS. Но, пожалуй, лучше рассматривать ВРМ как составную часть инициатив цифровизации и пересмотреть бизнес-процессы: возможно, некоторые из них существуют только потому, что существуют, и не стоит их брать в светлое цифровое будущее?

Ведущий круглого стола Анатолий Белайчук, президент ассоциации ABPMP Russian Chapter, предложив сторонникам разных взглядов обсудить роль BPM в цифровую эпоху, отметил, что сегодня наблюдается очередная волна интереса к BPM, и вызвана она появлением таких технологий, как Интернет вещей, машинное обучение, Low code, RPA и др. Однако, по замечанию Елены Березовской из инвестиционного банка «Веста», «если человек не понимает, как устроен мир, то ему не помогут ни BPM, ни CRM, ни даже искусственный интеллект — технологии вторичны».

Действительно, бизнес-процессы появились задолго до автоматизации, и BPM – это ядро платформы цифрового бизнеса. Однако Анна Кузнецова, руководитель практики BPM компании Naumen, уверена: «На пути к цифровой трансформации разные компании находятся в разных стадиях развития, работают в различном конкурентном поле, и этим-то, в каждом конкретном случае, определяются степень заинтересованности в BPM и пути внедрения соответствующих систем автоматизации».

Владимир Репин из ассоциации ABPMP Russia напомнил, что компании неоднородны и в разных подразделениях бытуют свои взгляды на цифровизацию, а главное – нельзя забывать про людей: «За каждой схемой стоит конкретный человек, и задача BPM – уменьшить «трение» в системе. Даже простой сбор предложений по изменению бизнес-процессов организуется среди людей, а не среди роботов». С ним согласна и Кузнецова: «BPM — для людей, а не против них. И задача любой автоматизации в том, чтобы освободить людей от рутины. Человек должен ощущать себя не 'винтиком', а главным звеном в единой машине организации».

Алексей Пестриков, управляющий директор дивизиона «Кредитные продукты и процессы» Сбербанка, отметил: «Все, что можно описать, можно и автоматизировать, однако людям свойственно ошибаться». Для минимизации ошибок можно использовать роботизацию бизнес-процессов (RPA), однако такие решения направлены на автоматизацию задач, а не процессов.

«Надо мыслить процессами целиком, а не отдельными задачами, иначе средства автоматизации смысла не имеют», – настаивает Березовская. Вместе с тем, в цифровую эпоху ИТ-подразделения, по мнению Пестрикова, уже не действуют по приказу бизнеса «что скажут, то и сделаем», а становятся партнерами бизнеса и предлагают ему новые бизнес-процессы, невозможные без новых технологий.

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

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

«ИТ-руководители могут способствовать выживанию и процветанию своих компаний за счет совершения цифрового прорыва, убеждая генерального директора и лидеров бизнеса придерживаться более продуманной и взвешенной стратегии», – отмечают аналитики Gartner Ли Макмаллен и Дэйв Арон.

В материалах проведенного ими исследования организациям предлагается пять возможных стратегий.

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

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

«Разрушение». Предложение продуктов и услуг бесплатно с целью увеличения числа клиентов, которым можно было бы предложить более ценные и дорогие услуги.

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

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

Макмаллен и Арон призывают ИТ-директоров иметь дело с теми поставщиками технологий и сервисов, которые помогают организации в освоении и выстраивании цифрового бизнеса.

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

Нас ждут сразу несколько волн цифрового прорыва.

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

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

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

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

С 1 декабря российское отделение Ассоциации профессионалов управления бизнес-процессами начинает прием заявок на конкурс «BPM-проект 2019 года». Об этом Юлия Вагнер, вице-президент ABPMP Russian Chapter, объявила 30 октября на конференции BPM 2019 издательства «Открытые системы».

Конкурс для организаций, которые смогли повысить эффективность управления благодаря процессному подходу и готовы делиться своим опытом, проводится при поддержке ИТ-кластера Фонда «Сколково» и Аналитического центра при Правительстве РФ уже третий раз. Его призеры и лауреаты, а также финалисты прошлого года вошли в число самых ярких докладчиков конференции BPM 2019. Так, Юрий Радыгин, начальник департамента организационного развития и проектного управления Башкирской электросетевой компании, — обладатель приза за самый результативный BPM-проект 2018 года. Примечательно то, что в этой компании трансформируют свои процессы на основе отечественных программных продуктов. Елена Березовская, руководитель процессного офиса инвестиционного банка «Веста», получила специальный приз за создание комплексной промышленной технологии внедрения и автоматизации системы бизнес-процессов. А работа команды Алексея Здюмаева, генерального директора компании Vetro, заслужила сразу две награды — от сообщества ABPMP Russia и от Роскачества за создание федерального оператора по обслуживанию клиентов страховых компаний в части ремонта автомобилей — Российского автостекольного союза.

Лауреатом прошлого года стал также проект автоматизации кредитного процесса для корпоративных клиентов Сбербанка, представленный Андреем Водяницким, директором проектов Сбербанка.

Очень живо восприняла аудитория конференции и выступление Ларисы Зубриловой, генерального директора Центра обслуживания бизнеса КАМАЗа, рассказавшей о проекте создания мобильного приложения для сотрудников автогиганта, который номинировался на конкурс 2018 года. «Проектные команды, приходящие на конкурс, — это люди светящиеся, у них глаза горят», — отметила Вагнер.

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

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

Помимо выбора главного BPM-проекта года, награды вручаются в нескольких специальных номинациях: за самый результативный проект, самый инновационный проект, лучший проект среди государственных организаций, приз сообщества ABPMP Russia и специальный приз жюри. А в этом году список номинаций пополнился еще одной: «За настойчивость в достижении процессного совершенства».

Итоги конкурса планируется подвести в мае 2020 года на конференции издательства «Открытые системы» по роботизации бизнес-процессов.

Предлагаемая публикация является фрагментом из книги There's No Such Thing as an IT Project: A Handbook for Intentional Business Change.

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

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

Отчасти это связано с тем, что принцип «ИТ как бизнес» привел к странной практике — заключению соглашений об уровне обслуживания между отделом по эксплуатации ИТ и его внутренними клиентами.

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

Задать первую часть обычно легко, со второй дело обстоит сложнее. Например, в SLA может быть указано, что длительность перебоя в работе до восстановления обслуживания может составлять не более часа. При этом, согласно второй части, это правило должно соблюдаться для 99% всех перебоев.

Для случаев, когда провайдер не выполняет SLA, в соглашении предусматриваются средства возмещения, заранее согласованные путем переговоров. Если предполагается, что ИТ-служба должна действовать как независимый бизнес, заключение SLA с внутренними заказчиками кажется вполне логичным. Однако как показывает реальность, трудно придумать что-то менее логичное.

Стопор инноваций

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

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

Третья причина — вы получаете только то, что измеряете. А в большинстве случаев отдел ИТ контролирует уровни обслуживания, но мерок инновации не имеет. Между тем, правильное управление ИТ-службой — это постоянное балансирование между надежностью и инновацией, а последняя подразумевает риск. Но поскольку отчеты по SLA — ретроспективные, в них включаются только негативные последствия инновации, но не достигнутые преимущества.

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

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

Доводы против SLA

ИТ-служба обычно отвечает за технические услуги и за услуги поддержки. SLA для технических услуг касаются доступности, производительности систем и т. п. Но проблема в том, что архитектуры высокой доступности когда-то были исключением, а сегодня — уже нет.

Нужно ли ИТ-службе продолжать контролировать уровень качества технических услуг? Да, если он не слишком высокий, но — только для того, чтобы придти к тому моменту, когда дальнейшее отслеживание станет бесполезной тратой времени.

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

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

Услуги поддержки, в свою очередь, оказываются ИТ-специалистами тем, кто занимается бизнес-операциями. SLA для услуг поддержки могут регулировать, например, длительность ожидания ответа на вопрос пользователя и максимальное время разрешения проблемы. Службе поддержки удается соблюдать эти требования, когда численности ее сотрудников хватает, чтобы справиться с объемом поступающих заявок, а если обращений слишком много, результативность падает. Таким образом, SLA не имеют никакого отношения к результативности — они просто «плетка», которой можно отхлестать руководителя службы поддержки.

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

Единственная характеристика ИТ-отдела, имеющая смысл

Успешная работа руководителей всегда делает их более заметными, способствуя продвижению по службе и росту оплаты. А о службе ИТ вспоминают только когда что-то идет не так.

Лучшие показатели — те, которые количественно выражают характеристики качества. Показатель результативности эксплуатации ИТ-систем, который наилучшим образом демонстрирует, насколько хорошо справляется ИТ-служба, — это степень ее невидимости. Этот «индекс невидимости» должен быть составным, учитывающим доступность и производительность приложений, число обращений в службу поддержки, а также частоту случаев, когда проблемы с эксплуатацией ИТ-систем создают узкие места в других бизнес-процессах и практиках.

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

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

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

Цифровая трансформация и BusOps

Сегодня во многих компаниях руководители только и твердят, что о цифровой трансформации, и вряд ли когда-нибудь был менее непонятный и неоднозначный предмет «корпоративной моды». Но, если отбросить ажиотаж, — существуют конкретные цифровые технологии, которые дают новые возможности. Компании могут воспользоваться ими, чтобы получить конкурентное преимущество или они могут проигноировать их, уступив преимущество соперникам.

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

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

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

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

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

Что же должно измениться? Ответ снова дает DevOps. Культуру взаимодействия DevOps нужно распространить на отношения между отделом эксплуатации ИТ и другими операционными отделами компании — аналогично тому, как бизнес-руководители, стремясь преуспеть, налаживают взаимодействие с ИТ-специалистами, отвечающими за бизнес-приложения.

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

Тем временем эксплуатационному отделу ИТ-службы нужно исправить ситуацию с Agile, в том числе и потому, что понятия «ИТ-проект» больше не существует: Agile в практикуемой ныне форме по-прежнему используется для выпуска конкретных продуктов, а не как основа взаимодействия, направленного на изменение бизнеса в лучшую сторону. «Исправляя» Agile, лучше усилить эффект, введя элементы DevOps и включив в проектную группу по изменению бизнеса системных администраторов и администраторов безопасности. Тем самым вы улучшите результативность проектов, а дополнительные знания по важным для бизнеса вопросам помогут повысить эффективность повседневных решений, принимаемых специалистами по эксплуатации ИТ.

Чтобы придать описываемой концепции официальный статус, предложим для нее новый термин. По аналогии с тем, как DevOps означает взаимодействие разработчиков и специалистов по эксплуатации ИТ, назовем словом BusOps взаимодействие последних с теми, кто отвечает за бизнес-операции.

Бой, согласно Сунь Цзы, «всегда идет за сердца и умы», так что начнем с согласования терминологии. Добавив новое слово в свой лексикон, вы, возможно, приятно удивитесь результатам.

Подход Low code, предусматривающий создание программных решений с минимальным программированием или путем конфигурирования и настройки системы через визуальный интерфейс, позволяет вовлечь в решение задач автоматизации и цифровой трансформации широкий круг бизнес-пользователей. Одно из главных направлений, где такой подход находит применение, — конструирование систем управления бизнес-процессами. Участники конференции «BPM 2019: Процессы цифрового предприятия», которую издательство «Открытые системы» проведет 30 октября, смогут сделать это своими руками. Их ждет интересное интерактивное мероприятие: мастер-класс «Автоматизация бизнес-процессов без программирования на платформе К2». Мы попросили генерального директора «К2РУ» Андрея Холинова поделиться некоторыми подробностями.

- В чем заключается основная идея мастер-класса?

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

- Нет ли в этом лукавства, игры словами?

Нет, в том-то и дело. К2 представляет категорию систем Low code, которые не требуют программирования. Мы хотим показать, как прямо «из коробки», с нуля создается решение: структура данных, справочники, интерфейсы управления этими справочниками и интерфейсы самой системы, потоки работ, проектируются роли пользователей, которые будут участвовать в этом процессе. Для этого мы возьмем за основу один из бизнес-процессов, общих практически для всех организаций, например заявку на отпуск, прием нового сотрудника или запрос в службу ИТ-поддержки, и покажем, что прототип системы можно разработать в течение часа, если под рукой есть такой инструмент. Исследования, проведенные нашей материнской компанией SourceCode Technology, показывают, что разработка на K2 в восемь–десять раз быстрее, чем выполненная традиционным способом.

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

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

- Кому адресован мастер-класс?

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

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

Платформа — это конструктор. Компании не придется ломать свои процессы и работать так, как предлагает «коробка». Возьмите наш инструмент, научите своих программистов строить реальные бизнес-процессы и автоматизируйте их в K2. Вы увидите, как работают ваши процессы, каковы проблемные места и возможности для дальнейшей оптимизации, сможете своевременно принять управленческие решения — поменять сотрудников, сократить стадии. По результатам анализа процессы переделываются. Это непрерывный цикл, но тем самым повышается качество сервисов, которые подразделения предоставляют внутри компании, и оптимизируется работа компании в целом. Где-то освобождается время сотрудников, где-то приводится в порядок учет и экономятся средства, добавляются прозрачность и возможности контроля. Люди освобождаются от необходимости бегать по этажам и думать, кому от них передается документ, им надо лишь четко выполнить свою функцию, а система сама знает, куда договор должен попасть дальше. Обеспечивается полное соответствие корпоративным политикам, потому что процесс нельзя обойти. Не бывает такого, что какая-то стадия просто опускается. Все, что должно произойти, обязательно происходит, плюс вы устанавливаете конкретные сроки, сокращая время исполнения процессов и делая бизнес эффективнее.

- Какие нужны минимальные знания и навыки, чтобы получить реальный эффект от мастер-класса?

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

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

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

- Есть ли ограничения для использования вашего решения?

Прежде всего надо понимать, что К2 — решение корпоративного уровня, предназначенное главным образом для среднего и крупного бизнеса с численностью 500-1000 сотрудников, а значит, оно недешево. Кроме того, надо учитывать технологическую платформу клиента. Если основу технологического стека организации составляют продукты Microsoft, то использование K2, как правило, не потребует дополнительных расходов.

По функциональности и возможности автоматизировать бизнес-процессы ограничений нет. Но в большей степени система направлена на оптимизацию процессов типа «человек–человек» и «человек–сервер». В процессах «сервер–сервер» польза от нее не столь очевидна.

Дизайнер интерфейсов К2 дает возможность «собирать» нужные для работы пользователя электронные формы в десятки раз быстрее, чем позволяют средства традиционного программирования. Вместе с тем для создания сложных интерфейсов может потребоваться иной UI-инструментарий, особенно если планируется работа с данными на уровне тысяч записей. Но клиент может выбрать для этой задачи любую другую технологию форм и работать с BPM-движком через API или сервисы, которые предусмотрены в K2.

Помимо традиционного продукта, устанавливаемого на оборудование клиента, у компании есть довольно популярный продукт K2 Cloud, предоставляемый по модели SaaS. Облачные сервисы избавляют клиентов от необходимости поднимать у себя инфраструктуру и заниматься вопросами технической поддержки, но здесь возникает ограничение, так как облака Microsoft Azure в нашей стране нет и по закону мы не можем отправлять на зарубежные серверы персональные данные, с которыми имеет дело практически каждая информационная система.

От разработки функции симуляции процессов компания осознанно отказалась, так как это ведет к удорожанию продукта. Также не стали включать в состав платформы дизайнер отчетов и анализа бизнес-данных. На рынке есть профессиональные средства построения отчетности (PowerBI, Tableau, SSRS и др.), К2 имеет встроенные коннекторы к этим системам. Вместе с тем K2 поставляется с внушительным набором базовых отчетов, относящихся к анализу потоков работ (количество задач, пользователей, нарушений сроков и т. п.).

- Вы расскажете в том числе и об ограничениях?

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

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

Мы надеемся, что они будут впечатлены технологическими возможностями платформы и получат представление о том, как работать с программным обеспечением такого уровня. Многие скептически относятся к тому, что можно построить решение без программирования. И хотя сейчас таких решений на рынке уже много, о них знают лишь энтузиасты. Большинство пользователей только слышали о таких решениях, но еще не «трогали их руками». По окончании мастер-класса мы готовы предложить слушателям бесплатно попробовать нашу систему в облачных учебных средах. У каждого будет своя персональная среда с удаленным подключением в течение какого-то количества дней. Желающие получат пошаговое практическое руководство по разработке своего решения и попробуют сделать его самостоятельно.

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

- Кто будет вести мастер-класс?

Андрей Семичастнов, ведущий разработчик К2РУ, который уже более пяти лет занимается автоматизацией бизнес-процессов на платформе К2 и имеет большой практический опыт в реализации сложных проектов, в том числе для таких российских компаний, как ГМК «Норильский никель», ФК «Открытие» и др. В команде разработчиков Андрей участвовал в реализации проекта автоматизации корпоративных сервисов НИУ «Высшая школа экономики», получившего в 2019 году награду «BPM-проект года» от ABPMP Russia.

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

«К 2025 году технология эта определенно станет мейнстримом, хотя сегодня в силу проблем безопасности и конфиденциальности получает лишь весьма ограниченное распространение», – указал вице-президент Gartner Мэтью Кейн, выступая на недавнем саммите Digital Workplace Summit.

Согласно прогнозам Gartner, расходы компаний и индивидуальных потребителей на умные колонки в 2021 году превысят 3,5 млрд долл. В ближайшие два года четверть цифровых работников будут использовать помощников с искусственным интеллектом на ежедневной основе. Ряд компаний уже внедрили у себя соответствующую технологию (впрочем, специалирующаяся на услугах коворкинга компания WeWork, по сообщениям, приняла решение отложить внедрение Alexa в собственную бизнес-среду).

«Думаю, единственной загадкой является то, почему этот процесс так затянулся, – отметил Кейн. – Все уже успели прочувствовать ценность персональных помощников в личной жизни – речь идет об Alexa, Siri и Google Assistant. Рано или поздно к ним присоединится и Microsoft с Cortana. Но мы ждем персональных помощников на рабочем месте – отложенный спрос здесь поистине огромен».

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

Новый босс ничем не отличается от прежнего?

В Gartner ожидают, что инструменты искусственного интеллекта помогут менеджерам принимать лучшие решения. «Боссы-роботы получат повсеместное распространение к 2025 году, – считает Кейн. – При этом не обязательно все должны подчиняться алгоритмам, так что можете вздохнуть свободнее».

Искусственный интеллект поможет выполнять рутинные операции, с которыми приходится сталкиваться менеджерам.

«Посмотрите, что делают менеджеры каждый день: составляют расписание, формируют задания, оценивают эффективность, содействуют карьерному росту, помогают в профессиональной переподготовке, утверждают предлагаемые инициативы, выстраивают информацию и следят за выполнением директив, – пояснил Кейн. – Многое из перечисленного способен проделывать искусственный интеллект. Вашего менеджера алгоритм не заменит, но искусственный интеллект будет использоваться для улучшения и повышения эффективности рутинной работы. Думаю, мы идем к сочетанию всего перечисленного».

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

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

Искусственный интеллект дополнит работника, а не заменит его 

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

«К 2024 году искусственный интеллект станет существенным, но по большей части невидимым элементом нашей повседневной работы, – указал  аналитик Gartner Лей Макмаллен. – Новые виды деятельности получат утонченную поддержку со стороны искусственного интеллекта».

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

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

«Лишь очень немногие рассчитывают на решение искусственным интеллектом сложных проблем, – указала вице-президент и аналитик Gartner Хелен Пойтевин. – Сотрудники не ждут от искусственного интеллекта чудес, они хотят от него лишь помощи в своей повседневной деятельности. Многие ежедневно подвергаются воздействию со стороны искусственного интеллекта, но, возможно, даже не осознают этого. У нас есть электронные таблицы, которые интересуются тем, нужны ли нам идентификация и визуализация шаблонов данных; текстовые редакторы, умеющие копировать; календари, напоминающие, когда следует отправляться в аэропорт, и приложения электронной почты, помогающие отвечать на письма. Все это повседневные сервисы искусственного интеллекта, которые оказывают на сотрудников гораздо более серьезное влияние, чем специализированные приложения для медицинской диагностики, одобрения кредитов или распознавания угроз».

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

«Сотрудники, которые уже знакомы с искусственным интеллектом, спокойнее относятся к его влиянию на рынок труда, – подчеркнула Пойтевин. – Тот, кто уже имел дело с сервисами искусственного интеллекта, с меньшей опаской воспринимает вероятность замены своей должности на искусственный интеллект».

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

«Не утихают споры о том, уничтожает искусственный интеллект рабочие места или же создает их, – заметил Кейн. – По мнению аналитиков Gartner, рабочих мест создается больше, чем ликвидируется, просто потому, что искусственный интеллект повышает эффективность работы предприятия, а это способствует развитию бизнеса, что в свою очередь влечет за собой увеличение числа рабочих мест. Конечно, опасения вытеснения людей искусственным интеллектом присутствуют, и с некоторыми рабочими местами это действительно происходит… на смену человеку здесь приходит искусственный интеллект. Но в большинстве случаев речь идет все-таки о дополнении. Искусственный интеллект берет на себя большую часть рутинной работы. Он помогает сосредоточиться на решении задач для человека, на наиболее творческих аспектах. Так что сегодня мы сталкиваемся в основном с изменением рабочих мест, а не с их ликвидацией».