Статьи

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

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

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

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

Выделить бюджет на внедрение принципов NetOps

73% участников исследования уже выделили средства на устранение недостатков средств сетевого мониторинга и диагностики неисправностей. Еще 23% рассчитывают получить соответствующий бюджет после 2021 года.

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

Провести ревизию требований к управлению сетями при работе из дома

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

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

49% нужно увеличить масштабируемость своих инструментов. Выясняется, что данные собираются из большего количества источников, что отражается на производительности существующих инструментов. Например, до пандемии сетевой администратор мог контролировать 30 маршрутизаторов в 30 филиалах. Исследование EMA показало, что сегодня 75% организаций используют сетевое оборудование и в домашних офисах. Особенно это касается устройств сетевой безопасности и точек доступа Wi-Fi. Таким образом, в дополнение к уже упомянутым 30 маршрутизаторам в филиалах инструмент мониторинга должен будет поддерживать еще 500 сетевых устройств в 500 домашних офисах. Это может потребовать модернизации оборудования и получения дополнительных лицензий в соответствии с растущим числом управляемых сетевых элементов.

Улучшить интеграцию инструментов мониторинга с другими системами

Администраторам сетей нужно интегрировать свои инструменты с другими системами, с тем чтобы улучшить поддержку сотрудников, работающих на дому. 43% опрошенных заявили, что ужесточение требований к мониторингу домашних офисов заставляют их интегрировать инструменты мониторинга с решениями SD-WAN или SASE (secure access service edge). 33% респондентов указывают на необходимость расширенной интеграции со службой поддержки или с системами управления сервисами, что должно ускорить реакцию специалистов по сетевым технологиям на жалобы со стороны удаленных работников.

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

Инвестировать прямо сейчас

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

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

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

Разные цвета денег

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

Капитальные затраты

Под капитальными затратами (Capital Expenditure, CapEx) обычно понимается покупка физического актива, который, как ожидается, будет использоваться в течение по крайней мере одного года.

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

Для капитальных затрат характерен ряд особенностей.

— Актив стоит относительно дорого. Обычно это одноразовая закупка (но одноразовая закупка может быть сделана в рассрочку).

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

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

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

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

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

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

Постоянные затраты

Постоянные затраты (fixed-cost expenditure) – это покупка товара или услуги, которые потребляются предприятием за короткий период времени, не превышающий одного года. Постоянные затраты предусматривают короткий период использования или приобретение каких-то расходных материалов.

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

Другим примером являются приобретаемые услуги, в том числе услуги по уборке офиса. Коммунальные услуги – электроэнергия и вывоз мусора – также относятся к таким затратам. В области программного обеспечения это применимо к оплате за SaaS-сервисы.

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

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

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

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

Себестоимость реализованной продукции

Последним типом затрат являются затраты на себестоимость проданной продукции (cost of goods sold, COGS). Себестоимость может быть непосредственно связана с покупкой товаров или услуг.

Показатели COGS растут при увеличении продаж и снижаются, когда продажи падают. Если ваша компания создает какой-то продукт, стоимость материалов и труда, затраченного на его изготовление, относится именно к COGS.

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

Расходы на себестоимость обычно находятся в прямой зависимости от объема получаемой выручки.

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

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

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

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

ЦОДы и облака

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

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

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

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

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

Большая часть затрат на строительство облачного ЦОДа считается переменными расходами, которые относятся к категории COGS.

***

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

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

Цвет денег, которые вы тратите, очень важен для вашего облачного опыта.

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

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

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

Задачи для разработки low-code такие же, что и для приложений, написанных вручную: настольных, веб- и мобильных. Настольные приложения обычно рассчитаны в рамках графических интерфейсов пользователя Windows, macOS и Linux. Веб-приложения должны работать во всех браузерах (Chrome, Edge, Safari, Firefox и Opera), и им необходимо оперативно обрабатывать различные размеры экрана. Мобильные приложения в первую очередь ориентированы на iOS и Android. Гибридные веб-приложения совмещают собственную оболочку с веб-контентом.

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

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

Что такое разработка no-code?

