Кроличья нора автоматизации бизнес-процессов
В мире современных технологий бизнес неизбежно сталкивается с необходимостью изменения, развития и оптимизации своих процессов. В этой статье в блоге ЛАНИТ мы погрузимся в мир автоматизации бизнес-процессов и рассмотрим, зачем она нужна, какие преимущества она приносит, какие ошибки могут привести к провалу проектов и как постараться избежать погружения в кроличью нору, казалось бы, простого проекта.
Зачем нужна автоматизация бизнес-процессов
Алиса из произведения Льюиса Кэрролла однажды услышала от Королевы, что чтобы остаться на месте, надо бежать со всех ног, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее. В современном мире, где технологии и требования рынка постоянно меняются, бизнесу тоже приходится постоянно двигаться вперед и совершенствоваться, чтобы не остаться на месте и не потерять конкурентоспособность.
И тут на сцену выходит она, автоматизация, волшебная таблетка от всех проблем и ключ к неограниченному росту прибыли. Именно так и думают некоторые люди, когда речь заходит про автоматизацию бизнес-процессов предприятия. И немногие задумываются о реальных возможностях и целях этой автоматизации, что в итоге может оказаться одной из причин неудач на пути к достижению обозначенных целей. Автоматизация не устранит плохие процессы, она только ускорит их выполнение. Поэтому очень важно еще перед началом работ чётко понимать, какие именно цели преследуются и как именно планируется их достижение.
Выбор цели автоматизации
Позабыты хлопоты, остановлен бег,
Вкалывают роботы, а не человек.
Когда бизнес решает автоматизировать бизнес-процессы, он обычно сталкивается с рядом задач и целей, которые пытается решить, чтобы улучшить свою эффективность и конкурентоспособность. Давайте более подробно рассмотрим эти задачи.
Оптимизация производительности сотрудников и сокращение времени на рутину. Включает в себя автоматизацию рутинных и монотонных задач, которые раньше требовали значительных временных ресурсов. Этот пункт не означает, что целью является сокращение сотрудников, например, в два раза. Он означает сокращение рутины, которая не только способна съедать время ценных специалистов, но и способствовать их усталости и выгоранию на рабочем месте.
Сокращение вероятности ошибок, связанных с человеческим фактором. Человеческие ошибки могут стоить компании дорого. Автоматизация же может помочь снизить вероятность ошибок, допускаемых человеком в процессах, так как компьютерные системы выполняют задачи более точно и последовательно. Например, автоматизация в бухгалтерии может уменьшить риск ошибочных расчетов или неправильного учета данных.
Прозрачность выполнения каждого этапа процесса с возможностью построения отчетов и анализа слабых мест. Автоматизация бизнес-процессов позволяет более детально отслеживать выполнение каждого этапа процесса. Это обеспечивает более высокую степень прозрачности и позволяет быстро выявлять возможные проблемы и реагировать на них. Кроме того, автоматизированные системы могут генерировать отчеты и анализировать данные, что помогает выявить слабые места в процессах, улучшить их, а также строить более точные прогнозы на основании обрабатываемых данных.
Исключение ручного труда на этапах, которые это позволяют сделать. Многие бизнес-процессы могут быть оптимизированы и упрощены за счет полного исключения ручного труда. Например, вместо того, чтобы сотрудники вручную вводили данные, системы автоматизации могут собирать, обрабатывать и передавать данные без участия человека. Это уменьшает риск ошибок и снижает издержки. При этом, стоит иметь в виду, что даже полная автоматизация некоторых областей не всегда приводит к возможности сокращения штата специалистов, а лишь увеличивает объем и качество выполняемой ими работы при меньших усилиях.
Централизация данных. Централизация данных позволяет хранить их в одном месте, что упрощает доступ к ним и управление ими. Это устраняет проблему разрозненных данных, которые могут затруднять анализ и принятие решений. Например, централизованная НСИ (нормативно справочная информация) однозначно поможет избежать появления новых седых волос как у руководителей, так и у исполнителей. Особенно, если дело касается крупного предприятия, когда одна позиция товара в разных системах может называться по-разному.
Итак, автоматизация бизнес-процессов призвана решать эти задачи, что в итоге способствует повышению производительности, эффективности, конкурентоспособности и, как итог, увеличению прибыли предприятия.
Выбор инструментов автоматизации
Выбор инструментов автоматизации не менее ответственен, чем определение целей. Эффективные средства автоматизации могут значительно упростить жизнь компании и ускорить достижение поставленных целей. Однако прежде чем выбирать инструменты, нужно четко определить, какие процессы требуют автоматизации и какие именно задачи необходимо решить. Исходя из этих задач, необходимо определиться с инструментом автоматизации, будут ли это ECM, CRM, ERP-системы или же, например, программные роботы (RPA).
Вдаваться в описание всех инструментов и их преимуществ, функций и недостатков в рамках данной статьи мы не будем, так как про выбор инструмента под конкретные задачи можно написать отдельную статью. Однако не упомянуть про этот этап нельзя — каждый инструмент решает свои задачи, несоответствие целей с выбранным инструментом может завершиться провалом проекта, т.к. результат будет сильно отличаться от ожиданий.
Так, для решения задач в части управления документами и контентом организации стоит рассматривать ECM-систему. Для автоматизации производственных процессов больше подойдут ERP-системы. В процессах же, где существует много ручного труда с одинаковым и предсказуемым алгоритмом действий, может подойти роботизация процессов (RPA), которая имитирует действия пользователя в интерфейсе одной или нескольких систем.
Возможные причины неудач и как избежать кроличьей норы с бесконечной автоматизацией
Хотя автоматизация бизнес-процессов имеет значительный потенциал для получаемой пользы, итоговое внедрение решения иногда может не принести желаемого результата. Давайте рассмотрим основные причины, которые могут привести к неудаче или к бесконечной автоматизации.
Недостаточное понимание процессов. Одной из распространенных причин, вызывающих неудачи в процессе автоматизации, является недостаточное понимание бизнес-процессов. Если заранее детально не разобраться в функционировании процессов и не определиться точно, какие именно задачи требуют автоматизации, то выбор инструментов или систем может быть неоправданным или неэффективным. Неполное изучение процессов также может привести к тому, что автоматизация затронет неподходящие этапы или, могут быть упущены важные детали, что в итоге может отрицательно сказаться на результатах. Важно учитывать принцип: попытка автоматизировать хаос приведет к еще большему хаосу в результате. Кроме того, необходимо не только понимать состояние процессов (as is), но и иметь четкое видение того, какими они должны стать после автоматизации (to be).
Например, при автоматизации в одном промышленном холдинге возникла проблема из-за отсутствия стандартизации процессов. Это привело к появлению множества одинаковых процессов, но функционировавших по-разному. Каждое предприятие в холдинге требовало индивидуальной настройки процессов под его собственные предпочтения. В результате были созданы сотни однотипных процессов, что затруднило их последующую поддержку из-за индивидуальных особенностей, заложенных в каждый из них. Однако были сделаны своевременные выводы, и предприятие параллельно приступило к стандартизации процессов и приведению их к желаемому состоянию to be.
Неудачный выбор инструментов. Неверный выбор инструментов автоматизации, не соответствующий конкретным потребностям предприятия, также может являться угрозой для успешной реализации проекта. Некоторые системы могут быть излишне сложными или недостаточно гибкими для конкретных задач. Это в свою очередь приведет к затратам ресурсов на что-то, что не приносит ожидаемой пользы. Данная проблема также может быть напрямую связана с недостаточным пониманием процессов и соответственно непониманием конечного результата, в связи с чем в процессе реализации команда может столкнуться с ограничениями выбранного решения.
Недостаточная оценка инфраструктуры и систем, находящихся в контуре автоматизации. Это одна из наиболее частых проблем, которая всплывает в процессе автоматизации. Примером такой проблемы может быть отсутствие нормализованной и централизованной НСИ, что приводит к большим проблемам при миграции данных между системами. Старт автоматизации без нормализации НСИ, которая будет использоваться, многократно повышает риски того, что внедрение начнёт буксовать или закончится неудачей. В процессе разработки можно реализовать маппинг данных, но это разовая операция и без четкого процесса внесения и изменения таких данных, любая, даже хорошо продуманная система будет плодить множество ошибок с завидной регулярностью.
Проблема со стандартизацией и нормализацией справочников и информационных систем наблюдается почти в каждом крупном проекте. Например, в рамках проекта по автоматизации обмена договорными документами с контрагентами возникла ситуация, когда договоры создавались в различных системах в зависимости от их типа, после чего должны были поступать в центральную систему управления договорами для отправки контрагентам. Каждая из исходных систем имела собственный список контрагентов, который мог содержать дубликаты и отличаться от списка в системе управления договорами. Кроме того, каждая система вносила изменения в эти данные по своему усмотрению и могла их изменять в любое время, что еще больше усугубляло хаос. Также возникали ситуации, когда в одной системе указывались данные филиала контрагента, а в другой — данные головной компании. Иногда ИНН контрагента может отличаться в разных системах, хотя фактически это один и тот же контрагент, например, в одной системе указан ИНН как крупнейшего налогоплательщика, а в другой обычного.
В случае с продукцией, проблемы нормализации становятся еще более заметными, так как в этом случае может вообще не быть каких-либо опознавательных признаков. В одной системе это будет «Стул» с артикулом условно »123», а в другой «Стул офисный» с артикулом »567».
В эту же категорию можно отнести недооценку возможностей других систем. Если речь идёт о холдингах или крупных предприятиях, то там очень часто наблюдается «зоопарк» систем с разными возможностями и функциональностями, от которых нельзя отказаться по каким-либо причинам, но которые участвуют в автоматизируемых процессах. Недооценка технических возможностей этих систем также может привести к тому, что «изобретение велосипеда» для корректного встраивания этих систем в обновленные процессы может оказаться айсбергом, который потопит, казалось бы, продуманный проект.
При автоматизации на одном из промышленных предприятий обнаружилось, что неполнота изучения данного вопроса привела к необходимости интеграции с системами, от которых зависело получение определенной информации. Однако эти системы, созданные еще в 90-е годы, имели значительные технические ограничения. Некоторые из них могли передавать данные только в формате XML, другие имели возможность взаимодействия лишь на уровне базы данных. Кроме того, технические доработки этих систем по различным причинам оказались невозможны. В результате необходимо было разрабатывать интеграции для каждой из этих систем в отдельности, чтобы обеспечить непрерывность процессов.
Сопротивление внедрению со стороны пользователей. У многих людей присутствует сопротивление нововведениям. В основном у сотрудников часто возникает отрицательная реакция из-за привычки к устоявшимся рабочим процессам, и любые изменения вызывают у них определенное сопротивление. Иногда они даже могут активно противодействовать внедрению нововведений, особенно если получают поддержку от непосредственного руководства.
Поэтому важно не только принятие решений на уровне управления, но также обучение и включение реальных исполнителей в процесс внедрения. Как показывает практика, когда сотрудники видят, что их мнения учитываются для улучшения их рабочего процесса, а также получают быструю поддержку и помощь в освоении новой системы, их отношение меняется. Они начинают осознавать преимущества, которые может принести автоматизация.
Недостаточное внимание к безопасности данных. Сфера кибербезопасности играет важную роль в вопросах автоматизации. Недостаточная защита данных может привести к утечкам информации, взлому системы или потере ценных данных. Несоблюдение нормативов и правил безопасности может создать уязвимости в системе и привести к серьезным проблемам на, казалось бы, завершающей фазе проекта.
Неудачное планирование и управление проектом. Отсутствие четкого плана внедрения автоматизации, неправильное распределение ресурсов и неэффективное управление проектом могут также затруднить его реализацию. Недостаточное внимание к этапам развертывания системы, оценке рисков и контролю над ходом проекта могут серьезно сказаться на его результативности.
Чтобы всего этого избежать, необходимо внимательно подходить к анализу и планированию процесса внедрения новых технологий, уделять внимание обучению сотрудников, выбору правильных инструментов и эффективному управлению проектом. Только в таком случае автоматизация сможет реально обеспечить прирост эффективности и улучшение результатов бизнеса.
Кратко о выборе модели разработки
Про выбор модели разработки, их плюсах и минусах не писал только ленивый. Подробно на плюсах и минусах каждой останавливаться не будем, рассмотрим лишь основные различия двух принципиально разных подходов, и почему неудачный выбор какой-либо модели может повлиять на успех автоматизации.
Если не вдаваться в частности, можно выделить два концептуально отличающихся друг от друга подхода, такие как каскадная модель разработки и гибкая модель разработки. У каждой модели имеются свои плюсы и минусы.
Каскадная модель разработки. Также известная как waterfall model или модель «водопад», представляет собой последовательный процесс, где разработка программного обеспечения проходит через такие фазы, как анализ требований, проектирование, реализация, тестирование, интеграция и поддержка. Эта модель включает следующие принципы.
Последовательность и строгий порядок. Каждая фаза начинается только после завершения предыдущей. То есть переход к следующей стадии возможен только после полного завершения предыдущей, без возможности возврата назад на предыдущие этапы разработки.
Предсказуемость и управление сроками. Каскадная модель обеспечивает определенные сроки завершения каждой фазы, что делает процесс более предсказуемым и управляемым с точки зрения времени.
Строгий контроль и документирование. Каждая фаза имеет свои строгие критерии завершения и требования к документации, что способствует подробному контролю и документированию каждого этапа процесса разработки.
Ограниченная гибкость и реакция на изменения. Эта модель менее гибкая в отношении изменений. Она мало подходит для ситуаций, когда требования могут измениться после начала разработки, поскольку любые изменения могут быть затруднительными и дорогостоящими.
Риск несоответствия ожиданиям. Из-за отсутствия возможности быстрой коррекции внесенных изменений, модель может привести к конфликтам между заказчиком и исполнителем, когда ожидаемый результат не соответствует финальному продукту.
Каскадная модель хорошо подходит для проектов с четкими, стабильными и неизменными требованиями, где изначально известен конечный результат и изменения редко возникают после начала разработки. Однако она менее подходит для современных проектов, требующих гибкости, адаптации к изменениям и частых обновлений.
Гибкая модель разработки. Также известная под общим словом Agile. Название является обобщающим термином для ряда подходов и практик, основанных на ценностях манифеста гибкой разработки программного обеспечения. Основные принципы методологии Agile отличаются от каскадной модели (Waterfall) несколькими ключевыми аспектами. Agile призвана обеспечить более гибкий и итеративный подход к разработке программного обеспечения.
Основные различия между методиками
Итеративность и инкрементальность. В Agile процесс разработки разбивается на короткие циклы, известные как итерации или спринты, в течение которых команда создает, тестирует и доставляет работающий продукт. Т.е проходит все фазы в рамках отдельно взятой функциональности. Это позволяет быстрее получать обратную связь и вносить изменения, если требуется.
Гибкость и адаптивность. Agile предполагает возможность изменения требований даже на поздних этапах разработки, с каждой итерацией улучшая продукт.
Вовлеченность заказчика и прозрачность. Методология Agile акцентирует внимание на постоянном взаимодействии с заказчиком, чтобы точнее понимать его потребности и ожидания. На каждый спринт совместно с заказчиком формируется список задач, которые должны быть реализованы по завершении этого спринта.
Управление рисками. Agile позволяет быстрее выявлять риски и управлять ими, поскольку процесс разработки помогает получить какую-либо функциональность и понять, соответствует ли она ожиданиям заказчика.
Поощрение командной работы и самоорганизации. Методология Agile акцентирует внимание на коллективной работе и самоорганизации команды. Она поощряет взаимодействие и эффективную коммуникацию между ее участниками, чтобы достичь общей цели проекта. Каждый член команды имеет свои обязанности, но в то же время принимает активное участие в обсуждениях, принятии решений и поиске оптимальных инструментов для выполнения задачи. Это способствует повышению эффективности работы команды в целом.
Главное отличие Agile от каскадной модели заключается в подходе к изменениям. В каскадной модели любые изменения, особенно на поздних стадиях разработки, могут быть дорогостоящими и затруднительными, тогда как Agile призван обеспечить гибкость и быструю адаптацию к изменениям, что делает этот подход более подходящим для современной быстро меняющейся среды разработки программного обеспечения.
У Agile существует много противников, но чаще всего негативный опыт связан с неправильным применением этой модели. Системы и процессы постоянно становятся всё сложнее, и всё предусмотреть на берегу становится все труднее, особенно заказчику, который может не знать всех тонкостей. В случае с каскадной моделью, заказчик, понимая высокую важность документации, которую он согласует, может начать заниматься буквоедством, чтобы максимально обезопасить свои решения. Каждое решение в этом случае будет сопровождаться бюрократией, когда каждое звено пытается переложить ответственность друг на друга. Agile-методики же позволяют заказчику регулярно «щупать руками» получаемый результат, что в свою очередь помогает легче принимать решения и еще на ранних этапах понимать, когда выбранное решение пошло куда-то не туда. Если была допущена ошибка при проектировании, лучше узнать о ней заранее, а не во время опытно-промышленной эксплуатации. Тогда можно будет вовремя проанализировать новые вводные и скорректировать направление дальнейшего развития, что будет невозможно при применении каскадной модели.
При решении использовать Agile-методики лучше сразу обсудить с заказчиком правила взаимодействия. Недопонимание в данное вопросе, приведет к тому, что заказчик будет ожидать крупные блоки завершенного функционала. Это будет и не Agile, и не полноценная каскадная модель, с соответствующими вытекающими в виде хаоса во время реализации. Лучше всего в таких случаях идти от большого к меньшему, слона нужно есть по частям. В первой версии реализуйте блок функционала, чтобы он хоть как-то работал. Пусть с ограничениями, пусть с увеличенной трудоемкостью, главное — попытаться объяснить заказчику, что это не конечный вариант, что далее будет сформирован список задач по улучшению первого варианта. Затем, собирая обратную связь, шаг за шагом улучшать этот блок, приближая его к состоянию, когда соотношение затраченных усилий и результата устроит как заказчика, так и исполнителей.
Заключение
Внедрение автоматизации требует не только технических знаний, но и учета человеческого фактора, безопасности данных и внимательного управления проектом. Чтобы избежать попадания в «кроличью нору» с бесконечными доработками, необходимо сосредоточиться на понимании процессов, выборе правильных инструментов, обучении персонала и четком планировании. Только при таком комплексном подходе автоматизация сможет стать катализатором роста эффективности и успеха бизнеса.
Еще до старта разработки системы все процессы должны быть разложены по полочкам, максимально унифицированы и продуманы, как они будут выглядеть на выходе и каким образом они будут решать цель автоматизации. Также важно еще до старта работ определиться с границами проекта и контуром инфраструктуры, который будет затронут.
При этом следует помнить, что даже очень хорошо продуманный план всегда будет иметь пробелы, которые могут быть выявлены только в процессе реализации. Заказчик может не знать всех нюансов или считать некоторые моменты очевидными и не упоминать о них. И это приводит к новым требованиям и конфликтам заказчика с исполнителями, когда исполнители сделали всё по согласованному техническому заданию, но заказчик всё равно недоволен и требует всё переделать. Для этого в планы обязательно нужно закладывать риски. При автоматизации желательно использовать Agile-методики, чтобы минимизировать ситуации, когда спустя несколько месяцев разработки, вдруг стало понятно, что шли не в том направлении и нужно всё переделать, а результат работы нескольких месяцев отправить в корзину.
Также необходимо уделить внимание ключевым пользователям вашей системы и предоставить им подробное объяснение того, как будет осуществляться реализация. Дайте этим пользователям возможность активно взаимодействовать с функционалом и собрать обратную связь о своем опыте использования: чего именно не хватает, что вызывает неудобства, а также, какие функции могут быть излишними. Эти участники процесса обладают ценными знаниями, поскольку ежедневно взаимодействуют с системой или процессом. Их участие в этапе разработки позволит предложить ценные рекомендации по оптимизации системы, указать, как ее сделать более удобной, а также выявить области, которые можно упростить или автоматизировать. Важно отметить, что если эти пользователи активно будут вовлечены в создание и улучшение системы, то впоследствии это поможет снизить сопротивление и негативное влияние при внедрении.
Во всём нужно соблюдать баланс. Успешный проект не тот, который выполнен строго по техническому заданию, и не тот, который длился десять лет и на который были израсходованы все бюджеты в полном объеме, а тот, в котором помимо технического задания были достигнуты цели автоматизации, и в котором довольны результатом и заказчик, и пользователи. Причем исполнители не успели заработать нервный тик при одном только упоминании этого проекта.
Статья подготовлена совместно с @LDM-platform.
