Статьи

Компания iiko занимается написанием и продажей программного обеспечения для управления ресторанным бизнесом. Пять лет назад iiko стала предоставлять свои разработки по модели SааS (ПО как сервис), и тогда ей потребовалось создать блок эксплуатации и обслуживания. Компания практикует DevOps; об этом в преддверии конференции «Корпоративный DevOps 2019», посвященной DevOps как управленческому подходу и его роли в цифровой трансформации, которую издательство «Открытые системы» проведет в Москве 26 ноября, рассказал Сергей Гнутов, руководитель эксплуатации и технической поддержки компании iiko.

- Почему компания прибегла к DevOps?

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

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

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

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

Сергей Гнутов: «Внедрение DevOps в конце концов делает команду единым целым, с общим инструментарием, целеполаганием, задачами»

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

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

- Как у вас сочетаются SAFe и DevOps?

DevOps – концепция, SAFe – конкретный инструмент организационного и технического характера одновременно (Scaled Agile Framework, SAFe – фреймворк для реализации принципов Agile в крупных организациях – М. С.). И если технический аспект у agile-компаний разный (например, могут быть различные производственные среды), то управленческий – универсальный. Во всех таких компаниях есть этапы планирования, оценки эффективности исполнения и пр. SAFe объединяет команду для выполнения бизнес-задач. При этом в нем есть элементы, которые подходят для различных организационных моделей.

- Чем вам нравится именно SAFe?

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

- Если DevOps – мировоззренческая концепция, то как вы меняете мышление людей?

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

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

- А эти шаги надо продумывать заранее, или они скорее интуитивные?

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

- Как новые люди внедряются в команду? Если с имеющимися сотрудниками надо провести немалую работу, то тяжело ли обучать новичков?

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

- Как часто у вас меняются люди?

У нас довольно стабильная команда. Ротация кадров на уровне 10-15% в год. Это немного с точки зрения рынка.

- Покажете на конкретных примерах, как внедряли DevOps, что получалось, что нет?

Давайте оставим примеры для конференции.

Управление бизнес-процессами считается важной, если не обязательной, составляющей цифровой трансформации. Действительно, как поговаривали еще во времена увлечения первыми 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 лишь роботизацией бизнес-процессов – деньги, выброшенные на ветер.

Все больше компаний позиционируют себя как data-driven, пытаясь сделать свои процессы более интеллектуальными, подвести под каждое решение объективный фундамент. Не случаен и рост популярности такой позиции в штате, как директор по данным. Мы побеседовали о подходах компаний к организации работы с данными, их успехах и проблемах с Александром Тарасовым, управляющим партнером DIS Group и членом экспертного совета CDO Award.

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

Российские компании осознали необходимость системной работы с данными — это бесспорно. Другое дело, что в зависимости от отрасли уровень зрелости компаний весьма разнится. Исходя из личных контактов, могу сказать, что директора по данным (Chief Data Officer, CDO) уже появились не только в финансах и ретейле, но и в медицине. Есть очень много интересных инициатив в промышленности, связанных с большими данными и созданием института data science.

В качестве позитивного изменения можно отметить, что уже не приходится слышать: мы назначили CDO, что ему делать? С таким приходилось сталкиваться два-три года назад. Зачем компании нужно управлять данными, объяснять уже тоже не надо. Более того, сложился рынок CDO, появились первые их переходы из одной компании в другую.

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

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

- А каков внешний показатель того, что компания фактически стала относиться к данным как к полноценному активу?

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

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

- Видите ли вы какие-то «национальные особенности» в развитии подходов к управлению данными у нас?

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

- Но ведь выход новых технологий на российский рынок традиционно запаздывает на пару лет…

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

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

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

- Может быть, вы работаете с лидерами, а «в среднем по больнице» ситуация гораздо хуже?

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

- Должность директора по данным до сих пор не стала массовой. Она нужна не всем или не все созрели?

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

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

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

- Что мешает эффективной работе с данными? Какие вы видите барьеры?

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

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

- Очень многие говорят о специфической культуре, без которой компания не станет data-driven. Насколько она важна и какие изменения подразумевает?

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

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

- Что можно посоветовать компаниям, пытающимся поставить данные в основу своего бизнеса?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В ближайшие два-три года корпоративная сетевая инфраструктура начнет играть более важную роль в условиях, когда средства автоматизации, сетевые компоненты и гибридное облако становятся неотъемлемой частью предприятия. В ходе конференции IT Symposium/XPO в Орландо ведущий аналитик и вице-президент Gartner Дэвид Каппучио осветил основные моменты ключевых инфраструктурных тенденций.

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

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

Переосмысление стратегии автоматизации

