Ответ на пост "Ответ на пост «Тем, кто боится, что ИИ нас заменит - нет»"
Писал комментарий, но что-то он превзошел все границы разумного, а потому оформляю отдельным постом.
Конкретно данный текст - это ответ пользователю @Alice.V на вот этот комментарий:
#comment_304897084
ну и в целом на сам пост:
Ответ на пост «Тем, кто боится, что ИИ нас заменит - нет»
Первое, что хотелось бы отметить - Я люблю демократию автоматизацию (тов. Палпатин). На мой взгляд, автоматизированное решение всегда будет предпочтительнее не автоматизированного, хотя бы за счет того, что оно позволяет поставить процесс на жесткие рельсы и снизить количество ошибок, вызываемых человеческим фактором.
Однако, в то же время я против автоматизации ради самой автоматизации. Иными словами внедрение автоматизированных процессов стоит внедряющей их компании определенных средств, а потому должно приносить какой-то ощутимый профит в обозримой перспективе. И этот профит должен быть определен и посчитан (хотя бы примерно) до принятий решений по внедрению.
На тему обоснованности внедрения автоматизированных процессов есть довольно забавная история про картошку от Максима Дорофеева по ссылке ниже (время - 1:06:20, если привязка по времени в ссылке не сработала).
И пост и комментарий, на который я отвечаю, описывают преимущественно плюсы внедрения RPA (Robot Process Automation) и описывают их, безусловно, верно. При этом умалчиваются или игнорируются потенциальные проблемы, возникающие при внедрении. А это создает уже излишне оптимистичную картинку, на что в комментариях некоторые пользователи также отмечают. Поэтому, не оспаривая ценность технологии RPA в частности и автоматизации бизнес-процессов в целом, я хотел бы указать на некоторые потенциальные проблемы, возникающие при их внедрении.
Некорректное описание бизнес-процессов.
Базой для автоматизации бизнес-процессов является их формальное описание, в виде текста, таблиц, блок-схем и т.п. Источники этого описания могут быть различными:- описание может быть составлено специально нанятыми внешними конторами (например, при сертификации по ИСО 9001)
- описание могут составить руководство или сотрудники самой компании, где предполагается внедрение
- описание может составить сам специалист по автоматизации путем опроса сотрудников компании
В любом случае следует быть готовым к тому, что это описание будет неправильным. Причем часто эта проблема всплывает уже на этапе внедренного автоматизированного процесса, когда пользователи (сотрудники компании) вдруг не могут выполнять свои задачи.
Приведу простой пример. Относительно недавно внедряли автоматизированный бизнес-процесс для конструкторов предприятия. Была проведена куча митингов с различными конструкторскими подразделениями, составлялись, утверждались, а потом переделывались регламенты их работы. Наконец спустя пару месяцев был принят некий общий регламент, который был подписан всем верхним руководством, и началась разработка. После разработки бизнес-процесс был запущен в тестовой среде, чтобы все причастные могли его пощупать и высказать свое "фиии...". Затем настал день Хэ, и автоматизированный бизнес-процесс был внедрен в рабочую среду предприятия. Уже к обеду пришел начальник и сказал, что "вертаем все взад". Оказалось, что на каком-то складе есть своя группа конструкторов, о которой то ли не знали, то ли когда-то знали, но уже забыли, а потому не включили в рабочую группу. И хотя эти конструктора работали в общей системе очень редко (а потому им на все эти наши телодвижения с бизнес-процессами было глубоко фиолетово), но зато их работа напрямую. практически в режиме реального времени, влияла на производство. А потому мы, внедрив в рабочую среду новый процесс, который заблокировал им их нормальную работу, чуть не остановили производство. И это только один довольно простой и безобидный пример.
Почему описание реально существующего бизнес-процесса может вдруг оказаться не корректным? Тут могут быть различные причины, например:
- БП описываются "сверху", а не "снизу". Вместо того, чтобы получить описание работы от тех, кто непосредственно занимается выполнением задачи, его (описание) составляют руководители. При этом у руководителя может возникнуть желание чуть приукрасить действительность, он может не знать каких-то деталей работы подчиненных и т.д. Все это приведет к искажению описания БП.
- При описании БП опускаются мелкие детали. Когда человек долго выполняет какие-то действия, то многие их детали для него становятся само собой разумеющимися, а потому при описании своей работы он может их упустить.
- После составления описания процессы поменялись. Хотя может так показаться, что компания - это нечто статичное и неизменное, по факту в ней постоянно происходят какие-то изменения: меняется персонал, меняются поставщики и покупатели, меняется используемый софт, вносятся правки в регламенты и т.д. В следствие этого однажды описанный бизнес-процесс через какое-то время может существенно поменяться.
- Работники "оптимизируют" БП. Часто регламенты излишне усложняют работу сотрудников, а также приводят к растягиванию сроков в бюрократической машине предприятия. А поскольку руководство всегда ставить задачи со сроком выполнения "вчера", то люди учатся находить "короткие пути", которые разумеется нигде и никак не документируются.- И еще множество других причин может привести к тому, что описание автоматизируемого бизнес-процесса становится не корректным. А это в свою очередь ведёт к сдвигу сроков и увеличению бюджета. Такова селяви.
Интеграция различных систем.
Как правило любое более-менее крупное предприятие имеет ряд подразделений (например, продажи, закупка, конструктора, технологи, производство, бухгалтерия и т.д.), которые для своей работы используют различные информационные системы, которые никак не стыкуются между собой. В тоже время бизнес-процессы редко ограничиваются рамками одного подразделения, но так или иначе захватывают часть смежных областей.
Например, запуск конструкторским подразделением работы над новым изделием вовлекает в работу также и технологический отдел (разработка технологии под новое изделие), и закупки (поиск поставщиков различных покупных изделий), и условную бухгалтерию (расчет затрат на новое производство) и т.д.
И вот при запуске бизнес-процесса нужно как-то суметь обеспечить взаимодействие между этими различными системами, учитывая тот факт, что они работают в принципе с абсолютно разными сущностями (конструктора - изделия, технологи - техпроцессы, бухгалтера - счета и договора), имеющими разное представление. Очень часто случается так, что какой-то атрибут в одной системе соответствует целой совокупности атрибутов в другой, причем далеко не всегда однозначно.
Ну а чтобы жизнь не казалась уж слишком простой нужно упомянуть ситуацию, когда на наших предприятиях иностранные системы с их парадигмой ведения процессов пытаются натянуть на отечественные реалии в виде ЕСКД, ЕСТД и т.п. И такие системы уже начинают использоваться не так, как это задумывал их разработчик, а так, как это удастся сделать внедренцам на наших предприятиях. Как итог этого безобразия одна и та же информационная система, внедренная на двух соседних предприятиях, может работать по-разному.
Таким образом, берясь за автоматизацию бизнес-процессов на предприятии, следует учитывать не только весь зоопарк используемых информационных систем, но и то, каким образом они используются.
Важность личных взаимодействий.
Здесь хотелось бы отметить, что иногда автоматизаторами игнорируется этот важный момент. С одной стороны человек как правило не очень любит по важным вопросам взаимодействовать с автоматами, а с другой - личное взаимодействие позволяет в диалоге нащупать тоненькую нить взаимных интересов.
В комментариях предлагалось возложить на RPA задачу по обзвону кандидатов на открытую вакансию, или, например, провести мониторинг поставщиков. Но вот давайте честно, захотите ли вы общаться с роботом при трудоустройстве? Не решите ли вы, что это тупо очередной развод от мошенников? Ну и уж точно вряд ли робот при мониторинге цен сможет выявить, кто из поставщиков будет готов подвинуться на скидку, а у кого цена окончательная.
Когда я еще учился в универе, один наш преподаватель рассказывал байку из своей практики, что когда они внедряли на каком-то предприятии PLM-систему Teamcenter, то в одном из подразделений в несколько раз увеличилось время внедрения изменений в документы. Когда стали копать, то выяснилось, что когда автоматизировали процессы подписания документов, то они все стали застревать на одном из начальников - этот товарищ просто не воспринимал входящие сообщения в системе, как нечто важное и требующее внимания, а уж тем более подписи.
Еще раз отмечу - я не против автоматизации. Автоматизация - это хорошо.
Однако замалчивание проблем, связанных с внедрением автоматизированных процессов, может сформировать у далеких от темы людей излишне оптимистичные ожидания.
Любая автоматизация - это сложный, длительный и дорогой процесс, затрагивающий большое число внутренних процессов компании. И запуская этот процесс следует, во-первых, четко понимать для чего это делается, и как это будет отбиваться, а во-вторых, нужно быть готовым к проблемам, если что-то пойдет не так. Ну и еще: те, кто обещает за копейки за пару месяцев автоматизировать работу всего предприятия - скорее всего эти люди говорят неправду.