Разработка no-code — это, по сути, та же разработка low-code, но без языка программирования, который вы могли бы использовать в продукте. Создатели подобных платформ иногда создают ухищренные визуальные инструменты, призванные заменить написание фрагментов кода, но инструменты эти, как правило, неудобны и отнимают много времени.

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

Кто занимается разработкой low-code?

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

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

Существуют ли гражданские разработчики?

Термин «гражданские разработчики», похоже, пришел из мира аналитических систем, и у него тяжелое прошлое. Фактически, речь идет о не-разработчиках, не проходивших специального обучения, на которых тем не менее возложена ответственность за конфигурирование приложений. Я встречал несколько «гражданских разработчиков», так что они действительно существуют, но я обнаружил, что хорошие их представители быстро учатся кодировать на базовом уровне и свободно пользуются своим набором инструментов из разряда low-code. Однако большинство «гражданских разработчиков» знают только то, что им нужно, об инструментах, которые им необходимы для выполнения их обязанностей, оставляя собственно программирование другим людям.

В преимущества разработки low-code?

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

Когда следует использовать разработку low-code?

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

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

Исследование рынка, проведенное компанией Enterprise Management Associates, показало, что специалисты, отвечающие в компаниях за сетевую инфраструктуру и операции, признают ценность применения AIOps при организации управления сетью.

Использование искусственного интеллекта в ИТ-операциях (Artificial Intelligence for IT Operations, AIOps) – развивающийся класс технологий, который объединяет машинное обучение, большие данные и другие виды продвинутой аналитики для автоматизации процессов управления ИТ. По сути, AIOps сопоставляет и анализирует различные наборы данных об ИТ-операциях, выявляет закономерности, делает на основании этих закономерностей определенные выводы и предоставляет соответствующую информацию персоналу ИТ-службы.

Недавно EMA опубликовала отчет «Революционные перемены в управлении сетью с помощью AIOps» ('Revolutionizing Network Management with AIOps'). Результаты проведенного опроса показали: 90% специалистов по компьютерным сетям убеждены в том, что использование AIOps при организации управления сетью может привести к улучшению бизнес-результатов предприятия в целом. Люди, решившие выйти за рамки этапа исследований, чтобы получить практический опыт работы с AIOps, оценивают потенциальные преимущества с наибольшим энтузиазмом.

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

Преимущества AIOps при организации управления сетью

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

— оптимизация сети;

— операционная эффективность;

— повышение уровня безопасности и соблюдение нормативных требований.

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

Оптимизация существующих инструментов управления сетью

В EMA поинтересовались, связан ли интерес специалистов по сетям к AIOps с недостатками существующих инструментов управления сетью. Выяснилось, что 91% опрошенных надеются устранить имеющиеся недостатки инструментов с помощью AIOps. Чаще всего при этом назывались следующие возможности:

— устранение противоречий и неточностей в данных;

— компенсация нехватки информации в реальном времени;

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

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

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

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

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

Архитектор операций машинного обучения (MLOps) и DevOps в GitLab Монмаюри Рэй попробовала пояснить, какое влияние машинное обучение оказывает на изменение порядка прогнозирования и принятия решений.

Экономическая модель искусственного интеллекта

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

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

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

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

Bing: меняться надо быстрее

По мнению Рэй и ее коллеги из GitLab, утверждение это хорошо иллюстрируется неспособностью Bing конкурировать с поисковыми технологиями Google на любом более или менее существенном уровне. С учетом того, что Microsoft Bing занимает менее 3% мирового поискового рынка, в операционном плане соответствующая технология отличается от технологии Google из-за соответствующих циклов обратной связи и увеличения времени, затрачиваемого на переосмысление рекомендаций Bing, которые, по сути, формируются за счет функций машинного обучения.

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

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

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

Генеральный директор компании OctoML Луис Сезе пытается решать соответствующие задачи совместно с сооснователем компании и ее директором по продуктам Джейсоном Найтом. Оба они активно высказываются на тему того, как использовать машинное обучение для улучшения самого машинного обучения.

Миллиарды вычислений для одного алгоритма

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