На том или ином уровне процесс автоматизации происходит уже много лет, но по мере дальнейшей разработки и развертывания уровень сложности становится слишком велик. Объемами и типами автоматизации необходимо управлять. Нужен переход к командной разработке, управляемой архитектором автоматизации и стандартизированной в бизнес-подразделениях. Чем здесь можно помочь? По оценкам Gartner, к 2025 году архитектор автоматизации будет присутствовать уже на 90% предприятий, тогда как сегодня таковых насчитывается всего 20%.

Гибридные ИТ влияют на надежность восстановления после аварий

Гибридные ИТ, которые строятся на использовании ресурсов частных и внешних центров обработки данных, сервисов SaaS и PaaS, филиальных вычислительных систем, граничных вычислений, разнообразных сервисов безопасности, затрудняют обеспечение готовности корпоративных ресурсов и создания резервных копий. Чрезмерно упрощенные планы восстановления ИТ после аварий могут привести лишь к частичному успеху. К 2021 году в 90% случаев проблемы с готовностью будут связаны с неспособностью провайдера облачных сервисов задействовать собственные резервные мощности. Предприятиям необходимо использовать инвестиции в автоматизацию и другие ИТ-инструменты для переориентации процесса восстановления систем.

Масштабирование практик DevOps требует переосмысления платформы

Во многих компаниях ИТ-служба практически превратилась в менеджера по продуктам для разнообразных команд DevOps. ИТ-служба должна обеспечивать согласованность в масштабах предприятия, потому что появление островков DevOps внутри компании противоречит ее интересам. К 2023 году 90% предприятий столкнутся с трудностями при масштабировании инициатив DevOps, если не произойдет перехода на совместно используемые платформы самообслуживания.

Инфраструктура – и ваши данные – повсюду

К 2022 году более половины корпоративных данных будут создаваться и обрабатываться вне ЦОДа или облака, в то время как в 2019 году их доля не превысит 10%. Инфраструктура сегодня находится повсеместно, и всякий раз, когда данные перемещаются, это порождает определенные трудности. Как управлять сценариями, когда данные находятся повсюду? Каппучио выступает за обязательную оценку инфраструктуры, обслуживающей данные, уже на ранней стадии проектирования. Необходимо инвестировать в инструменты инфраструктуры, с тем чтобы управлять данными там, где они расположены, и модернизировать существующие архитектуры резервного копирования для защиты данных, где бы они ни находились.

Всепроникающее влияние Интернета вещей

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

Распределенное облако

Развертывание облачных сервисов на собственной инфраструктуре с предоставлением провайдеру разрешения управлять этим облаком становится все более популярным. У Google, например, уже имеется Athos, а AWS вскоре представит OutPosts, так что в ближайшие два года среда здесь серьезно изменится. Но рынок еще только зарождается, поэтому клиентам надо проявлять осторожность. Предприятиям следует установить необходимые ограничения и определить, кто будет отвечать за обновления программного обеспечения, исправление обнаруженных там ошибок и производительность.

Иммерсивное восприятие

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

Демократизация ИТ-служб

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

Будущее сетевых технологий

В мире сетей формируется масса новых тенденций: ячеистые сети, сервисы безопасности категории SASE (secure-access service edge), управление сетями по требованию, автоматизация сетей и межсетевые экраны в качестве сервиса. После того, как на протяжении десятилетий все ресурсы направлялись на повышение производительности и готовности сетей, нынешние инновации ориентированы на простоту операций, автоматизацию, устойчивость и гибкость бизнес-моделей. Автоматизация нужна предприятиям «повсюду», и им необходимо искать баланс между безопасностью и гибкостью технологий.

Управление гибридной цифровой инфраструктурой

ИТ-директора сталкиваются с необходимостью выбора оптимального сочетания облачных и традиционных технологий. Сочетание множества различных элементов: граничных узлов, гибридного облака, рабочих процессов и управления приводит к образованию сложной инфраструктуры. 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 взаимодействие последних с теми, кто отвечает за бизнес-операции.

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

В июле 2016 года вступил в силу закон 54-ФЗ «О применении контрольно-кассовой техники при осуществлении наличных денежных расчетов и (или) расчетов с использованием платежных карт». Компании должны использовать электронные кассы, которые передают данные о всех продажах операторам фискальных данных, а те в свою очередь — Федеральной налоговой службе. ОФД оперируют большим количеством данных из чеков. Как работают с большими данными в «Платформе ОФД», рассказал глава компании Алексей Баров.

- Что входит в задачи оператора фискальных данных?

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

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

- У «Платформы ОФД» есть несколько аналитических сервисов, основанных на использовании больших данных. Расскажите о них.

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

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

Третий сервис, Off Take (показатель объема продаж в торговой точке. — М.С.) предназначен для розничных сетей и предоставляет аналитику по эффективности работы торговой точки и отдельных продавцов. Ретейлер может сравнить определенный магазин с другими в регионе, например, по уровню нагрузки на продавца.

