Что такое ошибка автоматизации

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

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

Ошибка № 1: Сделать ставку только на одну технологию

После того, как организация успешно приобрела и внедрила определенный инструмент автоматизации процессов, например RPA (robotic process automation, роботизированная автоматизация процессов) вполне естественно желание применять его как можно более широко.

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

Ошибка № 2: Верить в то, что бизнес может автоматизироваться без ИТ

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

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

Ошибка № 3: Думать, что автоматизация решает все проблемы

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

Совет: Оцените преимущества и недостатки автоматизации по сравнению с заменой системы, дополнительной функциональностью и стратегией интеграции.

Ошибка № 4: Не привлекать все заинтересованные стороны

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

Читайте по теме: Почему руководители опасаются цифровизации и что с этим делать

Совет: Возложите ответственность за взаимодействие с профильными отделами на конкретного члена экспертной группы.

Ошибка № 5: Не уделять достаточно времени тестированию

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

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

Ошибка № 6: Тратить усилия на чрезмерно сложные процессы

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

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

Ошибка № 7: Относиться к автоматизации как к простому воспроизведению действий

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

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

Ошибка № 8: Не контролировать систему после внедрения автоматизации

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

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

Ошибка № 9: Использовать неверные метрики для оценки результатов

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

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

Ошибка № 10: Игнорировать культуру и влияние на сотрудников

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

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

Источник.

Фото на обложке: Gorodenkoff / Shutterstock

Автоматизация тестирования

Автоматизация тестирования абсолютно неотъемлема и необходима в современной разработке программного обеспечивания. Ее преимущества известны всем, что делает автоматизацию тестирования желанным для применения. Факт, отказ от ручного тестирования, сокращение затрат и автоматизация в спринте (in-sprint automation) подталкивают компании внедрять автоматизацию как можно скорее в собственные проекты. У каждой компании свой подход к достижению цели. Однако, они все совершают одинаковые ошибки в процессе внедрения автоматизированного тестирования.

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

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

Жизненный цикл автоматизированного тестирования

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

1. Планирование автоматизации.

2. Проектирование/разработка автоматизации.

3. Внедрение и выполнение автоматизации.

4. Поддержка и улучшение автоматизации.

Я хотел бы представить распространенные ошибки в каждом из 4 этапов. Давайте посмотрим на них.

1. Ошибки на этапе планирования автоматизации

1. Не рассчитана окупаемость инвестиций (ROI).

2. Нет плана автоматизации/цели автоматизации.

3. Не определен и не приоритизирован объем тестирования перед стартом автоматизации.

4. Отсутствие задокументированных требований к среде автоматизации/нереалистичные ожидания.

5. Выбран неправильный уровень тестирования для автоматизации.

6. Выбор инструментов, так как они open-source или бесплатные.

7. Выбор неправильных инструментов автоматизации.

8. Выбор инструментов на основе навыков команды.

1.1 Не рассчитана окупаемость инвестиций (ROI)

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

Решение проблемы — с помощью формулы ниже рассчитать ROI в автоматизацию.

RIO = «Затраты ручного тестирования, которые уменьшает автоматизация» — («Затраты на автоматизацию» — «Затраты на поддержку автоматизации»)

1.2 Нет плана автоматизации/цели автоматизации

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

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

1.3 Не определен и не приоритизирован объем тестирования перед стартом автоматизации

Обычно говорят «нельзя улучшить то, что нельзя измерить», что верно при запуске проектов автоматизации. Как мы можем начать ее без определения объема тестирования? Без этого мы не можем измерить и сравнить результаты автоматизации. Без определения объема мы будем неуверенными на каждом этапе тестирования.

Решение проблемы — определить объем тестирования

1.4. Отсутствие задокументированных требований к среде автоматизации/нереалистичные ожидания

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

Решение проблемы:

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

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

1.5. Выбран неправильный уровень тестирования для автоматизации

Часто тестировщики фокусируются на автоматизации UI тестов для обеспечения end-to-end тестирования вместо интеграционных, API и БД тестов. Автоматизация нижних уровней тестирования обеспечит лучшее и детальное тестовое прикрытие с большей скоростью и меньшими затратами. UI тесты медленные и их дорого поддерживать. При этом мы не можем исключать тестирования UI, особенно для продуктов ориентированных на пользователя и продуктов Saas, но можем свести его к минимуму.

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

1.6. Выбор инструментов, так как они open-source или бесплатные

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

Разработка среды автоматизации — это, по сути, тот же процесс, что и разработка других бизнес приложений командой разработчиков. Это словно полноценный проект разработки, который должен иметь свои строгие стандарты жизненного цикла программного обеспечивания (SDLC). Разработчики среды автоматизации должны иметь тот же уровень компетенций, что и разработчики приложений. Потому, что возникает необходимость в процессах проверки кода, архитектуры, утверждении дизайна среды, тестировании, соблюдении стандартов кодирования, управлении кода и т.д. Если мы ожидаем качественный результат от автоматизации, разработанная среда автоматизации должна соответствовать всем практикам (best practices) SDLC.

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

Решение проблемы:

• Использовать best practices для разработки среды автоматизации, которым следуют разработчики бизнес приложений.

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

1.7 Выбор неправильных инструментов автоматизации

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

Решение проблемы:

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

• Применяя POC, использовать пробный период выбранного инструмента.

1.8 Выбор инструментов на основе навыков команды

Еще одна проблема заключается в выборе инструмента основываясь на навыках команды. Мир движется к no-code решениям и автоматизированное тестирования тоже. No-code инструменты автоматизации обеспечат более быструю работы без дополнительных навыков.

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

2. Ошибки на этапе проектирования/разработки автоматизации

1. Нет дизайна разрабатываемой системы.

2. Нет обработки исключений.

3. Неправильный механизм логирования.

4. Нет стратегии управления кодом/ветками и управления выпуском.

2.1 Нет дизайна разрабатываемой системы

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

• Неструктурированные модули/монолитное приложение.

• Неправильные паттерны проектирования.

• Неприменение best practices.

• Нет процесса ревью кода.

• Низкая возможность переиспользование кода.

• Отсутствие модульности на функциональном уровне.

• Нет этапа тестирования самой среды автоматизации.

2.2. Нет обработки исключений

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

Решение проблемы — все типы исключений должны быть обработаны на каждом функциональном уровне. Код должен пройти процесс ревью для исключения отсутствия обработки исключений.

2.3 Неправильный механизм логирования

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

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

2.4 Нет стратегии управления кодом/ветками и управления выпуском

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

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

3. Ошибки на этапе внедрения и выполнения автоматизации

1. Отсутствие определения объема тестирования.

2. Нет стратегии управления данными.

3. Автоматизация больших потоков.

4. Не проводится проверка тестов.

3.1 Отсутствие определения объема тестирования

Отсутствие определения объема тестирования приведет к отсутствию планирования на этапе внедрения автоматизации. Мы не сможем измерить результат работы по написанию тестовых скриптов.

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

3.2. Нет стратегии управления данными

Среда автоматизации должна иметь правильную стратегию управления данными. Хранение данных в файлах  excels, csv и т.п. устарело и замедляет выполнение тестов. Также, переменные с тестовыми данными не должны храниться в коде скриптов.

Решение проблемы — среда автоматизации должна иметь возможность хранить и предоставлять тестовые данные в удобном формате JSON, XML и т.п.

3.3 Автоматизация длинной бизнес логики

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

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

3.4. Не проводится проверка тестов

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

Решение проблемы — получить подтверждение правильности скриптов от заинтересованного лица. Заинтересованным лицом может быть бизнес аналитик или QA.

4. Ошибки на этапе поддержки и улучшения автоматизации

1. Нет обновления кода скриптов при изменении функционала тестируемого приложения.

2. Редкие запуски тестов.

3. Зависимость от члена команды.

4.1 Нет обновления кода скриптов при изменении функционала тестируемого приложения

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

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

4.2 Редкие запуски тестов

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

• Не реализация потенциала автоматизации и недостаточное тестирование приложения.

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

Решение проблемы — Запуск автоматизации на отдельно выделенной машине обеспечивает работу скриптов в любое время и без потери времени автоматизатора. Еще лучшим подходом является интеграция запуска тестов в CI/CD.

• Решение проблемы —

  Запуск автоматизации на отдельно выделенной машине обеспечивает работу скриптов в любое время и без потери времени автоматизатора. Еще лучшим подходом является интеграция запуска тестов в CI/CD.

4.3 Зависимость от члена команды

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

Решение проблемы — Создать и использовать общие ID, предоставлять доступ к приложению по общему ID и запускать тесты используя общей ID.

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

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

1. Не рассчитана окупаемость инвестиций (ROI).

2. Нет плана автоматизации/цели автоматизации.

3. Не определен и не приоритизирован объем тестирования перед стартом автоматизации.

4. Отсутствие задокументированных требований к среде автоматизации/нереалистичные ожидания.

5. Выбран неправильный уровень тестирования для автоматизации.

6. Выбор инструментов, так как они open-source или бесплатные.

7. Выбор неправильных инструментов автоматизации.

8. Выбор инструментов на основе навыков команды.

Проектирование/разработка автоматизации

1. Нет дизайна разрабатываемой системы.

2. Нет обработки исключений.

3. Неправильный механизм логирования.

4. Нет стратегии управления кодом/ветками и управления выпуском.

Внедрение и выполнение автоматизации

1. Отсутствие определения объема тестирования.

2. Нет стратегии управления данными.

3. Автоматизация больших потоков.

4. Не проводится проверка тестов.

Поддержка и улучшение автоматизации

1. Нет обновления кода скриптов при изменении функционала тестируемого приложения.

2. Редкие запуски тестов.

3. Зависимость от члена команды.

Выводы

Мы пришли к выводу, что разработка среды автоматизации также сложна, как и разработка бизнес-приложений. Становится понятно почему совершается много ошибок, если процессу разработки среды не уделять должного значения, не соблюдая best practices или не используются правильные ресурсы и навыки. Также, open-source инструменты не дают ожидаемого эффекта. Если организация не заинтересована в развитии средств автоматизации тестирования, это знак к использованию готовых решений, которые обеспечат более высокую ROI за счет уменьшений расходов на разработку и поддержку собственной среды. Особенно в случае маленьких компаний будет сложно обосновать ROI, поскольку они имеют меньшую экономическую гибкость.

Автор: Тоби Стид (TobySteed)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Я видел это очень часто – проект по внедрению тест-автоматизации (не обманывайте себя – это именно проект) получает один-единственный тикет. Как только это ошибка завершена – я практически гарантирую, что ваше видение тест-автоматизации никогда не будет воплощено.

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

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

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

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

Ниже – пять моментов, которые помогут вам спланировать и запустить успешный проект по тест-автоматизации:

1. Неважно, каким инструментом отслеживания вы пользуетесь – JIRA, Azure, Favro– создайте отдельный проект/пространство для тикетов по тест-автоматизации. Проведите декомпозицию, как для любого другого проекта, создайте эпики, стори, задачи, спайки. Сделайте спринты и релизы с четкой целью, чтобы вам было к чему стремиться и чего достигать, а не просто бесцельно копаться в тикетах.
2. Планируйте долгосрочно. Не будьте близоруким, не стремитесь к быстрым выигрышам. Возможно, это поможет вам запуститься быстрее, но зачастую приведет к серьезным проблемам позднее. Выбирайте инструменты и технологии, основываясь на долгосрочных целях. Идти на компромисс в некоторых аспектах, чтобы стартовать побыстрее, нормально, но не стройте фундамент своих автотестов на краткосрочных целях.
3. Убедитесь, что у вас есть способ запустить эти тесты. Неважно, виртуальная ли это лаборатория, облако или физическая машина. Избегайте необходимости запускать тесты на собственной машине. Если это все, что у вас есть сейчас, то это лучше, чем ничего, но со временем ваши тесты будут прогоняться дольше, и их эффективный прогон заставит вас сидеть на руках в ожидании, когда они завершатся.
4. Не работайте в одиночку, пусть вам помогут разработчики. Для действительно успешной тест-автоматизации вам нужна поддержка разработчиков, и нет ни одной причины для них не участвовать в таком проекте – неважно, в создании тестов, работе с фреймворком или даже прогоне тестов. Вам необходимо сотрудничать с разработчиками, чтобы убедиться, что ваша система непрерывной интеграции правильно и эффективно настроена – это важно для успешного проекта по тест-автоматизации.
5. Настаивайте, настаивайте, настаивайте еще. В ходе проекта вы с гарантией столкнетесь с препятствиями. Вам понадобится лицензия, настройка окружения, или что-то тривиальное, вроде необходимых прав. В зависимости от того, как далеко надо тянуться для решения этих вопросов, и количества канцелярщины, связанной с заказом и оплатой лицензии, может показаться, что вы тут бессильны, или что это вне вашей компетенции. Не сидите и не ждите милостей от природы! Не бойтесь быть навязчивым. Я столько раз видел, как препятствие заставляло большой проект, набравший высокую скорость, тормозить со скрежетом – а потом все сидели и ждали, чтобы кто-то что-нибудь с этим сделал. Со временем, если проект еще не дает отдачи, бороться за ресурсы и поддержку будет все сложнее. Не давайте вашим усилиям пропасть втуне, потому что вы столкнулись с препятствием.

От трагедии до курьеза

1 сентября 1983 года Boeing 747 южнокорейских авиалиний вылетел из аэропорта Анкориджа, направляясь в Сеул. Полет капиталистического воздушного судна должен был проходить над Тихим океаном восточнее Камчатки, огибая воздушное пространство Советского Союза. Экипаж поднялся на необходимый эшелон и включил автопилот. Последний, однако, был настроен неправильно, и вместо изящной дуги мимо оплота коммунизма, повел самолет по прямой – над территорией СССР. Несмотря на изменение курса, экипаж не стал проверять его и корректировать автопилот, положившись на автоматику. В результате произошла одна из самых известных авиакатастроф того времени – авиалайнер был сбит советскими истребителями над Сахалином.

Доверие к автоматике приводило не только к трагедиям, но и курьезам, таким как случай с канадкой, GPS-навигатор которой посоветовал ей заехать в озеро Гурон
– что она и сделала, чуть не утонув.

Эти случаи объясняются не столько глупостью, сколько более сложным и комплексным явлением, носящим нейробиологическую природу – automation bias. В русскоязычной литературе еще не установилась как такого общепринятого перевода данного термина. Однако перевод с английского дает представление о его содержании: bias – это и ошибка, и предвзятость, и пристрастность, и уклонение, и субъективность, т.е. любое отклонение от объективности. Наиболее точно перевести automation bias можно как «искажение, вызванное автоматизацией», или просто «ошибка автоматизации», так как психология и когнитивистика относят automation bias к разряду когнитивных искажений/когнитивных ошибок.

Что такое automation bias?

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

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

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

Исследования и предотвращение

Исследовать феномен automation bias начали еще в конце 90-х годов прошлого века, когда системы поддержки принятия решений только начали применяться в космонавтике, пилотировании, управлении атомными электростанциями и в отделениях интенсивной терапии. Одним из наиболее значимых в это время стало совместное исследование Линды Скитки (факультет психологии университета Иллинойса), Кэтлин Мозьер (университет Сан-Франциско) и Марка Бурдика (Исследовательский центр NASA), результаты которого были опубликованы в 1999 году в авторитетном американском журнале Human-Computer Studies.

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

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

