Пошаговая технология разработки плана автоматизации бизнес-процессов

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

В рамках общей концепции цифровизации мы выделяем 5 треков развития (подробно об этом в статье). Сегодня поговорим про один из них – автоматизацию бизнес-процессов. Почему именно про него?

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

Вывод: автоматизация бизнес-процессов – это база. Без неё цифровое развитие невозможно.

Конечно, автоматизация – это не что-то из разряда «есть» или «нету». Это бесконечный трек. В самом начале – моносистема и автоматизация только того, что нельзя не автоматизировать. На линии горизонта – бесчеловечный ИИ.

Соответственно, автоматизацию бизнес-процессов предприятия нужно развивать. Возникает вопрос: как? Что конкретно внедрять? В каком порядке? 

Стоит отметить позитивный тренд – все меньше предприятий живут в парадигме, что существует какая-то волшебная таблетка от всех бизнес-болячек. Все больше подходит к построению архитектуры ИТ-систем осознано. (Буду верить, что Digital4food со своей образовательной деятельностью тоже внес вклад 😉)

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

ПРЕДПОСЫЛКИ К РАЗРАБОТКЕ КОНЦЕПЦИИ АВТОМАТИЗАЦИИ БИЗНЕС-ПРОЦЕССОВ

Для начала хотелось прояснить, в каких ситуациях, как правило, появляется необходимость разработки концепции конкретно у предприятий FMCG и АПК.

• Вынужденная замена ПО (отмена поддержки текущего решения вендором/ импортозамещение)
• Запросы бизнеса переросли возможности текущей системы (текущее решение не позволяет реализовать необходимые функции, необходимые для достижения целей бизнеса)
• Хочется повысить уровень эффективности через цифровизацию (есть понимание гипотетической пользы от цифровизации, основанный на опыте коллег по цеху, но информации много и не ясно – с чего начать)

ОШИБКИ БЫСТРОГО ВЫБОРА

Надо сказать, что всех трех вышеописанных ситуациях люди совершают стандартные ошибки. Три наиболее частые из них:

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

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

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

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

ГЛАВНЫЕ ВОПРОСЫ ДЛЯ НАЧАЛА

Чтобы не наступать на грабли, о которых мы только что вам рассказали, необходимо ответить на следующие вопросы:

• Как (и почему именно так) должен быть выстроен целевой ИТ-ландшафт?
• Как обеспечить целостность и непротиворечивость ИТ-системы?
• Как при этом учесть требования функциональных руководителей и ТОП-менеджмента?
• В каком объеме, с какими приоритетами и почему именно так должны выполняться задачи по смене платформы?
• Какими ресурсами должен быть обеспечен такой проект для реализации и для дальнейшего сопровождения новой информационной системы?

ПОШАГОВАЯ ТЕХНОЛОГИЯ РАЗРАБОТКИ КОНЦЕПЦИИ

Переходим непосредственно к самой пошаговой технологии – что мы делаем на этапе разработки концепции.

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

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

На примере выделена функция «документооборот с клиентами». Еще выделяются такие функции как складская логистика, транспортная логистика, сдача бухгалтерской отчетности и так далее.

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

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

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

На приведенном выше примере документооборота с клиентами выделено две задачи: формирование и печать пакета сопроводительных документов после наборки продукции на складе и отправка сформированных документов через EDI и ЭДО.
Для среднего предприятия таких ИТ-задач выделяется порядка 100. Если это компания с несколькими производственными площадками и с выделенным, например, торговым домом, –порядка 200. (На нашей практике количество задач доходило до 300-350).

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

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

Шаг 3.1. Определить набор информационных баз
Шаг 3.2. Распределить ИТ-задачи по информационным базам
Шаг 3.3. Выбрать конкретные конфигурации для этих информационных баз

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

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

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

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

Шаг 4.1. Сформировать портфель проектов с описанием качественного результата каждого проекта
Шаг 4.2. Распределить ИТ-задачи между проектами для формирования содержания каждого проекта
Шаг 4.3. Оценить трудоемкость и длительность проектов
Шаг 4.4. Определить зависимость проектов друг от друга и наложить на календарь

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

Мы берем все задачи, которые у нас были (100-150-200) и распределяем их на набор проектов.
Тут, кстати не все задачи могут попасть в проекты, потому что какие-то из них мы можем признать решенными на достаточном уровне. Принять решение, что в горизонте 3-5 лет не планируем их изменять.

Так у нас появляется набор проектов, который выстраивается в классический график Ганта. В некоторую последовательность, которая определяется, с одной стороны, приоритетностью бизнеса, с другой – технологическими особенностями, (потому что какие-то системы не имеет смысла внедрять, пока мы не внедрили другие).

Шаг 5. Оценить необходимые ресурсы для выполнения проекта

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

• Требования к ИТ-инфраструктуре
• Требования к ИТ-отделу (для реализации проектов и их сопровождения)
• Бюджет на привлечение сторонних партнеров

Современные системы, как правило, являются намного более ресурсоемкими, чем системы прошлых поколений. (Если, опять же, взять «1С:ERP» в противовес «1С:УПП» или добавление в ИТ ландшафт систем класса MES, WMS и прочих узкоспециализированных). Поэтому мы должны быть готовыми к тому, что нам потребуется новое железо. А это, в свою очередь, деньги, которые надо учесть в бюджете. Кроме того, не следует забывать о том, что в текущих реалиях могут возникнуть проблемы с поставками этого железа.

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

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

Автоматизация – это вечнозеленая тема. Если вы внедрили систему, и после этого у вас нет задач на ее развитие и модернизацию, то, скорее всего, у вас мертвая система, которая не работает. Если система работает, у вас обязательно постоянно будет иметься N-ное количество запросов на ее развитие в соответствие с потребностями бизнеса.

ПОДГОТОВКА ПЛАНА. КЕМ ДЕЛАТЬ?

Теперь давайте рассмотрим требования к разработчику «дорожной карты». Мы считаем, что план развитие ИТ-системы должен выполняться специалистами, которые:

• Смотрят на систему с точки зрения бизнеса, а не со стороны ИТ

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

• Могут оценить возможности и риски использования разных конфигураций «1С»

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

• Понимают специфику и глубину потребностей в автоматизации именно у производителей вашей отрасли

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

• Может оценить готовность предприятия к изменениям в единицу времени

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

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

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

ГДЕ ВЗЯТЬ ГОТОВЫЙ ШАБЛОН КОНЦЕПЦИИ ДЛЯ САМОСТОЯТЕЛЬНОГО ЗАПОЛНЕНИЯ?

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

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