Источник: «Платформа ОФД»

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

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

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

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

Самые активные клиенты – производители фармацевтической продукции.

- С чем это связано?

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

Вторая активная отрасль – продукты питания. Часть сегментов пока сложно поддается «обсчету». Так, в строительстве число наименований слишком велико — одних только гвоздей сколько! Но в целом, мы видим, и другие сегменты постепенно проявляют интерес.

- По вашим словам, в августе 2019 года выручка от аналитических сервисов на базе технологий больших данных составила порядка 10% общего оборота компании. Такой показатель достигнут впервые, по итогам всего 2018 года выручка от этих сервисов была мизерной. Чем объясняется такой всплеск?

Это не всплеск, а результат, иллюстрирующий динамику системного роста.

- То есть рост был в течение всего 2018 года? И продолжается сейчас?

Да.

- Каков прогноз на будущее?

Опираясь на текущие тенденции, можно рассчитывать, что к концу 2020 года общая выручка компании от аналитических сервисов составит треть.

- В связи с ростом доли в обороте компании сервисов, основанных на больших данных, что можно сказать об организации работы с данными в «Платформе ОФД»?

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

- Какие технологии применяются для сбора и аналитической обработки данных?

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

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

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

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

- Какие партнеры есть помимо Сбербанка?

Сейчас, например, идет эксперимент по общим продуктам с Tele 2. С банками занимаемся скорингом, мониторингом выданных кредитов, эквайрингом. Договорились с рекламной платформой Segmento о развитии нового формата таргетированной рекламы с использованием агрегированных обезличенных данных кассовых чеков.

- Каковы планы по сотрудничеству со Сбербанком в области аналитики больших данных?

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

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

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

Насколько близко московский бизнес успел подружиться с технологиями программной роботизации? Какие процессы роботизируются прежде всего и каковы перспективы развития RPA в столице? Ответы на эти и другие вопросы содержит исследование ICT.Moscow и Smart City Lab Департамента информационных технологий города Москвы, результаты которого руководитель Smart City Lab Эльдар Файзуллин представит 30 октября на конференции BPM 2019 издательства «Открытые системы». В преддверии своего выступления Эльдар согласился ответить на несколько вопросов об исследовании и технологиях, тестируемых в ДИТ г. Москвы.

- Зачем RPA нужна городу?

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

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

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

Человек, погруженный в рутину, часто ошибается от усталости или невнимательности, например, выгружая большое количество данных в Excel или обрабатывая документы в «1C». Вначале эта ошибка может быть не очень важна, но впоследствии она может оказать серьезное влияние на управленческие решения. Так как робот не устает и не ошибается при работе с исходными данными, результирующие данные получаются чище. Плюс ускорение тоже влияет на качество. Например, если срок оказания госуслуги сокращается с двух недель до одного дня.

- Но ошибки роботов тоже дорого обходятся…

Если мы работаем не с рукописным текстом, а с конкретными данными из таблиц или информационных систем, то ошибки полностью исключены.

- Разве не может быть ошибки в написании алгоритма?

Это проблема не только роботизации, но и автоматизации как таковой.

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

- RPA применимы во многих областях. Какие ключевые направления роботизации бизнес-процессов развивает ДИТ и почему?

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

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

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

- Похоже, то, что раньше называли «костылями», теперь называют роботами?

Если задача решается, причем дешевле, чем классическая интеграция, вряд ли можно назвать это «костылями».

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

- Какие цели ставятся в RPA-проектах?

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

- Как оценивается эффективность проектов RPA?

Для оказываемых городом услуг классические KPI – количество транзакций, выполняемых в единицу времени. Экономию фонда оплаты труда мы не измеряем, так как делаем все в рамках пилотных проектов. Мы не увольняем сотрудников, а фокусируем их на более экспертные задачи.

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

- Кто занимается роботизацией в ДИТ?

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

- С какой целью проводилось исследование применения RPA в столичном бизнесе?

Устранение неизвестности и коммуникации с рынком входят в число задач лаборатории Smart City Lab. Мы нарабатываем у себя экспертизу, и готовы ею делиться. Когда мы начали тестировать роботизацию, хотелось понять, насколько данная технология известна рынку и какие кейсы существуют. Решили собрать эту информацию, обобщить, а затем транслировать ее тем, кому интересно узнать, что такое RPA. С этой целью мы провели качественные и количественные исследования (интервью и анкетирование), в которых приняли участие около 470 компаний. Основная задача — сформировать базу знаний и практик, на основании которой можно получить представление о технологии, реализованных проектах, и при желании начать использовать RPA.

- То есть вы делали это не для ДИТ?

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

- Как отбирались участники исследования?

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

- Каковы основные результаты исследования?

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

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

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

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

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

Региональной компании сложнее найти эффективное применение роботизации.

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

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

- Нормативные барьеры участниками опроса упоминались?

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

- Каковы планы по развитию направления RPA в ДИТ?

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

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

Сегодня для эффективного управления большими массивами данных необходимы сотни конвейеров данных (data pipelines) и сложная инфраструктура. В процессе генерируются тысячи наборов данных, которые «весят» терабайты и петабайты — и все это стоит десятки тысяч долларов. Но при этом многие компании не используют возможности технологий больших данных на полную мощность. Так, в ходе нашего аудита в крупной медиакомпании было выявлено, что 73% инфраструктуры данных работает вхолостую, поглощая немалую долю бюджета. Как другим не наступить на эти же «грабли»?

Куда уходят деньги

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

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

Такие ситуации не редкость. При этом работающие «вхолостую» процессы обходятся компаниям в определенную сумму. Она включает в себя:

• Затраты на создание и обслуживание инфраструктуры, включающие «человекочасы» специалистов, которые выполняют эти задачи.
• Расходы на сервера, на которых работают ETL-продукты, — от нескольких тысяч долларов в месяц.
• Расходы по хранению. Например, стоимость хранения одного петабайта данных в BigQuery (хранилище для больших данных от Google) варьируется от 10 тыс. до 20 тыс. долл. в месяц в зависимости от свежести данных.
• Оплату различных сервисов, которые генерируют данные, таких как инструменты для сбора аналитики по сайту.

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

Крупный бизнес осознает ценность данных и не экономит на продуктах и решениях для их обработки. Консалтинговая компания New Vantage Partners посчитала, что за прошедшие 12 месяцев 34% компаний из списка Fortune 1000 потратили на поддержку BI и AI-инициатив от 50 млн до 500 млн долл., а 21% компаний — более 500 млн долл. При этом 92% руководителей сообщили, что планируют увеличить финансирование этих направлений.

Оптимизируйте хранение

У многих сервисов есть ограничения по срокам сбора данных. Например, сервис GAM (Google Ad Manager) дает возможность собирать данные не более чем 3-летней давности. У других сервисов период может ограничиваться несколькими месяцами. Это значит, что доступ к потенциально полезным данным будет безвозвратно утерян.

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

В первую очередь это ADS-решения (Archive Data Storage). У Google — это Coldline, у AWS — Glacier; «холодное» хранилище предлагает и «Яндекс.Облако». Такие хранилища позволяют долго хранить данные и обходятся относительно недорого. Но есть нюанс: концепция сервисов предполагает длительное хранение данных с платой за доступ. Плата варьируется в зависимости от операции: добавить новые данные — бесплатно; хранить данные — минимальная стоимость; чтение данных — на порядок дороже (и медленнее) по сравнению с обычными хранилищами данных.

Ценовая политика сразу дает понять, что этот сервис — своего рода архив «на всякий случай», предназначенный для ситуаций, когда частое обращение к данным не требуется. Например, если перенести 500 Тбайт редко используемых данных из BigQuery в Coldline и при этом дополнительно сжать данные до 25 Тбайт, расходы на хранение можно сократить с 5 тыс. долл. в месяц до 175 долл.

Оптимизируйте функционал

В свою очередь, отключение функционала также может помочь сэкономить кровные на инфраструктурных расходах. Однако это приведет к потере новых пока бесполезных (но потенциально полезных) данных.

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

Например, данные Google Analytics 360 представляют собой достаточно объемные таблицы с множеством метрик. Представим, что на каком-то этапе работы компании по этим данным генерировалось два отчета: один включал в себя статистику по пользователям, а второй – статистику в разрезе ключевого слова источника трафика (trafficSource.keyword). Когда второй отчет по тем или иным причинам перестал использоваться, продолжающаяся обработка данных стала по сути бесполезной. В такой ситуации целесообразно отключить генерацию отчета, но продолжить накопление сырых данных.

Еще один пример: при помощи Marketing Cloud (бывш. Exact Target) проводился сбор данных по проведенным почтовым рассылкам – кому и какие письма отправлялись, сколько писем было открыто, сколько человек перешло по ссылке в письме и т.д. В какой-то момент эти данные перестали активно использоваться, но это не означает, что они не понадобятся в будущем. А из-за объема и особенностей платформы Marketing Cloud одновременно «вытащить» данные за период более чем полгода — проблематично. Поэтому рациональным решением будет продолжить их накапливать в собственном хранилище в удобной форме и собирать их не ежечасно, а раз в неделю, в тот период, когда другие ETL-процессы минимально нагружают инфраструктуру.

***

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

Автор — Константин Попандопуло, технический директор компании Umbrella IT