«В условиях, когда машинное обучение становится все более и более популярным (в сферах компьютерного зрения, NLA/NLP, производства контента и т.д.), объем вычислительных мощностей, которые требуются для машинного обучения, непомерно растет, – констатируют Сезе и Найт. – Во многих случаях (возьмем какую-нибудь масштабную модель, например, GPT-3) разработчики выполняют миллиарды и миллиарды вычислений, чтобы получить от алгоритма лишь один ответ».

Созданный на базе Apache TVM проект OctoML предназначен для упрощения производственного запуска моделей машинного обучения за счет автоматического повышения производительности моделей на любом оборудовании в популярных средах машинного обучения Pytorch, TensorFlow и ONNX. Еще раз, речь здесь идет об автоматизации развертывания самой модели машинного обучения.

Тестирование программ и возможности тестирования

Возвращаясь к GitLab, стоит отметить, что свет в конце тоннеля уже виден. Опрос GitLab DevSecOps Survey 2021 свидетельствует о расширении использования программных ботов машинного обучения для создания программного обеспечения на этапе тестирования.

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

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

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

Как меняет карьеру бизнес-образование? Чему и на каком этапе важно учиться? Об этом, а также о направлениях цифровой трансформации крупнейшего транспортного холдинга страны рассказывает Сергей Висленев, первый заместитель генерального директора компании «РЖД-Технологии», которая служит проектным офисом масштабной стратегии цифровой трансформации РЖД.

- Несколько лет назад вы проходили обучение по программе MBA CIO в Высшей школе бизнес-информатики ВШЭ. С какой целью решили получить бизнес-образование?

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

- То есть в первую очередь MBA решает проблему коммуникативную?

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

- Почему вы выбрали именно программу MBA ВШБИ ВШЭ?

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

При выборе конкретной программы я анализировал два аспекта: первый — отзывы коллег, которые уже проходили эту программу, и второй — преподавательский состав. В MBA интересны не столько наименование дисциплин, сколько фигуры преподавателей. Для меня было очень важно, что эти люди имеют существенный вес в сообществе ИТ-руководителей и вносят значимый вклад в его развитие. Например, Андрей Коптелов играет существенную роль в развитии сообщества BPM, Роман Журавлев — сообщества ITIL, и этот список можно продолжить. Это лидеры направлений, чье видение мне хотелось понять.

- Какие изменения произошли в вашей карьере благодаря этому обучению?

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

Я пришел в 2001 году в петербургский железнодорожный институт «Ленгипротранспуть» инженером технической поддержки, занимался эксплуатацией информационных систем, а впоследствии — цифровизацией проектной деятельности в железнодорожной отрасли на достаточно серьезном уровне. Как раз после окончания курса MBA я возглавил компанию, занимавшуюся разработкой программных продуктов для управления эксплуатацией железнодорожных телекоммуникационных систем, и три года в ней трудился. В 2020 году стал победителем всероссийского управленческого конкурса «Лидеры России» и перешел в цифровой блок РЖД — в компанию «РЖД-Технологии», проектный офис цифровой трансформации РЖД. Я работаю в железнодорожной отрасли с 17 лет. «Цифра» в РЖД — это та сфера, которая меня привлекает и мотивирует.

Роль MBA на этом пути довольно существенна: полученный базис сильно помог мне на позиции руководителя предприятия и помогает сейчас решать задачи уровня холдинга РЖД. Понятно, что MBA не является «билетом в счастье», но это правильный и для многих необходимый шаг, который дает эффект.

- А помимо этого базиса, что еще помогло достичь поставленной цели?

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

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

Я занимаюсь проектами цифровой трансформации в РЖД. Холдинг ведет масштабную программу цифровизации, затрагивающую все области производственной и непроизводственной деятельности (от перевозочного процесса и взаимодействия с клиентами до внутренних коммуникаций), внедряет самые актуальные технологии.

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

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

