Парадокс автоматизации

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

Действительно ли необходимо уделять этому аспекту столько внимания? Например, в черновике готовящейся к выходу книге ITIL®4 Create, Deliver and Support (CDS) («Создание, предоставление и поддержка») объём текста про организацию, культуру, команды, взаимодействие и сотрудничество не меньше, чем про технологии (AI, AIOps, RPA, CI/CD, ML и т.п. и т.д.).

На мой взгляд, интересный штрих к этому «противопоставлению» добавляет опубликованный пару недель назад отчёт Forrester «Остерегайтесь парадокса автоматизации» («Beware The Automation Paradox»). Чарльз Бетц (Charles Betz) коротко описывает суть в корпоративном блоге.

Оказывается, ещё в 1982 году Лизанн Бэйнбридж написала в британский научный журнал «Автоматика» статью «Ирония автоматизации», в которой исследовала парадокс, заключающийся в том, что автоматизация производственных процессов с участием человека в качестве оператора может усиливать, а не устранять проблемы.
Спустя 30 лет, в 2012 году команда британских учёных подтвердила актуальность проблемы («The ironies of automation … still going strong at 30?»).

В приложении к ИТ коллеги из Forrester описывают проявление парадокса следующим образом.

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

Увеличение скорости релизов, с одной стороны, увеличивает скорость восстановления, снижая среднее время простоя.
С другой стороны, более быстрые и частые изменения ведут к сокращению эффективного жизненного цикла статей базы знания и, следовательно, к увеличению времени, затрачиваемого на восстановление (MTTR). Так как для каждого инцидента или дефекта растёт вероятность того, что потребуется более высокий уровень компетенции для того, чтобы с ним разобраться.
И это, похоже, не просто теория. Авторы отчёта утверждают, что по данным от производителей систем автоматизации ITSM Atlassian и Zendesk наблюдается сокращение жизненного цикла статей базы знания.
По данным авторов, несколько крупных компаний, с которыми они работают, сообщили о постепенном увеличении среднего времени восстановления.

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

Эта идея не то, чтобы сверхсложная. Но она точно не лежит на поверхности. Также, как соображения по поводу того, что с этим всем делать. При проектировании и построении систем нужно учитывать человеческий фактор («человеко-центричное» проектирование систем); особое внимание на взаимодействие (человек-система, человек-человек); вопросы культуры (в частности культура с отказом от поиска крайнего, blameless culture) и т.д. и т.п.

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

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

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

DevOps Основы DevOps

Популярный трёхдневный учебный курс
 

Проект Феникс — DevOps на практике

Полезная деловая игра для вашей команды
 

Узнайте больше!

Комментарии и мнения

  1. Владимир Невский

    Интересная мысль. Да, парадокс автоматизации существует: чем более эффективны автоматизированные системы, тем более важно участие в них людей. Нужно помнить два правила от Билла Гейтса: 1. Автоматизация эффективной операции повышает её эффективность. 2. Автоматизация неэффективной операции увеличивает её неэффективность. Поэтому важно не изобретать велосипед, а пользоваться методологией/проверенными инструментами автоматизации и помнить, что иногда эффективнее изменить свои бизнес процессы под эффективную технологию, чем автоматизировать свои «эффективные» операции.

    1. Игорь Гутник Автор

      Владимир, спасибо за дополнение!

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

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

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

      1. Ирина Волкова

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

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

        1. Игорь Гутник Автор

          Ирина, согласен с первым абзацем.

          Но утверждение «период «автоматизации» уже прошел» мне кажется слишком сильным.

          Вокруг много примеров «автоматизации» деятельности. Например, работа операторов АЭС, или пилотов самолётов и т.п. А также автоматизация более близких к повседневной жизни обычного человека процессов — работа операциониста в банке, кассира в магазине. Работа в рамках любых бизнес-процессов. Ну, и, конечно, наш любимый ITSM. Работа по управлению услугами тоже ведь может быть автоматизирована на многих участках.

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

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

          Так что «усмешки автоматизации» мы будем наблюдать ещё долго.

          Направлений приложений усилий существует, кажется, только два.

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

          2. Обеспечивать нормальную интеграцию двух разнородных компонентов системы (человек и «автомат»)

          Я в заметке говорил о втором. Точнее, рассуждал на тему «актуальный вопрос, или выдумки?» 🙂

  2. Андрей другой

    Лично мне кажется, что основная проблема автоматизации не в сдвиге «влево»(...доля сложных задач, выполняемых людьми, возрастает.), а в деградации квалификации исполнителей. Один из ярких и страшных примеров — катастрофа SJ100 в Шереметьево. В результате инцидента вышли из строя (отключились) системы автоматизации, но самолет был полностью жизнеспособен и мог лететь в ручном режиме. Только вот летчики уже без систем автоматизации летать не умеют и банально разбили самолёт при посадке. У меня есть еще несколько примеров подобного рода, хоть и менее трагичных. Касаемо ITIL — мне кажется с ростом автоматизации надо существенно большее внимание уделять процессам мажорных инцидентов (major incident), порядку действия персонала при выходе ИТ системы(сервиса) из строя. Не устранению сбоя, а действиям в «ручном» режиме, когда уже ясно, что восстановить ИТ систему в сроки без катастрофических последствий не удастся.

    1. Игорь Гутник Автор

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

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

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

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

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

      1. Андрей другой

        Я не вижу в вашем замечании противопоставления моему высказыванию.

        Автоматизация — хорошо, но она не должна порождать заблуждение что теперь нам сами ничего не надо уметь делать. Я говорю о том, что с ростом автоматизации возрастает роль Major Incident Management, а именно — поддержание квалификации сотрудников на уровне, достаточном для выполнения операций вручную. Еще пример, менее драматический. В Америке (не самая отсталая страна) возникла ситуация с переоформлением билетов с компании на компанию. Молодежь на стойке не смогла справиться с этой ситуации и только сотрудник сторонней компании смог помочь — женщина в чужой системе сделала все нужные операции. Так вот, ей было лет под 60 и она просто понимала суть того, что она делает. Молодежь — лет по 30 просто знала некоторую последовательность действий, но не понимала суть того, что они делают. Еще пример — положительный. В службе управления ИТ одного из крупных западных аэропортов я заметил плакаты порядка А0 с распечатанными на них схемами сети. На мой вопрос зачем, если у них есть мощная система мониторинга, где эти схемы и так есть, они мне ответили — а вдруг система мониторинга выйдет из строя? Мы тогда по этим плакатам сможем продолжить поддержку ИТ инфраструктуры.

  3. Максим Афонасьев

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

    1. Игорь Гутник Автор

      Максим, интересное замечание. Про возрастание значимости «человеческой» в работе человека согласен.

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

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний: