С чего начать ИТ-апгрейд пищевого предприятия? Сначала думаем, потом делаем

Как вы считаете, от чего зависит способ решения задачи? Мы считаем, что от вводных данных. В случае с проектом автоматизации/цифровизации – от запроса на входе.

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

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

Итак, с какими же запросами к нам чаще всего приходят ваши коллеги по цеху?

Примеры:

1. Внедрить «1С:ERP»
Один из самых частых сегодня запросов, продиктованный отменой поддержки решений на платформе «1С:УПП», которая до недавнего времени являлась наиболее популярной среди прочих по рынку.

2. Сменить «старую» платформу
Кто-то все еще работает на семерке, кто-то на Галактике, у кого-то западные решения, требующие замены из-за невозможности обновлений. Отсюда и запрос.

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

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

5. Заменить «SAP» на «1С»
Популярный сейчас запрос по импортозамещению. Заменить западную систему, которая не поддерживается, на какую-то отечественную.

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

Примеры:

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

2. Оцифровать производство для контроля потерь
Мы понимаем, например, что из одной тонны мяса должно получиться полторы тонны колбасы с учетом всех добавок. А получилось почему-то тонна триста. Двести килограмм где-то потерялись. Где? Чтобы узнать, надо оцифровать учет по переделам. Тогда станет понятно, на каких переделах происходят потери.

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

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

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

Такие запросы мы называем узкими. Они направлены на решение конкретной задачи бизнеса. В этом случае мы рекомендуем разработать концепт проекта.
Чем отличаются дорожные карты разработки концепции и концепта – читайте далее.

Если на входе запрос широкий, то, прежде чем стартовать изменения, необходимо определить:

• Архитектура

Из каких ИТ-систем будет реализован наш ИТ-ландшафт.

• План-график

За сколько лет мы сможем прийти к целевому состоянию и какими укрупненными этапами мы туда пойдем.

• Бюджет

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

• Критерии успеха

Когда запрос узкий, есть бизнес цель. Когда запрос широкий, (например, сменить платформу из-за невозможности поддержки старой), каков критерий успеха? (Что-то стало работать лучше, или просто не хуже, чем раньше)? Задаться этими вопросами необходимо заранее.

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

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

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

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

5. Планирование «укрупнённое» план-графика портфеля проектов
Когда понятен набор проектов, составляем укрупненный план график. На данном этапе мы не можем спланировать все точно. Мы даем предварительную оценку сроков, чтобы понять хотя бы в общих чертах – например, 2 года нам понадобится или 4.

6. Определение подходов к реализации проектов
Здесь мы выбираем – идем в проект «от запросов бизнеса» или «от продукта». Если «от запросов бизнеса», то нам предстоит глубокая кастомизация продукта под ключевые бизнес-процессы предприятия, потому что именно они помогают нам обгонять конкурентов. Если мы хотим получить стандартное решение, то в проект мы идем «от продукта» и принимаем, что в каких-то моментах нам придется подстраивать свои бизнес-процессы под него.

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

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

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

• Отраслевой опыт экспертов

Представьте ситуацию: к вам пришли интеграторы, готовые еще вчера автоматизировали машиностроительный завод. Вам придется потратить очень много времени, чтобы объяснить им особенности пищевки. Это не говорит о том, что автоматизировать машиностроительный завод сложнее или проще. Специфика другая. Если вы готовы тратить время и ресурсы своего бизнеса на то, чтобы учить кого-то, тогда вперед. Но всем же хочется сделать быстрее. Нормальный срок разработки концепции для большого бизнеса – до 3 месяцев. Для среднего без существенных организационных проволочек – 3-4 недели. Но только в случае, если у специалистов есть отраслевой опыт.

• Насмотренность вариантов

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

• Широта экспертизы

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

Когда запрос на старте узкий, мы делаем концепт конкретного проекта. Что он помогает нам определить:

• Цель проекта
• Содержание (каким образом мы будем достигать этой цели)
• План-график (сколько времени это все займет)
• Бюджет

Это ключевые результаты, которые нам надо получить от разработки концепта.

1. Проработка бизнес-задачи
Как бы банально ни звучало, сначала надо понять, зачем мы делаем проект.
Обычно это происходит так. Клиент говорит: «Мы тут думали-думали и решили внедрить МЕS-систему». Спрашиваем: «Зачем»? «Хотим на автоматизировать производственный учет». «Зачем»? И так далее. В итоге мы докапываемся, зачем же на самом деле клиенту нужна система. Либо для прослеживаемости, либо для контроля качества продукции, либо для контроля потерь, либо для контроля себестоимость продукции.

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


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