Среди важнейших проектов, которые я курирую, — Интернет вещей и применение возможностей, которые он предоставляет в телеметрии, а значит — в области эксплуатации крупных территориально распределенных инфраструктур. В этой области мы реализуем целую серию проектов, которые особенно важны для РЖД с учетом гигантских пространств Российской Федерации и протяженности железных дорог. Фактически Интернет вещей открывает для РЖД новую телеметрию, «переизобретает» ее, дает возможность построить цифрового двойника инфраструктуры на абсолютно новом уровне: вы не просто опосредованно получаете информацию о проектном и текущем состоянии какого-то участка пути или объекта сети, а имеете данные обо всей сети в режиме онлайн. Раньше это было невозможно сделать в пределах разумной экономической эффективности, потому что классическая телеметрия построена на проводах и требует наличия электропитания. Современные же сети Интернета вещей построены на технологиях, которые позволяют охватывать до ста квадратных километров на одну базовую станцию. Один датчик может работать автономно от 5 до 10 лет. Использование этих простых элементов дает впечатляющий результат — живую инфраструктуру, реально демонстрирующую свое состояние онлайн, причем на всех участках. Особенно важна эта технология на Восточном полигоне.

Второе важнейшее направление, которым мы сейчас активно занимаемся, — новая цифровая среда сотрудников. В начале пандемии компания очень быстро перестроилась: в РЖД за 10 дней перевели на удаленную работу более 100 тыс. сотрудников. Это фантастический результат работы команды.

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

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

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

Все эти возможности, как созвездия, растут вокруг простой идеи: сотрудники должны коммуницировать по-новому. И это именно то, что сейчас трансформирует РЖД и чем мы занимаемся.

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

Я рекомендую еще до прихода в ИТ-отрасль развивать свои знания, подтверждая их сертификациями. Считаю, что всем специалистам по эксплуатации важно знать концепцию ITIL, а экзамен ITIL Foundation или его аналог требуется сотрудникам уже на уровне Help Desk. Специалисту по эксплуатации важна «продвинутая» сертификация ITIL, в первую очередь по созданию сервисов.

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

Специалисты по разработке ПО (особенно начинающие), по информационной безопасности, тестировщики, cдавайте сертификационные экзамены по своему направлению. Это вам сильно поможет.

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

А кроме MBA, рекомендую всем «цифровизаторам» получать формальное образование в той отрасли, где они долго работают (транспорт, нефтегаз, телекоммуникации, госуправление). Эффект будет потрясающим, поверьте.

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

От чего зависит скорость

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

И все же, многое в таком «скоростном» внедрении зависит от входных условий. К ключевым можно отнести:

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

И, главное, табу на фундаментальное изменение методологии учета или бизнес-модели на время внедрения.

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

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

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

Возможность для «творчества»

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

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

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

Процессы имеют значение

В последние годы на рынке возрастает интерес к технологии Process Mining (высокоуровневый мониторинг и корректировка бизнес-процессов на основе точных данных). Пока внедрение таких решений буксует, как правило из-за низкой готовности входных данных – их качества и уровне доверия к ним. Тем более сложно крупным предприятиям соотносить свои реальные процессы с «отрисованными» в методологии учета. Конечно, приведение всего этого в порядок требует много времени и ресурсов; соответственно, некоторые компании просто не в состоянии довести начатое до конца.

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

Не патриотизма ради

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

Хотелось бы обратиться и к «собратьям по отрасли». Коллеги, послушайте! У нас самая большая страна в мире, лучшие ИТ-специалисты и программисты, на которых есть спрос на всей планете. Ну давайте уже не будем игнорировать и забывать о собственных успехах. Давайте вместе будем наращивать присутствие отечественных решений, а не зарубежных. Сегодня – в России и в Восточной Европе. А в будущем – …

Автор – Александр Казеннов, руководитель корпоративной практики ДКИС ALP Group

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

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

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

Когда не хватает экспертизы

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

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

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

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

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

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

Больше, чем аутсорсинг

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

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

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

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

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

Автор — Кирилл Владимиров, генеральный директор компании ONLY

Сфера роботизации и автоматизации процессов — RPA (Robotic Process Automation) активно развивается, и все больше компаний применяют RPA-решения в своих бизнес-процессах. Согласно отчету Grand View Research, к 2027 году рынок RPA превысит 25 млрд долл., при этом среднегодовой темп роста составит более 40%. Разработчики таких решений предоставляют бизнесу платформы для создания «цифровых сотрудников». Цифровой сотрудник – это главный компонент платформы, программный робот, выполняющий действия с программным обеспечением на рабочем столе. Дополнительные компоненты платформы позволяют анализировать бизнес-процессы, автоматизировать их, и контролировать выполнение в продуктивной среде.

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

Интеллектуальная эффективность

Сама по себе RPA-платформа способна автоматизировать многие бизнес-процессы, базирующиеся на разных технологических платформах (Windows Desktop, Web, Mainframe, Java, Web Services, API). Гибкость интеграции достигается путем использования различных способов взаимодействия с пользовательской средой робота. Один из способов предполагает, что робот может имитировать действия человека и работает с целевым приложением напрямую, при этом целевое приложение «не знает», что им управляет робот. То есть стандартный процесс работы сохраняется без каких-либо дополнительных изменений, и робот просто заменяет человека. В других случаях могут использоваться и системные функции. Например, робот может не использовать проводник (пользовательский интерфейс), управляя файлами с помощью системных команд. Работая с таблицами и базами данных, робот может обойти пользовательский интерфейс и работать напрямую с данными через API, что существенно повышает производительность.

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

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

Аналитика: обнаружение процесса и идентификация действий

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

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

Распознавание текстов

Распознавание текста (Optical Character Recognition, OCR) включает в себя распознавание графических символов, курсива, а также неструктурированных данных. Данные технологии используются для автоматизации приложений, к которым невозможно подключиться на системном уровне, и для работы с текстовыми файлами, из которых невозможно выделить текст – например, из PDF-файлов отсканированных документов. Таким образом можно обрабатывать счета-фактуры, чеки, приходные ордеры и другие стандартизированные (но не обязательно структурированные) документы. Подобное использование ИИ приводит к сквозной автоматизации процессов. Люди поддерживают роботов и обрабатывают документы только в тех случаях, когда робот не уверен в дальнейших действиях.

Благодаря технологиям на базе ИИ доступны также дополнительные возможности по распознаванию текста. Они требуются для более умного использования оцифрованных документов – в случаях, если в документе есть таблицы или разное расположение текста. Например, разработчики предлагают продукты для работы с графическими документами, относящиеся к семейству IDP (Intelligent Document Processing). IDP отличается от OCR тем, что помимо конвертации графического текста в цифровой, также может определить тип документа и находить поля, меняющие свое местоположение. IDP проходит наблюдаемое обучение, где аналитик поправляет выстроенную концепцию документа. Очень удобно, когда OCR и IDP предоставляют не только распознанный текст, но и оценку уверенности в правильности оцифровки. Большинство решений по распознаванию текста не гарантируют 100% корректное распознавание, однако ИИ технологии помогают минимизировать ошибки даже в сложно структурированных документах.

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

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

Распознавание изображений

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

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

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

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

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

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

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

Возможности для повышения эффективности обслуживания клиентов

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

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

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

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

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

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

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

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

Что нас ждет в будущем?

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

Автор – Кристиан Уэллс (Christian Wells), эксперт по роботизации процессов, руководитель клиентского офиса Blue Prism в России (russia@blueprism.com)

Согласно исследованию, проведенному Okdesk, из почти 100 интеграторов транспортной телематики 65% понимают, что на сервисных услугах можно зарабатывать больше. Но примерно четверть из этих компаний не знает, как начать продавать такие услуги. Похожая ситуация и на всем российском рынке сервисного обслуживания.

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

В чем проблема

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

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

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

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

Шаги по решению этой проблемы

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

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

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

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

Работая по такой модели, компания сможет варьировать стоимость часов или услуг в соответствии с разными уровнями обслуживания (Service Level Agreement, SLA). К примеру, если клиенту необходимо решить вопрос быстрее или для выполнения заявки нужен сотрудник более высокой квалификации, час специалиста может стоить дороже в соответствии с прописанной в договоре схемой.

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

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

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

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

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

6. Важно заранее предупредить, что бесплатная или безлимитная поддержка скоро закончится. Для этого компании нужно подготовить объяснение, почему и кому выгодно работать по-новому. Для клиента аргументом может быть SLA — обязательство компании отреагировать на заявку в течение определенного времени.

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

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

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

Автор - Кирилл Федулов, сооснователь и директор по развитию сервиса Okdesk