Пошаговая технология разработки плана развития ИТ-системы пищевого предприятия

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

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

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

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

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

1. Использование отраслевой конфигурации «1С:УПП»
Первая ситуация, в которой люди начинают говорить о развитии ИТ-системы – это необходимость вынужденного перехода на новую систему из-за отмены поддержки текущего программного продукта.
Как правило, большинство пищевиков (90-95%) работают либо на «1С:УПП», либо на отраслевых конфигурациях «1С:УПП», (либо работали на них совсем недавно). Соответственно, когда «1С» объявила о предстоящей отмене поддержки данной системы, логично, что у людей возникли вопросы: «куда идти?» и «каким набором шагов это делать?».

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

3. Вы на пороге внедрения «1С:ERP»
В последние 8-9 лет со стороны компании «1С» идет активное маркетинговое продвижение универсальности продукта «1С:ERP». Поэтому запросы на его внедрение стали очень популярны, в том числе среди производителей продуктов питания.

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

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

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

3. Недооценка ресурсов для выполнения проекта
Третье, с чем сталкивается, мне кажется, 90% компаний, которые начинают ИТ-проекты – это недооценка ресурсов. С чем это связано?
Многие возвращаются к старому опыту, (например, к внедрению «1С:УПП» или продуктов на базе «1С:УПП» 10-15 лет назад), но при этом забывают, что бизнес на тот момент был намного меньше и намного менее активный. Не было столько требований со стороны внешних контролеров (Меркурий, Честный знак, торговые сети и т.д.) Да и проекты тогда проходили относительно просто. Можно было внедрить продукт за несколько месяцев небольшим количеством людей. Но все это время (последние 10-15 лет) продукт развивался и на текущий момент получился довольно функциональным и закрывающим большое количество задач, (даже если с архитектурной точки зрения он является неказистым). Соответственно, если сейчас весь этот объем работ мы попытаемся проделать теми же ресурсами, которые потребовались нам при внедрении старой системы, нас неизбежно ждет разочарование.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заполните форму или напишите нам на почту marketing@standart1c.ru «Запрос шаблона концепции», и мы вышлем вам документ ответным письмом.