Приблизительное время чтения 8 минут

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

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

7 бед – 1 ответ

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

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

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

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

Типовые слои ИТ-системы пищевого предприятия

В традиционной ИТ-системе предприятии мы (и не только мы) выделяем 3 основных слоя:

  1. Финансовый учет
  2. Оперативный учет
  3. Специализированный (локальный) софт

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

Финансовый учет

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

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

Оперативный учет

Система оперативного учета, как правило, направлена на поддержку исполнения того или иного бизнес-процесса.

Для предприятий пищевой промышленности свойственно два основных вида систем оперучета – системы управления торговыми и производственными операциями. (Разумеется, в реальности видов куда больше, чем два. Однако, торговля и производство – это более 80% функционала оперативного учета у производителей продуктов питания).

  • системы управления торговыми и логистическими операциями

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

  • системы управления производственными операциями

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

Специализированный (локальный) софт

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

Локальный софт не накапливает учетную информацию, а пооперационно передает ее в систему оперучета.

Хорошим примером является кассовое ПО «Front office» у предприятий, имеющих подразделение розничной торговли. Его главная функция – пробивать продукцию на кассе и передавать данные о розничных продажах в систему оперучета.

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

Типовые ошибки распределения задач по системам и их последствия

  • Использование системы финансового учета для ведения оперативного учета

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

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

  • Финансовый и оперативный учет в одной информационной базе

Если мы осуществляем надстройку управления оперативным процессом в системе финучета, нам необходимо, чтобы она была доступна для работы 24х7 (т.к. пищевые предприятия обычно работают в режиме «non-stop»).

Однако, система финучета включает в себя:

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

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

Сопутствующий софт

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

  • Система документооборота

Помимо хранения неструктурированных документов (а-ля Word, Excel и прочих неподдерживаемых основной учетной системой форматов), система документооборота выполняет функцию некоторого «процессного движка». Она обеспечивает автоматизированную передачу бизнес-процесса последовательно от одного исполнителя к другому, если ответственных за выполнение задачи несколько.

  • Система консолидации финансового учета

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

  • Системы MDM (Master Data Management)

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

  • Системы аналитики и визуализации отчетности

Когда система выстроена, а данные накоплены, в игру вступает слой так называемых BI-систем, которые, опираясь на эти данные, обеспечивают их наглядность и в разы упрощают восприятие информации. Вряд ли кто-то будет спорить, что автоматически формирующиеся графики и диаграммы по всем статьям выигрывают у многостраничных и однообразных Excel-таблиц.

Типовая схема ИС для производителя пищевой продукции

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

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

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

Вывод

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

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

Свяжитесь с нами, если у вас появились вопросы

Как разработать концепцию по смене платформы ИС? Инструкция к применению.

Концепция смены платформы ИТ-системы. Обзор практики формирования.

5 3 votes
Рейтинг статьи
guest
0 Комментарий
Inline Feedbacks
View all comments
близко
Связаться с нами

 

×
Copy link