1. Трэкинг. Участник должен был в течение всего полета (параллельно с выполнением других задач) удерживать с помощью джойстика изображение самолета в рамках круга, смещение которого генерировались компьютером. Участник должен был постоянно следить за тем, чтобы «самолет» оставался в границах этой зоны, компенсируя отклонения выравниваем самолета по вертикали и горизонтали.
2. Путевые точки. Путевые точки. Участник должен был отслеживать свое местоположение на карте. Иконка «самолета» перемещался по экрану-карте слева направо. Красные и синие треугольники на его пути обозначали радиовышки: при прохождении через них участник должен был нажать специальную кнопку соответствующего цвета, имитируя отправку сигнала о своем местоположении.
3. Калибровка. В нижнем углу экрана отображались четыре датчика, непрерывно перемещающиеся в рамках диапазона нормальных показаний. Каждый из них или все вместе датчики могли рандомно выйти за пределы диапазона нормы. Когда один из датчиков показывал ненормальное значение, участник должен был нажать соответствующую кнопку датчика; если все датчики выходили за пределы диапазона, участник должен был нажать кнопку «сброс датчиков». Датчики были запрограммированы вернуться к нормальному значению через 10 секунд, если участник не нажал ни одной кнопки, т.е. не заметил события.

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

Участники эксперимента были разделены на две группы. Первая группа проходила испытания-полеты с автоматизированным средством мониторинга (AMA). У этой группы в верхнему углу экрана появлялись объявления АМА, которые оповещали участника о каком-либо событии (например, перемещении показателей датчиков за пределы нормального диапазона), а также рекомендовали совершение конкретных действий (например, нажать кнопку «сброс датчиков»). Участники были проинструктированы, что АМА не является совершенным средством и может давать сбои. Вторая часть участников проходила испытания без AMA.

Экспериментом было предусмотрено, что за все 8 полетов АМА «не сработает» 6 раз, то есть средство автоматизации не предупредит участника о 6 событиях из 100, на которые он должен отреагировать. Интерес представляло, сколько участников из первой группы пропустят эти события, положившись на компьютер, а также каково будет их соотношение с числом участников из второй группы, пропустивших то же самое событие.

Результаты опыта показали, что участники, использовавшие АМА, допустили больше пропусков 6 выделенных событий, чем участники, не пользовавшиеся АМА. Коэффициент точности первой группы в этих событиях составил 59%, когда как второй – 97%.

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

во-первых, усовершенствованы сами программы автоматизации и рекомендаций, повышена их точность и надежность;

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

Это позволило существенно нивелировать риски automation bias в таких сферах, как пилотирование, работа больниц и электростанций.

Новая опасность

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

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

Эти обстоятельства закономерно стали питательной средой для увеличения числа automation biases в сфере государственных услуг. Так, в Дании полицейскими использовался специальный алгоритм, позволявший на основе геолокационных данных мобильных устройств, полученных от операторов связи, выстраивать маршрут движения подозреваемых в преступлениях в интересующие следствие дни. В 2019 году обнаружилось, что алгоритм работает с ошибками и в некоторых случаях дает неверные результаты. Это привело к пересмотру 10 000 уголовных дел, по итогам которого были отменены приговоры датских судов в отношении 32 осужденных. В ходе пересмотров было установлено, что при первоначальном рассмотрении указанных дел, судьи чрезмерно доверяли результатам работы программы даже тогда, когда в деле имелись доказательства, ставящие их правильность под сомнение.

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

На фоне указанных скандалов команда во главе с С. Алон-Бакартом (Хайфский университет) и М. Бусуйок (Амстердамский свободный университет) решила провести сходное с экспериментами Ситки исследование, только в области принятия публичных и социальных решений. Его результаты показали, что хотя степень ошибок, связанных с доверием компьютерным помощникам, недостаточно велика, чтобы говорить об устойчивой практике automation bias, такие показатели связаны с тем, что алгоритмы еще не стали настолько распространены в практике государственных органов, чтобы сформировать «ореол» доверия к ним. Кроме того, прошедшие скандалы также сделали госслужащих более настороженными. Однако это не исключает, что в будущем, когда прошлые скандалы забудутся, а алгоритмы станут частью бюрократической рутины, проблема automation bias в секторе публичных решений станет острее.

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

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

Источник

Бизнес-процессы в онлайне – это сложно и муторно. Вот бы упростить… и не ошибиться!

Сегодня поговорим на тему автоматизации (воронок, писем, кнопок и отслеживания). Тема важная, поэтому полностью буду рад твоему мнению.

Автоматизация бизнес-процессов – это необходимость, но и здесь можно накосячить. Как? Ниже рассмотрим три главных ошибки автоматизации. Смотрим, смотрим!

Давай начнем разговор с того, ЧТО и ЗАЧЕМ мы автоматизируем.

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

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

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

Окей. Вроде разобрались. Теперь к делу. Как же можно накосячить?

Например. Представим себе мужика, который постоянно покупает запчасти для своей “ласточки” на одном из сайтов. И тут ОПА – электронное письмо. Там рассказывают об ассортименте. Он просматривает буквально пару пунктов и закрывает. Позже ему приходит электронное письмо “недавно вы смотрели то-то. Так купите же это прямо сейчас!”. Они рассчитывали, что учтут опыт работы пользователя с сайтом. На самом деле только оттолкнули своей навязчивостью. Тебе же не будет приятно, если за твоими действиями на сайте будут слишком усердно следить?

Представим того же самого мужика. Только он подписался на рассылку добровольно и довольно давно. Ему приходит несколько писем, в одном из которых они говорят, что завели аккаунт в Твиттере и просят оставить отзыв именно там. Только вот одна проблема… рассылка, похоже, была сгенерирована давно, ведь там сказали “используй максимум 140 символов”, в то время как Твит уже как пару лет позволяет оставлять комментарии в 2 раза длиннее.

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

Я сейчас про маркетинговые воронки. Вот нажал ты на рекламу и понеслооось – CTA-кнопки, “загрузи”, “купи”, “зарегистрируйся”… Вот та точка входа. Потом начинаются рассылки, лендинги, формы регистрации и прочее.

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

Окей. С ошибками разобрались, теперь давайте разберемся с тем, как это можно исправить.

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

Если ты перед тем, как послать какой-нибудь электронное письмо думаешь “а нужно ли это?”, можешь смело не отправлять это сообщение. Даже тень сомнения в целесообразности означает ее отсутствие.

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

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

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

Нужно искать два вида недочётов – фактические ошибки (помнишь тот случай с Твиттер?) и неработающие гиперссылки.

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

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

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

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

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

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

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

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

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

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

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

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

Пять советов по успешному запуску тестовой автоматизации:

1. Не имеет значения, какие инструменты вы используется – JIRA, Azure или Favro – вам надо создать отдельный проект/пространство для тикетов по автоматизации тестирования. Рекомендуется подойти максимально серьезно к этому вопросу и провести декомпозицию, то есть, как и для любого другого проекта, создать эпики, стори, спайки, задачи. И учесть все это в спринтах и релизах, то есть поставить четкие цели и стремиться к их достижению, а не бесцельно/бесконечно копаться в тикетах.
2. В приоритете долгосрочное планирование. Стремление к быстрому выигрышу — это ошибка. Да, вы можете запуститься очень быстро, но последующие серьезные проблемы нивелируют ваши профиты. Мыслить надо стратегически, выбирая инструменты и технологии с учетом долгосрочных целей. Чтобы быстрее стартовать, можно где-то и пойти на компромисс, но ни в коем случае нельзя строить фундамент автотестов на основе краткосрочных целей — это тоже ошибка.
3. Удостоверьтесь в том, что способ запуска тестов существует не только на собственном компьютере. И не имеет значения, что это: виртуальная лаборатория, облако либо физическая машина. Запускать тесты только на своей машине — это ошибка. И даже если это все, что сейчас у вас есть, это лучше, чем ничего, однако со временем автоматизированные тесты будут прогоняться дольше и дольше, следовательно, вам придется сидеть и ожидать, когда они завершатся.
4. Не стоит работать в одиночку, разработчики тоже могут помочь. Практика показывает, что для действительно успешной автоматизации поддержка разработчиков очень нужна, и не столь важно, идет ли речь о создании тестов, работе с фреймворком либо даже банальном прогоне тестов. Сотрудничать с разработчиками можно и нужно — благодаря этому вы будете уверены, что система непрерывной интеграции будет настроена правильно и эффективно.
5. Настойчивость и еще раз настойчивость. В процессе работы вы гарантированно столкнетесь с препятствиями. Потребуется лицензия, настройка окружения, какие-нибудь права доступа и пр. Иногда вы будете тонуть в вопросах бюрократии и канцелярщины, связанных с заказом и оплатой лицензии. Тут главное проявить твердость и настойчивость, иногда даже навязчивость. Всегда помните о том, что если реализация проекта начнет «тормозить», то с каждой последующей задержкой вам будет все труднее бороться за нужные ресурсы и поддержку. А значит, повышается риск, что ваши уже затраченные усилия пропадут даром.

Источник — https://www.learnautomation.co.uk/2020/07/mistakes-the-automation-ticket/.

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

«Машины должны работать. Люди должны думать».
Девиз компании IBM

Что можно автоматизировать и зачем это делать

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

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

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

Вот несколько задач бизнеса, которые помогает решить автоматизация:

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

Если суммировать все перечисленное, станет понятно, что главная ошибка автоматизации бизнеса — ее полное отсутствие. Рассмотрим еще 10 серьезных ошибок, которые могут помешать развитию компании.

10 ошибок при автоматизации бизнес-процессов

1. Выбирать слишком большое количество процессов для автоматизации. Чем больше процессов будет автоматизировано одновременно, тем ниже качество автоматизации. Важно правильно расставить приоритеты и выбрать то, что должно быть автоматизировано в первую очередь.
2. Ставить на первое место сокращение затрачиваемого времени. Автоматизация помогает сократить время занятости сотрудников для решения рабочих задач. Однако на первом месте должно быть не это, а повышение производительности и эффективности.
3. Не прислушиваться к советам ИТ-специалистов. Сотрудники ИТ-отдела могут помочь как при создании стратегии автоматизации, так и при практической реализации. Их навыки и опыт помогут извлечь максимум пользы из автоматизации бизнес-процессов.
4. Прислушиваться только к советам ИТ-специалистов. В то же время не стоит относиться к процессу автоматизации как к чему-то, что требует только знаний специальных программ и опыта их внедрения. Для успешной автоматизации бизнеса необходима глубокая экспертиза и понимание происходящих в компании процессов.
5. Отказываться от помощи внешних специалистов. Так как автоматизация бизнес-процессов охватывает самые разные сферы, часто компании бывает недостаточно компетенций штатных сотрудников. Правильное решение — обратиться за помощью сторонних экспертов.
6. Оперировать слишком узкими категориями. Автоматизация требует задействования ресурсов компании. Поэтому решать с ее помощью только отдельные узкие задачи будет нерационально. Важно построить тактику, которая будет охватывать сразу несколько важных бизнес-процессов в компании.
7. Мыслить слишком масштабно. В противоположность предыдущему пункту масштабные планы могут привести к тому, что процесс автоматизации займет слишком много времени. Некоторые процессы могут оказаться очень требовательными к качеству реализации и отнимать слишком много времени и сил. Вместо того чтобы автоматизировать их целиком, можно начать с 60–70% каждого процесса.
8. Не получить поддержки со стороны руководства. Поскольку автоматизация оказывает глобальное влияние на компанию, для ее реализации необходима поддержка руководителя высокого уровня. Этот специалист должен обладать полномочиями для принятия решений в масштабах целой компании.
9. Приступать к автоматизации без дорожной карты. Перед началом автоматизации важно поставить четкие измеримые цели и наметить шаги для их достижения. Успех зависит от того, насколько тщательно будут спланированы изменения и насколько гибко компания подходит к планированию.
10. Считать автоматизацию способом решения всех проблем. Автоматизация действительно может помочь снизить затраты, повысить производительность сотрудников и сделать работу компании более эффективной. Однако важно понимать, что она не решит проблемы с управлением и неправильной организацией процессов. Понимание того, что именно автоматизация бизнес-процессов может и не может дать компании, защищает от разочарований и неэффективного использования данного инструмента.

Использование ESM-системы для автоматизации

Для того чтобы автоматизировать большинство сервисных процессов в современных компаниях, используют технологии ESM (Enterprise Content Management). ESM — это набор технологий, которые помогают собирать корпоративный контент, хранить его, управлять им и предоставлять к нему доступ сотрудникам компании. Под контентом подразумеваются договоры, счета, отчеты, коммерческие предложения, таблицы, презентации и другие документы, которые используются в компании. Также сюда относят переписку по email, аудио- и видеофайлы, веб-страницы и т. д.

С помощью ESM-платформы компании создают единое корпоративное пространство. Для этого система обеспечивает:

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

Для выполнения такого широкого круга задач подойдет не каждая ESM-платформа. На сегодня одним из лучших предложений на рынке считается решение от SimpleOne.

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

Преимущества ESM-платформы от SimpleOne:

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

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

Автоматизация, если она выполняется плохо, может оказать негативное влияние на использование данных, процессы, моральный дух сотрудников и удовлетворенность клиентов. на страницах сайта Gartner пишет: недавний опрос Gartner показывает, что почти 60% организаций реализуют в среднем четыре или более одновременных инициативы по гиперавтоматизации. “Лидеры должны относиться к автоматизации как к принципу, который необходимо принять, а не как к проекту, который необходимо выполнить, и должны знать о распространенных ошибках, которые могут привести к неудачам”, — говорит Николь Стерджилл, вице-президент Gartner по аналитике.

На картинке изображены десять распространенных ошибок в автоматизации

Ошибка № 1: влюбленность в единственную технологию

После того, как организация успешно приобрела и внедрила определенный инструмент автоматизации процессов, такой как robotic process automation (RPA), естественно, что коллеги хотят внедрить его более широко. “Однако неправильный подход заключается в том, чтобы управлять автоматизацией с точки зрения одной технологии. Вместо этого ориентируйтесь на бизнес-результат, а затем подбирайте правильный набор инструментов”, — говорит Стерджилл.

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

Ошибка № 2: вера в то, что бизнес может автоматизироваться без ИТ

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

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

Ошибка № 3: думать, что автоматизация — это всегда решение

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

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

Ошибка № 4: не вовлечение всех заинтересованных сторон

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

Действие: возложите ответственность за управление заинтересованными сторонами на конкретного члена команды в центре передового опыта автоматизации.

Ошибка № 5: неспособность уделить достаточно времени тестированию

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

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

Ошибка № 6: напрасная трата усилий на чрезмерно сложные процессы

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

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

Ошибка № 7: отношение к автоматизации как к простой репликации задач

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

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

Ошибка № 8: отсутствие контроля в постпродакшене

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

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

Ошибка № 9: использование неправильных показателей для измерения успеха

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

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

Ошибка № 10: Игнорирование культуры и влияния сотрудников

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

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

Оригинал статьи Лоуренса Гоасдаффа – здесь.