Пример: есть проблемы на складе. Люди думают: «Сейчас внедрим WMS и все проблемы решатся». А может быть склад переваривает такой объем продукции, который не позволяет сделать его работу системной (продукция стоит под потолок и еще все проходы заняты). Да, хаос приносит нам проблемы, но работать данный склад может только в этом хаосе. В этом случае ИТ – не помощник, а скорее враг.


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

Пример: внедряем производственный учет, для контроля потерь. Откуда мы стартуем: с приемки сырья или с получения сырья со склада сырья? Заканчиваем передачей на склад готовой продукции или передачей на участок маркировки? Функционально ограничиваемся только учетом или в границы входит в том числе планирование по рабочим центрам?
Шаг важный. Потому что, если не определить границы на старте, то на финише начнут появляться вопросы: «А это разве не входит»? Чтобы не возникло недопониманий, границы должны быть четко прописаны.


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


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

Хороший вопрос: одна информационная база или микросервисная архитектура? Я считаю, что одна база – это утопия. Споры на эту тему идут уже лет 10. Раньше, когда у всех была одна УПП, спорили меньше. Но объем и количество задач растет и противостояние мнений вместе с ними. Хочется отметить, что в последнее время количество людей, которые перетекают из лагеря «Одна система» в лагерь «Микросервисная архитектура» становится все больше и больше.


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

Яркий пример – автоматизация процессов планирования.
Раньше они были на бумажке. Продажники принимали заказы, записывали их себе в блокнот, потом звонили на производство и говорили: «Мы тут еще заказ принял на 2 тонны продукции, исполни его пожалуйста». И производство принимало. А потом выяснялось, что на складе бардак и постоянные недогрузы.

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


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


8. План график проекта
Занимаясь построением план графика, важно понимать, что проект – это не только то, что делает интегратор. Не бывает таких проектов, в которых 100% задач делает подрядчик. Это всегда команда, причем состоит она не только из ИТ-команды заказчика и ИТ-команда подрядчика. Это также представители бизнеса, которые участвуют в проекте.


9. Бюджет проекта
Здесь мы должны понять, сколько проект будет стоить. Точность оценки бюджета после разработки концепта бывает +/- 20%. Мы считаем, что на этапе старта проекта такая точность является достаточной, чтобы понять ценность и идти в этот проект.


10. Планирование ИТ поддержки
Мало систему внедрить. Ее потом надо как-то поддерживать. И, как ни странно, иногда это упускается.

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

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

Проведем аналогию: бизнес-задача – выкопать большую яму. Копаем лопатами. Чтобы решить задачу, строим экскаватор. Проект – это строительство экскаватора. Но, если нет бизнес заказчика, который сказал, что он ему нужен, а мы построили, то в итоге экскаватор будет стоять, а люди – продолжать копать лопатами.

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


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

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


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

1. Сначала думаем – потом делаем
Без предпроектных работ в проект идти нельзя. Вариант: «Да все понятно! Что там думать? Вот программа, вот люди, надо взять и внедрить», – не работает.

2. Два варианта: концепт и концепция
Однозначного варианта, каким путем идти – нет. Выбор за вами. Готовы ли вы заниматься разработкой всего ИТ-ландшафта? Или хотите начать с решения локальной задачи, (в том числе для того, чтобы получить опыт реализации проектов цифровизации, поднять свою ИТ-грамотность и после этого уже заниматься концепцией)? Но, если вы выбираете второй вариант, надо помнить, что в какой-то момент все равно надо будет вернуться к целостной концепции.

3. Одна голова хорошо, а две лучше
Ошибка, допущенная на более ранней стадии проекта, наиболее сильно влияет на его эффективность.
Люди считают: «Мы сами умные и сами можем сделать предпроект». Нисколько не умаляю ваших заслуг. Однако, альтернативное мнение очень важно. Это как консилиум у врачей. Когда возникают сложные ситуации, (а автоматизация и цифровизация – это сложные истории, потому что компетенций не хватает), объединение мнений нескольких специалистов может сэкономить вам миллионы рублей, которые вы потратите на реализацию ошибочно принятых решениях.