Jump to content
НЕЗАВИСИМЫЙ ПОРТАЛ
ДЛЯ СПЕЦИАЛИСТОВ МЯСНОЙ ИНДУСТРИИ

Алена_Константа

Профессионал
  • Content count

    23
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Алена_Константа

  • Rank
    Активный участник

Информация

  • Ваш пол:
    женский
  • Интересы и увлечения
    Творчество: дизайн, рисование, музыка, стихи. Спорт: велосипед, лыжи, ролики. Путешествия, походы, новые места, активный отдых.

Реквизиты и ФИО

  • Страна
    Россия
  • Город
    Нижний Новгород
  • Должность
    - PR/Рекламщик/Маркетолог/Аналитик
  • Источник информации о портале
    через поисковую систему в интернете

Страна

  • Флаг
    без флага
  1. Регулярно в ходе наших проектов мы сталкиваемся с очень важным вопросом – организацией IT-ландшафта. И традиционно сразу образуется 2 лагеря: сторонники одной большой информационной системы («лучшая интеграция та, которой не было») и сторонники использования нескольких отдельных информационных систем («под каждого воробья пушка своего калибра»). У каждого из этих подходов есть свои плюсы и минусы, которые мы не будем глубоко затрагивать в рамках этой статьи, однако попробуем раскрыть тему. Как жить безопасно, если интеграции все-таки быть? Если все-таки сложилась ситуация, при которой в нашем IT-ландшафте будет несколько различных информационных систем, то при проектировании этой схемы необходимо предусмотреть методологические аспекты: каким образом мы будем нарезать наши бизнес-процессы таким образом, чтобы они и работали органично (когда на каждом этапе в информационной системе выполняются только те операции, которые должны выполняться) и обеспечивали достаточно целостное информационное пространство, в котором работают пользователи. Попробуем разобрать традиционную для производителей продуктов питания задачу – организацию документооборота с клиентами. И выявить правильные и не правильные способы ее решения. Распространенный вопрос: отделять логистический контур от финансового или нет? Неправильная схема разделения: В логистическом контуре выписываем документ реализации, затем он выгружается в финансовую базу. После возврата документов от клиентов мы начинаем редактировать их в базе финансового учета. И при редактировании у нас получаются изменения, которые влияют на остатки товаров, важные для логистического контура. На лицо нарушение одного из базовых правил – объект должен создаваться и редактироваться в одном месте. Пример правильной схемы разделения: Документы реализации создаются и редактируются в своем контуре, затем за какой-то завершенный период (день, неделя, месяц) документы выгружаются в контур фин. учета. Таким образом получается, что документы создаются и редактируются в одном месте, а база фин. учета является потребителем выверенной информации логистического контура. Если мы методологически грамотно разделили информационные потоки – это уже очень весомый вклад в то, что системы будут функционировать нужным образом. Но у нас так же остается достаточно серьезный вопрос Техническая организация обменов Чтобы не ошибиться с выбором механизма интеграции, необходимо сначала определиться с «калибром»решаемой задачи. Итак, можно выделить 4 уровня ее масштабности: Локальный – характеризуется обменом через внешние файлы. Данный механизм мы относим к классу устаревших, но тем не менее ранее он был достаточно распространен и с некоторыми ИС является единственным доступным вариантом интеграции. Регулярный в однородных средах – подразумевается, что интегрируемые ИС находятся в одной информационной среде. Например, на одном сервере, обмениваются через COM. Такой механизм на текущий момент достаточно часто встречается и позволяет решать задачи интеграции регулярного характера. Его удобно реализовывать, когда у нас имеется относительно небольшое количество ИС. Преимуществом такого подхода является очень легкая настройка и создание программного интерфейса, которым будут пользоваться интегрируемые системы. Регулярный в гетерогенных средах – подразумевается, что интегрируемые ИС могут располагаться на разных серверах, с разными ОС, даже территориально обособлено. Речь идет об обмене через web сервисы. Одно из преимуществ такого подхода – возможность интегрировать базы в различных средах, при этом сохраняя относительно невысокую сложность настройки интеграции. Промышленный – применение отдельно стоящих решений в гетерогенных средах: шины ESB (например DATAREON) или промышленный сервер очередей (например RabbitMQ). Такие решения актуально применять, когда в обмене участвуют более 3-х ИС, когда важно обеспечить качественную передачу НСИ между всеми системами, и когда важно балансировать нагрузку между обменивающимися ИС. Инструменты проверки Когда мы решили первые 2 вопроса в нашем пути интеграции, настает время подумать о поддержке эксплуатации ИС в части интеграции. И здесь встает вопрос о том, чтобы можно было в 1 информационном пространстве сверить данные 2-х интегрируемых систем. Как один из примеров – анализ отгрузок в базах фин. учета и логистического контура. Здесь мы так же выделяем 2 подхода: Пассивный – когда ответственный за участок учета пользователь формирует отчет, который позволяет сравнивать данные за идентичный период в 2-х базах и предпринимать какие-то действия в случае расхождений Активный – когда есть некий анализатор, который регламентно получает 2 набора данных из разных баз, сравнивает их и в случае расхождения оповещает ответственного. Таким образом, если вы планируете строить не просто систему автоматизации фин. учета, а систему управления, в том числе и на оперативном уровне, то вы неизбежно придёте к архитектуре нескольких информационных баз. Наиболее успешные из автоматизированных предприятий потому и являются таковыми, что вовремя осознали ценность концепции микросервисов (когда небольшие отдельные ИС решают узконаправленные задачи), ведь выиграть в конкурентной борьбе им смогли помочь только специализированные решения, которые заточены под их особенности и способны достаточно оперативно реагировать на изменения среды. Именно на примере этих компаний мы понимаем, что для реализации таких подходов требуются надежные и удобные для внедрения и эксплуатации средства интеграции IT систем. P.S.: Интеграция – это задача, а вовсе не проблема. И, при современном уровне ее осмысления и наборе технического инструментария - больше, чем решаемая.
  2. 21 июня 2019 года в Москве состоится практикум для производителей продуктов питания «Переход с 1С:УПП. Куда идти и что делать?» Бизнес в порядке – что это? Это однодневный практикум для производителей продуктов питания. В очном формате обсудим актуальную тему отмены поддержки 1С:УПП и вариантов построения современной ИТ-архитектуры. Разберём реальные кейсы смены платформы информационных сисием на пищевых производствах и ответим на наболевшие вопросы. Основные вопросы мероприятия Какие ИТ-решения есть на рынке автоматизации пищевых производств? Голая правда про 1С:ERP Где граница между оперативным и финансовым учетом? Одна большая информационная база или разные базы с обменом данными? Какой путь выбрать (от простой настройка учета в новой базе до переосмысления роли ИТ в бизнесе)? Как оценить сроки и стоимость перехода? Зачем идти на мероприятие? Возможные варианты архитектуры ИС после отмены УПП. Практика решений в отрасли (с ERP или без). Разбор реальных кейсов смены платформы ИС у производителей продуктов питания. Обзор «граблей». Что может удлинить/усложнить проект и как этого избежать. Общение с коллегами по цеху из разных регионов, но из одной отрасли и с одинаковыми проблемами (как минимум – узнать «как это сделано у других») Практикум состоится 21 июня 2019 года в бизнес-отеле «Ибис» по адресу г. Москва, ул. Бахрушина, 11, строение 2. Подробности о программе, организаторах и порядке регистрации читайте на сайте http://event.standart1c.ru/
  3. Все крупные производители продуктов питания уже давно приняли как данность, что трейд-маркетинговые акции — это один из главных инструментов управления продажами. Однако при этом у многих ещё остаются вопросы: как организовать трейд-маркетинговую активность не в ущерб прибыльности? На начальном этапе работы руководство компании начинает планировать промо акции и старается объективно оценить, как увеличение объёмов готовой продукции скомпенсирует снижение цены и не приведет ли это к снижению маржинальности по участвующей в акции номенклатуре. В дальнейшем начинаются попытки учесть ещё и каннибализм по аналогичным позициям внутри товарной категории. Следующим шагом является осознание, что управлять нужно не отдельными акциями, а набором акцией в рамках одной товарной категории и оценивать достижение целевых объёмов продаж с затратами на организацию программы промо активностей. О целевом варианте управления трейд-маркетингом через маркетинговые бюджеты мы и поговорим в этом материале. Из чего состоит система управления трейд-маркетингом через бюджеты? Планирование регулярных продаж Планирование целевых продаж и ТМ бюджетов Планирование ТМА и контроль бюджета Мониторинг исполнения ТМА Завершение ТМА и контроль фактических затрат Анализ расходования бюджета и достижения целевых показателей продаж Описанная система управления трейд-маркетингом является исполнимой при должной степени автоматизации. На практике же 98% производителей продуктов питания опираются в этих вопросах на Excel. Многие конечно задумываются о необходимости реализации необходимого функционала в 1С, но уж слишком непонятна предметная область штатным программистам и, как следствие, от Excel уйти не получается. Понимая эту проблему, мы разработали типовой модуль автоматизации трейд-маркетинга для производителей продуктов питания, использование которого позволит вам сэкономить деньги, время и думается, что значительное количество нервных клеток:)
  4. В основном потребность в уходе от ручного учета и автоматизации оправдана и востребована на предприятиях с достаточно большим объемом производства, потому что именно тогда появляется выигрыш на стандартизации своих процессов + на оперативности сбора большого количества информации, необходимой для управления предприятием. Однако в этом году к нам поступило множество запросов на автоматизацию отфермерских компаний, которые занимаются производством сыров и цельномолочной продукции в малых объемах (перерабатывают от 1 до 10 тонн молока в сутки). Их руководство тоже изъявило желание стандартизировать свои процессы и оперативно получать реальную информацию о том, что происходит на производстве. И как следствие, иметь возможность анализировать эту информацию в нужных разрезах и быстро формировать отчетность (как управленческую для себя, так и внешнюю для контролирующих органов). Мы среагировали на один из таких запросов и в сегодняшнем материале расскажем об опыте автоматизации оперативного учета на примере Истринских сыроварен, которыми управляет Олег Сирота — небезызвестный производитель русского пармезана. Предпосылки Учет на предприятии ввелся в разрозненных системах — журналы, самописная база данных на Access, 1С:Бухгалтерия, Excel. В связи с ростом объема производства и объема операций, которые требуют учета, часть персонала компании полностью переключилась на учетные функции. А для небольших предприятий занятость такого количества людей только учетом – это роскошь. В большинстве случаев необходима параллельная вовлеченность в задачи по развитию бизнеса и помощь руководителю компании с другими вопросами. Поэтому и было принято решение перевести учет в единую базу на платформе «1С: Управление нашей фирмой». На данный момент — с минимально достаточным функционалом (с каким именно – см. описание ниже), но имеющим потенциал для дальнейшей детализации учета по отдельным участкам производства. Что было сделано? На базе «1С:УНФ» мы настроили: Оперативный учет варок Здесь все довольно просто, так как сырье поступает от проверенного поставщика (своего стада) и полностью перерабатывается. Поэтому для учета интересен только объем полученной продукции с привязкой к дате варки. Учет созревания Реализовано раннее резервирование сыров (т.к. на предприятии существует возможность приобрести сыр по предзаказу) и автоматический переход между разными стадиями созревания сыров. Загрузка в систему предзаказов с сайта компании Учет торговых операций 1) Формирование заказов от магазинов 2) Закупка сопутствующих товаров для розничных магазинов 3) Настройка АРМ наборки на складе готовой продукции в том числе интеграция с весовым оборудованием и принтером этикеток) Ввиду того, что это одна из самых трудоемких операций, был реализован АРМ наборки для их ускорения и минимизации лишних действий во время наборки. Работа с ним ведется через планшет на рабочем месте наборщика: в момент набора продукции под сформированный заказ путем взвешивания реальных голов сыра и передачи веса в информационную систему на каждый короб с головой сыра происходит выдача соответствующей этикетки. 4) АРМ транспортного логиста У компании есть несколько собственных автомобилей с различной грузоподъемностью и вместительностью (Ларгусы и Газели) и постоянно увеличивающееся количество заказов. Поэтому для удобства распределения заказов по машинам (до точек доставки и покупателей) был реализован АРМ транспортного логиста. 5) Загрузка информации о розничных продажах из системы Эвотор Расчет себестоимости продукции Так как в один день происходит варка только одного вида сыра и йогуртов, то «сложный» отраслевой вариант распределения стоимости материалов пропорционально жиро-белко-килограммам для данной компании оказался избыточен. Поэтому в системе настроили распределение по фактически потребленному объему молока на соответствующие виды продукции. Прочие операции 1) Учет коров и производства собственного молока 2) Учет ДС 3) Закупка прочих материалов Интеграция с системой бухучета Реализована автоматическая выгрузка данных большинства хозяйственных операций в системы бухучета для исключения ручного ввода информации силами бухгалтера. Что это дало? Возможность учитывать возрастающий объем производства силами того же количества людей + выделение у них свободного времени для выполнения других задач по развитию бизнеса Возможность оперативно видеть остатки готового сыра, объем голов на созревании и сроки созревания (в том числе количество зарезервированных голов), что позволило повысить качество обслуживания клиентов Возможность проанализировать себестоимость и маржинальность продукции в разрезе каждого вида сыра и йогурта, а не «котлом», как раньше Вместо эпилога В завершение хочется сказать, что опыт получился интересный и полезный (как для клиента, так и для нас). Получается, что с помощью «1С» фермерские хозяйства могут повысить оперативность и прозрачность своего базового оперативного учета относительно быстро и недорого. Сейчас мы работаем над отраслевым коробочным решением для небольших фермерских хозяйств по производству сыров, чтобы они, как и более крупные компании, могли еще более грамотно и эффективно управлять своим производством. Как только получим первые отклики от клиентов – поделимся. Всем неравнодушным к своему благородному делу — накормить страну, хочется пожелать успехов в их нелегком труде. Если будет нужна помощь для повышения эффективности вашей работы – обращайтесь, будем рады помочь!
  5. Андрей, добрый день! Прошу прощения за долгий ответ. Система работает у нескольких наших клиентов. Максимальный срок эксплуатации - 2 года. Описанная в статье схема заложена в функционал системы.
  6. В конце 2018 года переработчиков молока захлестнула волна беспокойства в связи с предстоящей обязанностью перейти на учет готовой продукции в ГИС «Меркурий». И произошло это уже ни в первый раз. Причина тому – отложенное до июля 2019 г. вступление в силу закона + неофициальные новости от Минсельхоза о более раннем старте работы молочников с электронными ВСД. «Минсельхоз РФ рассчитывает, что готовая молочная продукция с апреля 2019 года будет учитываться в системе электронной ветеринарной сертификации «Меркурий». — Сообщила журналистам замминистра сельского хозяйства Оксана Лут (источник — milknews.ru). А вскоре и на сайте «ВетИС» открылось активное обсуждение грядущих изменений. Символично, что именно 1-ое апреля установлено как очередной срок, когда от молочных предприятий ждут включения в работу с электронными ВСД. В свете того, что это уже далеко не «первое предупреждение», сделанное Минсельхозом, не является ли оно первоапрельским розыгрышем? Впрочем, шутки в сторону. Сегодня хочется поговорить о явных трендах госконтроля, которые прослеживаются для производителей продуктов питания. Ведь «Меркурий» — не единственный внешний контролер, которому необходимы полные данные обо всех этапах переработки в рамках цикла преобразования сырья в готовый продукт, ложащийся на полки магазинов. Как первопричина ужесточения контроля с внешней стороны была обозначена борьба с фальсификатом, недобросовестными производителями продуктов питания и забота о конечном потребителе. Благое намерение. Однако при этом остается непонятным – возможно ли достичь реального контроля прослеживаемости сырья на молочном и мясном производстве? Не станет ли это поводом для фальсификации итоговых данных учета в информационных системах предприятий? Требования и тренды Попробуем просуммировать – у кого есть требования к производителям продуктов питания по предоставлению данных о движении сырья? Россельхознадзор Требование для экспортеров продуктов питания обеспечить прослеживаемость сырья + ГИС «Меркурий» с его обязательной ветеринарной сертификацией для мясников и молочников Сетевые клиенты Требования по маркировке готовой продукции и партионному учету от сырья до выхода с производства и далее. ХАССП Давно уже не новые стандарты для пищевого производства, но забывать про них не стоит. ЦРПТ Пока ещё находящаяся на пилотной стадии, но грозящая стать обязательной для многих цифровая маркировка и обязательность прослеживаемости товаров в России и ЕАЭС. Сейчас маркируются только меховые изделия и алкоголь. А в будущем это якобы потребуется и от остальных производителей товаров повседневного спроса (в 2019 г. – для табака, обуви, некоторых видов одежды, шин и покрышек, фотокамер и ламп-вспышек). Появится ли что-то еще — пока трудно загадывать. Но тренд контроля за движением сырья и производителями товаров повседневного спроса, в т.ч. производителями продуктов питания отслеживается явно. До первопричин и бенефициаров такого контроля на данный момент докопаться все равно не удастся, поэтому приходится рассматривать все как факт. Нам, как автоматизаторам пищевых производств, за прошедший год регулярно приходилось сталкиваться с запросами – «помогите настроить и автоматизировать учет для Меркурия/аудита сетей/прослеживаемости по ХАССП и т.д.». При этом и клиент, и мы понимаем, что пользы бизнесу от автоматизации немного – это всего лишь исполнение внешних требований со стороны проверяющих органов, которым можно транслировать не реальные данные о происходящем на производстве, а всего лишь данных в том виде, который будет их удовлетворять и одновременно не мешать работе предприятия. А ведь организация достоверного оперативного учета движения сырья, полуфабрикатов и готовой продукции на предприятии может принести немало пользы для управленцев на производстве/складах и ТОП-менеджменту. Ибо помимо внешних требований со стороны проверяющих органов есть фактор конкуренции на рынке. И чтобы «не выпадать из рынка», надо: понимать эффективность работы своего предприятия, контролировать-минимизировать потери на производстве и складах, обеспечивать высокое качество готовой продукции и стандартизировать процессы для снятия зависимости от «талантов» исполнителей на местах. Сразу стоит оговориться, что многие предприятия в определенном виде получают информацию о том, сколько сырья принято, сколько выпущено полуфабрикатов и готовой продукции и т.д. Но! Стоит сделать акцент именно на оперативности, полноте, достоверности и объективности этой информации, т.к. у многих производство (а у кого-то и склады) остаются «черным ящиком» из-за ручного контроля внутренних процессов с помощью журналов. В противоположность ручному учету наличие автоматизированной системы учета решает все эти проблемы. Вот и получается, что наличие внешних требований является хорошим стимулом для наведения порядка у себя на предприятии и повышению эффективности производства, а далее, как следствие этого, и конкурентоспособности конечного продукта на рынке. Прошлогодняя практика внедрения ГИС «Меркурий» у мясопереработчиков показала, что многие до последнего откладывают изменения у себя на предприятии, а преступают к реорганизации только когда становится понятно, что тянуть с обеспечением внешних требований больше нельзя. А ведь для средних и крупных производителей продуктов питания внедрение автоматизированной системы, которая способна будет обеспечить одновременно и внешние (от проверяющих) и внутренние (от управленцев) требования учёта — это вопрос усилий, времени (более 2-3 месяцев) и денег. При этом те, кто реализовал у себя оперативный учет задолго до «Меркурия» и сетей, не испытывают сложности с отправкой необходимых данных в любую систему отчетности (внутреннюю или внешнюю). Вместо завершения Думайте сами – оставлять все на последний момент или заранее заняться наведением порядка на своем предприятии. За нашими плечами опыт реализации самых различных схем учета у средних и крупных производителей продуктов питания. Мы имеем в своём арсенале не только знания – «как это сделать?», но и готовые программные решения, которые позволят вам быстро реализовать задуманное. Если потребуется помощь специалистов – обращайтесь. Мы найдём способ как вам помочь.
  7. «1С» официально объявила, что в скором времени завершит поддержку широко используемого на территории РФ продукта «1С:Управление производственным предприятием». Ну и как следствие - всех его отраслевых версий. Это заставило многих использующих это ПО задуматься о том - что же им делать? «1С» со своей стороны предлагает как стандартное решение переходить на свой новый флагманский продукт «1С:ERP». Однако стоит остановиться и порассуждать - единственный ли это вариант развития событий? Попробуем разобраться с этим вопросом на примере условного производителя продуктов питания (так как мы работаем именно с такими клиентами, то и адресуем этот материал именно им). Итак, на входе у нас молокозавод, автоматизированный на «1С:Молокозавод» (отраслевое решение на базе «1С:Управление производственным предприятием»). Продукт внедрён в компании ещё в 2010 году. На старте были автоматизированы только базовые функции: оперативный учет отгрузок и бухгалтерский учет. Но за прошедшее время предприятие развивалось и в процессе эксплуатации был автоматизирован целый ряд функций, обычно используемых на практике у других пищевых производств: · работа с клиентами через EDI · транспортная логистика · процессы маркировки логистической упаковки · процессы наборки на складе с использованием терминалов сбора данных · пакетная печать отгрузочных документов · оперативный учет на производстве с автоматизированными рабочими местами для операторов · налоговый учет · управленческая отчетность И это только крупные блоки… К текущему моменту времени информационная система стала «скелетом», обеспечивающим работу предприятия в соответствии с требованиями рынка. И замена продукта с таким количеством настроек и доработок – это уже совсем не замена системы только бухгалтерского учета, которая не сильно влияет на операционную деятельность. За один подход выдернуть этот «скелет» из организма организации и вставить новый, пусть даже много лучший чем старый, невозможно. Как же быть? Чтобы перейти к возможным сценариям перехода с «1С:Молокозавод» в такой степени использования на другие программные продукты проясним 2 пункта: 1) В любой информационной системе выделяется как минимум 2 слоя: a. Оперативный учет, обеспечивающий функционирование бизнес-процессов предприятия (приемка сырья, попередельный выпуск полуфабрикатов и готовой продукции, складские процессы, транспортная логистика и т.д.) b. Финансовый учет, который на основании данных оперативного учета, интерпретируя их через учетную политику, подготавливает финансовую отчетность (бухгалтерский учет здесь рассматривается как один из видов финансового учета) 2) Когда речь идёт про прекращение поддержки «1С:УПП», то разговор в первую очередь идет про прекращение обновлений форм бухгалтерской отчетности. Доработанный и настроенный функционал оперативного учета при этом никак не пострадает. Итак, исходя из вышесказанного, рассмотрим возможные сценарии перехода с «1С:УПП»: 1) Бухгалтерия завода переходит на «1С:Бухгалтерия предприятия», оперативный учет без изменений. // При реализации такого сценария мы не трогаем оперативный учет и оставляем его в «1С:УПП» на видимом горизонте времени, а для решения задач бухгалтерского учета внедряем стандартную «1С:Бухгалтерия предприятия» + настраиваем выгрузку оперативных данных в неё из «1С:УПП». Да, в таком варианте появляется это страшное слово интеграция, которого многие боятся. Но практика реализации такого сценария показывает, что сложности интеграции связаны, как правило, не с самим фактом её наличия, а с её плохой реализацией (либо на методологическом уровне, либо на техническом). Такой сценарий самый быстрый и самый дешёвый, но при этом для большинства компаний я бы порекомендовал именно его. 2) Бухгалтерия переводится на «1С:ERP» или «1С:Комплексная автоматизация 2.0» (в текущей реализации - немного упрощённая версия «1С:ERP»), оперативный учет без изменений. // Данный сценарий отличается от предыдущего только программным обеспечением, выбранным для ведения бухгалтерии. При этом такой сценарий видится неоправданно усложнённым в большинстве случаев (хотя бывают, конечно, исключения, когда это оправдано). Выбор такого сценария, на мой взгляд, оправдан только если вы планируете развитие системы бюджетирования после автоматизации финансового учета. При этом вам должна нравится модель бюджетирования, заложенная в «1С:ERP», и вы не хотите разделять базу финансового учета и базу бюджетирования. 3) Переход с «1С:УПП» на «1C:ERP» и в части оперативного учета и в части финансового учета. // Это самый рекламируемый компанией «1С» и самый «интересный» для тех, кто будет его реализовывать, сценарий (читай - самый сложный и самый спорный). Если компания хорошо представляет себе процесс перехода, который для среднего предприятия на практике займёт примерно 2 года и порядка 10 млн рублей, то это одно дело. Однако если компания рассчитывает поменять свой «скелет» за 3-6 месяцев (такое ощущение может создаться на основании не всегда достоверной рекламы), то её ждёт разочарование и с большей долей вероятности финансовые потери, связанные с существенными сбоями в операционной деятельности. Затевать такой сценарий только для решения задач обеспечения обновляемости бухгалтерской отчетности точно не целесообразно. А вот если стоит задача повышения уровня упорядоченности и автоматизированности операционной деятельности взамен текущих процессов на «1С:УПП», то мы рекомендуем рассматривать специализированные программные решения, которые уже несут в себе принятые отраслевые практики и за счет этого обеспечивают более быстрое и менее стрессовое внедрение. Для примера, раз уж в статье идёт речь про молокозавод, можно посмотреть на решение для сыродельных предприятий или с решением по автоматизации складов готовой продукции. Конечно я выделил только основные варианты сценариев, которые возможны на практике (и при этом у них может быть масса вариаций), но, думаю, общая концепция понятна. Главное, что бы мне хотелось – это чтобы вы понимали - для чего вы планируете изменение платформы автоматизации. И уже исходя из этого выбирали наиболее прагматичный путь. P.S. В последнее время нам как внедренцам на волне обновления линейки программных продуктов «1С» (в т.ч. и отказе от поддержки «1С:Комплексная автоматизация» и «1С: Управление производственных предприятий») все чаще приходится сталкиваться с всплеском активности в задачах автоматизации у производителей продуктов питания. При этом всё чаще встречаемся с ситуациями недооценённых внедрений, наносящих ущерб и бизнесу, и людям, выполняющим эти проекты. Надеюсь, что эта статья хоть немного добавит некоторого здорового скепсиса при вашем выборе смены платформы автоматизации и уменьшит количество неудачных проектов. Если кто-то попал в такую неудобную ситуацию и не может определиться с планом замены текущей 1С:УПП, то можете обращаться к нам, и мы подскажем – какой конкретно вариант будет наиболее удобный и менее болезненный для вашей компании.
  8. После одного из наших проектов автоматизации участка специй на мясокомбинате пришла мысль, что хороший технолог на пищевом производстве – как шеф-повар в ресторане :). Он точно знает какие нужны ингредиенты и какие добавки нужно использовать, сколько и в какой последовательности жарить/парить/варить – чтобы сделать вкусный, по возможности недорогой, но главное — качественный продукт. Все это хорошо в теории, но когда технология приготовления продукта передается на исполнение цеховым рабочим, то встает непростой вопрос – как обеспечить то же «шефское» качество продукции на промышленных объемах производства? Для этого описывается технология (рецептуры и параметры процесса обработки), проводится инструктаж-обучение рабочих,продумываются мотивация и показатели, вводится контроль процесса со стороны мастеров и контролеров, и пр. И все это правильно и необходимо. Но к сожалению– не всегда достаточно. Но есть и другой способ! Обеспечение (и даже повышение) качества продукции – за счет автоматизации контроля соблюдения технологии и рецептур – это одна из основных задач MES-системы. К справке, MES-система –автоматизированная система внутрицехового управления производством, которая помогает начальнику производства и технологу сокращать потери и обеспечивать необходимое качество продукции. Летом текущего года один наш клиент (быстрорастущий мясокомбинат Нижегородской области) пришел к пониманию,что в управлении производством требуются изменения, и замахнулся на внедрение системы внутрицехового управления производством. Первым шагом было решено автоматизировать участок специй для решения следующих задач: Полная идентификация партий поступающих специй и ингредиентов Формирование заданий на подготовку комплектов специй на основании сменного задания на производство Расчет потребности объема специй под сменное задание Учет наборки комплектов специй с автоматизированным контролем рецептуры и веса ингредиентов. Учет комплектов специй в нескольких пакетах Учет передачи комплектов специй на участки переработки Учет остатков специй («россыпью» и в комплектах)на участке набора специй Учет инвентаризаций Общая схема решения выглядит следующим образом: Рисунок 1. Общая схема автоматизации участка специй Ключевой инструмент в решении – это АРМ наборки комплектов специй по рецептуре. С помощью этого инструмента как раз производится контроль состава и объема ингредиентов, которые закладываются в комплект специй. Рабочее место комплектовщика оборудовано: сенсорным экраном для удобной работы с заданием и подтверждением его выполнения сканером штрих-кода, которым сканируется этикетка партии очередной специи, набираемой в комплект весами, на которых взвешивается очередной ингредиент, и вес сразу передается и учитывается в системе термопринтером этикеток, на котором при завершении наборки печатаются этикетки и клеятся на пакеты с набранным комплектом специй Рисунок 2. Автоматизированное рабочее место комплектовщика Как это работает? 1. Комплектовщик выбирает в «1С» очередное задание на наборку специй, где ему открывается окно с рецептурным составом данного комплекта и плановым объемом ингредиентов, которое соответствует объему замеса из сменного задания на производство: Рисунок 3. АРМ наборка по рецептуре 2. Комплектовщик берет первый из взвешиваемых ингредиентов, сканирует этикетку партии с мешка –и система проверяет – есть ли данный ингредиент в рецептуре набираемого комплекта. Если проверка не прошла – система подсказывает об этом. Если прошла– предлагает продолжить взвешивание. 3. Комплектовщик начинает отвес специй, в процессе которого в «1С» с весов сообщается набранный вес. Комплектовщик подтверждает завершение отвеса, и система проверяет –соответствует ли набранный вес плановому с учетом погрешности весов. Если проверка не прошла – система сообщает об отклонении. 4. Таким образом происходит отвес и добавление в комплект каждого ингредиента. После завершения комплектовщик подтверждает окончание наборки комплекта и печатает этикетки на все пакеты. Благодаря такой организации работы с комплектацией специй: наборщику не нужно помнить или хранить вокруг себя талмуды с рецептурами, так как все актуальные рецептуры и их изменения хранятся в системе и интерактивно используются в процессе комплектации система встроена в процесс комплектации и помогает наборщику не допустить ошибку как по составу рецептуры (за счет сканирования этикеток партий и контроля остатков специй), так и по объему закладываемой специи (за счет интеграции с весами и проверке набранного объема заложенному нормативу) И пусть пока не на всем производстве, но на первом участке, с которого наш клиент решил запускать MES-систему – появляется гарантия рецептурного состава, а значит качества будущего продукта.
  9. Сегодня мы затронем область, которая по опыту нашего общения с компаниями сектора FMCG наименее технологизирована и автоматизирована (но при этом является ключевой для развития любого предприятия) – продажи. В последнее время запросы на автоматизацию а-ля «хотим внедрить CRM» всё чаще слышны от наших клиентов. При этом практически никто из них не может сказать – что такое CRM для производителя продуктов питания и чего они от этого хотят? Что ж, попробуем добавить ясности в этот вопрос. О ком речь? Модели управления продажами серьезно отличаются для производителей разного масштаба с разной территорией представленности. Поэтому, чтобы не вносить путаницу, сразу оговорюсь – сегодня будем рассматривать только управление продажами для тех производителей, которые: продают несколько товарных категорий работают в нескольких регионах через разные каналы ставят для себя цели расширения продаж, а не просто работают по принципу «продаем то, что само продается» Про товарные категории При управлении продажами мы выделяем основной объект управления – это одна товарная категория в одной группе планирования клиентов. Как правило, группа планирования – это пересечение канала и региона продаж (см. схему ниже). А для крупных сетевых клиентов вообще логично выделять под каждого клиента один элемент в группах планирования. Пример выделения товарных категорий и групп планирования клиентов Хочется отметить что продукты питания – это один из наиболее склонных к корректному планированию товаров, так как потребление имеет самый короткий цикл и высокую повторямость. Однако это относится только к тем продажам, когда мы управляем поставками на полку магазина (или РЦ в случае с сетевыми клиентами). В случаях же, когда мы продаём посредникам и не управляем/не контролируем поставки на полку, управлять такими продажами мы не можем, поэтому и не будем рассматривать этот вариант (большинство компаний уже осознали, что полагаться в продажах на посредников-перекупщиков или неуправляемых дистрибуторов ошибочно и все стараются выстраивать управляемые каналы продаж). Про структуру продаж Структура продаж в рамках одной ячейки из вышеуказанной схемы состоит из следующих элементов: 1. Регулярные продажи Тренд регулярных продаж Сезонный элемент продаж (как «+» так и «-» относительно средней статистики продаж по году) 2. Продажи за счет дополнительных активностей Промо продажи (активности в основе которых снижение цены «на полке» в различных механиках акций для стимулирования сбыта) Рекламная поддержка продаж (например, реклама по TV) Коммерческие активности (например, дополнительная мотивация продаванов за фокусные SKU) Исходя из структуры продаж понятно, что для достижения интересующих целевых показателей продаж нам необходимо: спрогнозировать регулярные продажи с учетом тренда продаж, коэффициентов сезонности понимая разницу между целевыми продажами и прогнозом регулярных продаж, запланировать дополнительные активности (чаще всего это бывают промо-акции). При этом мы понимаем, что продавать 1 рубль за 99 копеек любой сможет)) Поэтому задача управления продажами сводится к тому – как с минимальными бюджетами затрат на продажи добиваться выполнения целевых показателей по плану продаж. Про методику планирования продаж На основании нашего опыта автоматизации продаж и исследовании международного опыта (в частности методики планирования продажи операций) мы разработали методику планирования/управления продаж, представленную на схеме ниже. У ряда компаний уже реализована подобная схема планирования/управления продажами, но это сделано в Excel (и даже если частично в «1С» что-то сделано, то большинство оперативной работы всё равно ведется в Excel). Мы же разработали полноценную модель в рамках нашего отраслевого продукта на базе «1С» для производителей продуктов питания — «K2FRESH». Если ваше видение продаж коррелирует с представленной выше схемой, то наше программное решение станет для вас существенным подспорьем на пути к технологизации и автоматизации продаж. P.S. Управляйте продажами зряче и продавайте больше! А если вопросов все еще больше чем ответов – обращайтесь и мы поможем.
  10. За последний год производители продуктов питания с завидной регулярностью получали новые требования и от сетевых клиентов, и от государственных контролирующих органов. При этом требования эти постоянно менялись и многие запутались – что же нужно предоставить клиентам и государственным контролерам? А так как нет ясного понимания – какую информацию нужно предоставлять, то ещё менее понятно – какие изменения нужно внести в свои процессы логистики чтобы обеспечить себя необходимой информацией (в первую очередь). И уже при необходимости быть готовыми поделиться ей с внешними потребителями. Для начала разберёмся – какие требования актуальны для производителей со стороны клиентов и контролирующих органов: EDI. Эта аббревиатура уже давно не в новинку для большинства поставщиков. Если ранее этот инструмент использовался для приёма заказов от клиентов, то в 2017 году сетевые клиенты начали требовать отправку уведомлений об отгрузках и в ответ начали присылать уведомления о приёмке. В дальнейшем сети с этими уведомлениями сравнивают отправленные им электронные накладные. А в 2018 году появились еще и требования по отправке SSCC-кодов транспортных упаковок. Маркировка транспортных мест. Требования по маркировке готовой продукции и ее упаковке были и ранее, но в 2018 году для корректной обработки электронных ветеринарных сертификатов и оптимизации своих процессов сетевые клиенты сформировали новый набор требований по маркировке, которая должна позволить через штрихкод считать необходимую клиенту информацию (о товаре, дате производства, партии производства, количестве товара). На данный момент времени требования от сетей всё ещё не устоялись и, следовательно, многие производители до сих пор их не реализовали. ГИС «Меркурий». Если с сетевыми клиентами кто-то не работает и его не касаются требования сетей, то требования государства не может игнорировать никто и это нововведение 2017 г. об обязательности оформления электронных ветеринарных сертификатов касается почти всех (в большинстве своем – переработчиков мяса и молока). Задача отправки информации в ГИС «Меркурий» не так сложна (есть вариант и ручного оформления в ВЭБ-версии и автоматизированной отправки через программные решения). Проблемными являются только те случаи, когда клиенты отправляют сотни или тысячи накладных, так как сервера «Меркурия» не всегда позволяют оформить такой объём отгрузок с учетом всех требований законодательства за разумное время. Одна только задача получения данных по отгружаемой продукции в разрезе номенклатуры, количества, даты производства, партии производства, SSCC-кода транспортной упаковки требует изменения производственных процессов и процессов на складах. Для обеспечения целостности системы логистики целесообразно рассматривать все требования в совокупности. Что ж, выделим ключевые участки учета в логистике, которые влияют на обеспечение реализации требований внешних потребителей, и разберём как их можно реализовать: 1. Маркировка транспортных мест и формирование монопаллет Тут возможны разные варианты – от простой ручной печати этикеток на весах до автоматизированных маркировочных комплексов. Нам, как наиболее прагматичный вариант, видится оснащение рабочего места маркировки информационным киоском с принтером этикеток для продукции с фиксированным весом. А в случае с весовой продукцией – то же рабочее место, но с дополнительным подключением весов. Такой вариант позволяет минимизировать ошибки оператора, так как ему нужно только указать выпускаемую продукцию, а система сама сформирует этикетку по всем требованиям, указанным в нормативно-справочной информации. Таким же образом учетная точка на этапе маркировки позволяет фиксировать выпущенный с производства объём продукции в разрезе всех необходимых аналитик. А это уже может быть использовано для отражения соответствующих операций в ГИС «Меркурий» (для тех, кого это требование касается). В случае целесообразности в момент выпуска можно сразу же формировать монопаллету с присвоением ей SSCC кода и печатью паспорта паллета (при отгрузках монопаллетами в таком варианте нам не нужно будет дополнительно маркировать паллеты, а можно будет лишь просканировать SSCC-код). Рисунок 1. Рабочее место, оборудованное информационным киоском, принтером этикеток и весами 2. Наборка продукции под клиентов и формирование сборных паллет При наборке продукции под заказ клиента удобно использовать бумажную наборную ведомость, на основании которой выполняется непосредственно сборка (возможен вариант, когда заказ на наборку сборщик получает в электронном виде на ТСД). И уже после фактического набора в зоне комплектации работник склада сканирует с помощью терминала сбора данных сначала наборную ведомость, и далее – сканирует транспортные места продукции. Обращу внимание – здесь не рассматриваем вариант отгрузки штучной продукции (мы сторонники уменьшения транспортного места при необходимости, но не сторонники штучной отгрузки). После сборки полной паллеты сборщик формирует SSCC-код паллеты и печатает паллетный лист. При необходимости готовая паллета может ставиться на напольные весы, с которых система будет считывать вес брутто и указывать его в паллетном листе. Рисунок 2. Терминал сбора данных (ТСД) (Мы рекомендуем применять ТСД с большим экраном (при этом не нужны кнопки, управление ТСД аналогично смартфону) и работать со специализированными формами 1С непосредственно с ТСД через WI-FI.). Как мы видим на реализацию требований влияют только 2 участка учета на складе, и их реализация не является неразрешимой проблемой. Однако в виду запутанных требований от внешних потребителей становится проблематично сформировать лаконичные требования к маркировке и учету отгрузки. Поэтому и происходит некая путаница с тем – кому, что и как надо сделать, чтобы удовлетворить требования покупателей и контролирующих органов. Мы уже не раз реализовали такие схемы учета и имеем в своём арсенале не только знания – как это сделать, но и готовые программные решения, которые позволят вам быстро реализовать задуманное. Если для вас актуальна рассмотренная задача, то обращайтесь – мы вместе найдём способ как вам помочь.
  11. ПРОСЛЕЖИВАЕМОСТЬ? ЭТИМ ТОЧНО НУЖНО ЗАНИМАТЬСЯ? Прослеживаемость в пищевом производстве – это средство обеспечения требований пищевой безопасности. В случае (не дай Бог) возникновения проблем с качеством продукции и угрозы здоровью потребителей – предприятие-производитель должно: Правильно понять – в какой партии выпущенной продукции возникла проблема, т.е. идентифицировать и локализовать проблемные партии продукции (на своих складах и в отгрузках клиентам) Восстановить информацию: из каких партий сырья и материалов была произведена проблемная партия продукции через какое оборудование и через чьи руки прошла проблемная продукция в ходе производства (чтобы провести адресные корректирующие и профилактические мероприятия с конкретным персоналом, причастным к проблемам с качеством продукции Провести анализ и выяснить, какие партии материально-сырьевых ингредиентов привели к проблемам с качеством продукции Выяснить – в каких еще партиях продукции были использованы эти некачественные материально-сырьевые ингредиенты и убедиться, что с качеством этой продукции все в порядке Чем точнее в этой рекламационно-претензионной работе будут определены проблемные партии – тем меньший объем продукции необходимо будет проверять и/или отзывать. То есть предприятию вся эта рекламационная работа обойдется меньшими затратами. Не смотря на очевидную пользу для потребителя и выгоды для предприятия – всерьез организацией прослеживаемости производители-пищевики начали озадачиваться в последние 2-3 года. На подавляющем большинстве пищевых производств сейчас организован «журнальный» вариант прослеживаемости: когда все движение сырья и продукции по этапам производства записывается в бумажные «талмуды». И когда возникает вопрос – из чего была сделана сегодняшняя продукция или в какую продукцию вошло сырье, купленное у конкретного поставщика – происходит либо нудное и скрупулёзное «перетряхивание» журналов, либо умышленное лукавство и волевое «назначение виноватых» (как партий сырья или материалов, так и людей). ДЛЯ КОГО НУЖНА ПРОСЛЕЖИВАЕМОСТЬ Нарастающий интерес последних лет к организации и автоматизации прослеживаемости в производстве у пищевиков связан в первую очередь с ужесточением требований сетевого ритейла. Сети проводят собственные аудиты процесса производств, технологии и прослеживаемости, результаты которых определяют коммерческие условия дальнейших отношений производителя с сетью. Это стимулирует производителей искать способы соответствовать требованиям сетей. В ту же сторону внимание переработчиков мяса и молока направляет Россельхознадзор со своими законодательными инициативами по внедрению ФГИС Меркурий: для погашения ветеринарных сертификатов переработчики жиров животного происхождения должны сопоставлять из какого сырья была произведена продукция. А после внедрения и по мере дальнейшего развития ФГИС Меркурий отраслевые эксперты ожидают, что требования к точности этого сопоставления будут повышаться. Помимо внешних мотиваторов наиболее продвинутые предприятия хорошо осознают и свои внутренние профиты от наличия адекватной прослеживаемости. Это и сокращение затрат на претензионную работу, и имиджевые преимущества перед конкурентами. Так или иначе наличие адекватной организации прослеживаемости – это явный отраслевой тренд, который сейчас дает набор конкурентных рыночных преимущества, а в ближайшей перспективе обещает стать гигиеническим условием существования промышленного пищевого производителя на рынке. ОПЕРАТИВНЫЙ УЧЕТ В MES-СИСТЕМЕ – ОСНОВА ДЛЯ ОРГАНИЗАЦИИ ПРОСЛЕЖИВАЕМОСТИ В своей предыдущей статье я рассказывал про подходы к организации системы оперативного учета на пищевом производстве – что и как нужно сделать, чтобы организовать и внедрить MES-систему. А сегодня я расскажу, как MES-система у нашего клиента (цех глубокой переработки мясного сырья), внедренная в соответствии с рекомендованными нами подходами, обеспечила клиенту основу для получения прослеживаемости производства. К проекту внедрения MES-системы наш заказчик определил следующие ключевые цели и задачи: Оперативный попередельный учет технологических этапов производства продукции, в том числе: Учет объемов выработки полуфабрикатов и продукции с разделением на производственные партии Учет фактически использованных объемов и партий сырья и полуфабрикатов для выработки продукции Контроль и анализ потерь и выходов продукции Соблюдение технологии и стандартизация качества продукции за счет: Рецептурного контроля формирования сырьевых и материальных комплектов Контроля технологических параметров и времени обработки партий продукции на ключевых этапах переработки, влияющих на качество продукции или показатели выхода Обеспечения своевременного и упорядоченного по дате выработки движения и обработки партий сырья и полуфабрикатов При решении первой группы задач проекта была организована идентификация (этикетирование с использованием штрихкодов) парий поступающего в цех сырья и выпускаемой продукции и внутрицеховых полуфабрикатов. А далее, используя идентифицирующие этикетки, на каждом контролируемом переделе производства был обеспечен оперативный автоматизированный учет выработки партий продукции и использованных при производстве партий сырья. Таким образом, организованные процессы достоверного учета движения и переработки сырья и полуфабрикатов в производстве сформировало связку «партия сырья – партия продукции» для каждого передела. А накопление этой информации в системе за любой день и смену позволило, используя алгоритм разузлования, получить желаемую прослеживаемость – отчеты, которые показывают: Из чего (каких партий сырья и материалов) была произведена конкретная партия продукции В какие партии продукции вошла конкретная партия сырья. Вариации полученных отчетов позволили проанализировать информацию по прослеживаемости как в древовидной форме (показывая историю появления промежуточных цеховых полуфабрикатов, даты их выработки и бригады рабочих), так и в линейной – когда показывается какое покупное сырье было использовано в продукции (без промежуточных переделов). Отслеживание истории продукта: (для просмотра изображения — нажмите на него левой кнопкой мыши) Отдельный вопрос в теме организации прослеживаемости – это какое оборудование можно-нужно использовать в связке с MES-системой, чтобы процесс оперативного учета был действительно оперативен, объективен и не зависим от конкретных исполнителей. Об этой теме мы уже говорили здесь. А позднее напишем материал с описанием конкретных решений у конкретных предприятий по переработке мяса, молока и производству сыра. В ЗАВЕРШЕНИЕ Оглядываясь на наш опыт общение с клиентами в последнее время хочется сказать, что многие производители продуктов питания задумываются об организации прослеживаемости на своих предприятиях, но не знают с чего начать и как обеспечить эту прослеживаемость. Для всех наших последних проектов внедрения MES-систем на производствах организация прослеживаемости – это обязательная составляющая. Так что, если вдруг возникнут вопросы – вы знаете к кому обращаться ;-).
  12. Добрый день! Сроки и стоимость проекта внедрения MES напрямую зависят от степени вовлеченности в проект самого Заказчика, предъявляемых требований к системе, текущей инфраструктурной ситуации на предприятии. Не проработав данные вопросы, нельзя однозначно сказать, что больше в материальном плане будет стоить предприятию. Нужен визит на предприятие. Однако, если вас интересуют ориентировочные сроки, то обычно наши проекты внедрения MES длились 0,5 – 1 год. Если у вас возникли дополнительные вопросы, то лучше связаться лично. Наши контакты есть в описании блога.
  13. Многие из вас, уверен, хотя бы раз в своей профессиональной карьере участвовали в проекте внедрения новой информационной-учетной системы. И, уверен, эти воспоминания почти для каждого вызывают неприятный холодок, легкую дрожь или внутреннее съеживание. Словом, воспоминания не из приятных. Я искренне завидую тем счастливцам, кто запускал систему в эксплуатацию спокойно, ровно, без ненормированного рабочего дня, авралов-пожаров, употребления разнокалиберных нервовыпрямляющих препаратов. Вы – счастливчики по обстоятельствам или по призванию, вы – белые вороны в рядах внедренцев изменений, вы – люди «стальные яйца нервы». Но, скорее всего, вы – вымышленный и несуществующий в реальности персонаж Теперь шутки в сторону и перехожу к сути. Сегодня хочу поделиться с вами советами из своего опыта внедрения автоматизированных систем (10+ лет подобных «приключений»), который поможет вам и окружающим вас людям не только пережить этот переходный период, но и осмыслено приложить свои усилия для гладкого перехода в светлое будущее под названием «промышленная эксплуатация новой информационной системы». 0. ФОРМИРУЙТЕ АДЕКВАТНЫЕ ОЖИДАНИЯ К ПРОЦЕССУ ЗАПУСКА СИСТЕМЫ В ЭКСПЛУАТАЦИЮ Нужно понимать, что внедрение информационной системы – это серьезные изменения: в деятельности компании, в работе людей, в подходах и способах выполнения производственных задач. А любое изменение – это преодоление, порой с элементами стресса. И это не только для вас – надо учитывать общее количество сотрудников-пользователей системы, у которых меняется привычный способ работы. Поэтому нужно сразу настроиться – легко запуск в эксплуатацию происходить не будет. Почти наверняка будет трудно (особенно на первых порах). Однако после отладки системы, завершения переходных процессов, выработки привычки к новым подходам, работа станет не только легче, но и результативней и эффективней. Это должно вас подпитывать силами в нелегком переходном процессе. 1. ПОДГОТОВЬТЕ ПЛАН ЗАПУСКА Подготовка плана запуска – непростая задача, особенно когда речь идет о запуске крупной функциональной задачи в системе с большим количеством запускаемых операций и/или пользователей. Но раз Вы подошли к этапу запуска – в вашей команде неизбежно должны быть люди, которые способны определить – ЧТО должно быть запущено (состав операций, функций, задач) и КАК должен проходить запуск (из каких этапов/вех). Хорошим примером ответа на вопрос ЧТО? является модель описания информационной системы, приведенная в одной из наших предыдущих публикаций. Если к моменту запуска системы в эксплуатацию такое описание внедряемой системы будет у вас в наличии, то оно (описание) отлично поможет оценить полноту состава запускаемых операций. Кроме ревизии состава запускаемых операций в плане запуска нужно предусмотреть – в какой последовательности будут запускаться функции и операции, а также – какие необходимо выполнить подготовительные работы для начала работы пользователей: завести пользователей и назначить им права, внести начальные остатки и т.д. 2. ПОДГОТОВЬТЕ ИНСТРУМЕНТЫ УПРАВЛЕНИЯ ЗАПУСКОМ Основными инструментами управления запуском являются: Чек-лист операций конкретного пользователя. Чек-лист позволяет проконтролировать как возможность выполнения пользователем операций (может или нет), так и полноту (все операции выполняются или не все). Журнал учета инцидентов. Журнал – это место регистрации, хранения и ведения списка вопросов и их решений. У пользователей в ходе запуска могут возникать вопросы и проблемы разного калибра. И нужно обязательно иметь инструмент ведения списка задач, требующих отложенного решения. 3. РАСПРЕДЕЛИТЕ ОТВЕТСТВЕННОСТЬ ЗА ПЕРВИЧНУЮ КОНСУЛЬТАЦИОННУЮ ПОМОЩЬ ПОЛЬЗОВАТЕЛЯМ И ЗА РЕШЕНИЕ СЛОЖНЫХ ВОПРОСОВ В большинстве наших проектов мы делим команду внедрения на два эшелона: Первая линия поддержки – это специалисты к которым непосредственно обращаются конечные пользователи со своими вопросами по работе с системой. Крайне важно, чтобы: количество таких специалистов на поддержке было достаточно для оперативной реакции на вопросы пользователей. Особенно на первых 2-3 интенсивных неделях запуска каждый пользователь знал к кому обратиться со своим конкретным вопросом Вторая линия поддержки – это интеллектуальный штаб для решения сложных вопросов или инцидентов пользователей, которые не могут быть оперативно отработаны в режиме «вопрос-ответ». 4. ПРОГОВОРИТЕ ПЛАН ДЕЙСТВИЙ И ЗОНЫ ОТВЕТСТВЕННОСТИ СО ВСЕМИ УЧАСТНИКАМИ ПРОЦЕССА Этот совет (как и первый) связан с психологической подготовкой проекта. В основе страха (порой подсознательного) для большинства людей лежит не масштаб предстоящих изменений, а неопределенность, которая в них скрыта. Например, проводились исследования, показывающие, что студентов меньше беспокоит грядущая сессия, если у них составлен план подготовки к ней. Поэтому, когда вы проделали предыдущие подготовительные задачи, обязательно соберите всех участников запуска (самое главное – пользователей) и объясните максимально подробно – КАК будет происходить запуск, КТО и ЗА ЧТО отвечает, К КОМУ обращаться при возникновении вопросов. ВМЕСТО ЗАВЕРШЕНИЯ Хороший вопрос – когда заканчивается запуск? «Когда все станет хорошо» — частый и вполне ожидаемый ответ пользователей/заказчика. Но поскольку мы говорим про управляемый, а значит измеримый результат, то надо отвечать на этот вопрос конкретней. В своих проектах границей окончания запуска мы считаем следующие критерии: Каждая из запланированных к запуску операций выполняется (или может быть выполнена) в системе в соответствии с определенной для нее периодичностью Устранены инциденты, не позволяющие операции выполняться в рабочем режиме Это далеко не полный перечень того, что помогает снизить болезненность процесса запуска системы в эксплуатацию. Однако, если вы возьмете в привычку и практику хотя бы перечисленные выше советы, то разницу относительно предыдущего опыта запуска вы точно сможете почувствовать. Интересных вам проектов внедрения и управляемых запусков!
  14. О ЧЕМ РЕЧЬ Сегодняшний материал будет интересен представителям финансовых подразделений и представителям производства. Впрочем, отговаривать от чтения всех остальных точно не буду. Поговорим о том – как корректно выстроить связку систем финансового и оперативного учета на производстве продуктов питания. Начнем с того, что автоматизированные системы финансового учета (как минимум бухгалтерского) есть почти на всех предприятиях. А в последнее время конкуренция на рыке производителей продуктов питания заставляет активно заниматься внедрением автоматизированных систем оперативного учета для получения более широкого спектра данных и принятия оперативных управленческих решений. И вот тут возникает вопрос – каким образом организовать и автоматизировать контур оперативного учета? Вести все в одной базе и расширять финансовый контур до детальности оперативного? Разделить их так, чтобы оперативные данные велись в одном контуре, а в финансовый только транслировались необходимые аналитики? Вести их в одной базе или в разных? Сегодня мы поделимся своим опытом и подходами к решению этой задачи. ПРИЧИНЫ РАЗДЕЛЕНИЯ СИСТЕМ Мы на практике решали задачу и путем расширения финансового учета до требований детального учета на производство в единой информационной системе, и выполняли проекты, где контуры оперативного и финансового учета были реализованы в отдельных базах. Дело в том, что финансовый и оперативный учет ведутся для разных целей и обладают принципиально разными свойствами, хотя и основываются на одних исходных данных. В свете этого важно решить один из ключевых вопросов – вопрос границы оперативного и финансового учета и момента перехода данных из одной системы в другую. В итоге мы остановились на том, что наиболее экологичное решение – разделять контуры оперативного и финансового учета (и лучше их делать в разных базах). 3 основные причины почему нам видится разделение данных задач на разные подсистемы: Финансовый учет ведется, как правило на основании бухгалтерских документов и с задержкой на 5-20 дней. В то время как для принятия оперативных решений часто надо обладать информацией практически в режиме реального времени. Системы оперативного учета подстроены под производственные процессы предприятия и изменяются существенно реже нашего «шального» законодательства, поэтому и останавливать систему MES-учета для получения очередного обновления регламентированной отчетности – задача, не несущая никакого профицита для бизнеса. Режим работы MES-систем должен быть организован 24/7, и, соответственно, нельзя останавливаться, когда идут долгие регламентные процедуры (например, по расчету себестоимости) так необходимые для финансовых служб предприятия. Реализация проектов, где финансовый контур детализировался до оперативного приводил к тому, что финансовый учет существенно усложнялся. Наш опыт реализации проектов оперативного учета привел нас к следующим правилам интеграции подсистем финансового и оперативного учета: Необходимо сворачивать аналитики учета до требуемых для экономического анализа // Каждому объекту финансовой подсистемы должно быть поставлено в соответствие несколько объектов оперативной подсистемы. Эта связь должна быть использована в дальнейшем при автоматическом формировании документов финансового учета на основании оперативных документов. Упрощайте схемы движения материальных потоков для формирования себестоимости // Для финансового учета не нужно учитывать все возможные места возникновения затрат и рабочие центры, достаточно взять минимальный объем для получения целевой схемы учета затрат. // Например, когда с точки зрения оперативного учета подразделения детализированы с точностью до производственных участков и цеховой кладовой при них, а в финансовой подсистеме все эти подразделения являются единым подразделением. В этом случае перемещения ТМЦ между участками, а также между участками и цеховой кладовой не попадут в финансовый учет. В финансовом учете будут отражены только агрегированные данные о приходе ТМЦ на подотчет цеху и об отпуске ТМЦ из цеховой кладовой . Определяйте единые точки ввода для справочной информации // Для каждого справочника (подразделения, продукция, номенклатурные группы и т.д.) надо определить систему, в которой элементы справочника будут первично рождаться. Это позволит избежать захламления справочников «дублями». Откажитесь от счетов учета и прочих «бухгалтерских штучек» в системе оперативного учета // Непонятные для оперативных работников реквизиты документов могут вводить их в ступор и тормозить скорость работы людей в системе. Такие вещи должны настраиваться для автоматического обмена в рамках интеграции подсистем. При этом надо сохранять возможность ручной корректировки в системе финансового учета (например, счетов учета и статей затрат). Увеличивайте периоды обмена подсистем, но не забывайте про минимальную потребность обеспечения финансового учета первичными данными. // Такой подход позволит уменьшить нагрузку на систему оперативного учета и увеличить ее производительность. Таким образом, труд финансово-экономических служб существенно упростится, если использовать механизм автоматического формирования финансовых данных на основании оперативных. При таком взаимодействии все технические и экономические службы предприятия получают достоверные и структурированные данные обо всех производственных процессах в режиме реального времени в виде сформированных сводных отчетов в виде таблиц и графических образов. Еще один момент, на который надо обратить внимание – на каком месте в общей информационной системе предприятия данные должны перетекать из одной системы в другую. Любой документ, отражающий оперативную деятельность в системе – это факт передачи ответственности (в т.ч. материальной). Поэтому важно понять – в каком месте будет происходить фиксация факта передачи этой ответственности. Рассмотрим это на примере операции выпуска готовой продукции на склад. Причем сразу оговоримся, что данная операция подразумевает под собой 2 факта: Отражение выпускающим/передающим подразделением факта выпуска/передачи. Подтверждение принимающим подразделением факта его получения в полном объеме. Варианты реализации этих операций следующие: Данные операции можно отражать в системе оперативном учете целиком и затем транслировать в систему финансового учета. В данном случае мы имеем проблему в работе приемщика в 2-х системах, так как факт отгрузки будет фиксироваться уже в системе финансового учета. Можно отражать первую операцию в системе оперативного учета, а подтверждение факта приемки в системе финансового учета. В данном случае придется поддерживать двухстороннюю интеграцию, либо формирование каких-то сводных отчетов из 2-х систем для того чтобы удостовериться в единообразии данных. С точки зрения упрощения работы пользователей второй вариант более удобен, но он требует более грамотного технического подхода и более трудоемок в реализации. Если у вас есть возможность, то лучше склонятся именно к нему. ПЛЮСЫ И МИНУСЫ РАЗДЕЛЕНИЯ КОНТУРОВ УЧЕТА Плюсы a. Уменьшение ручной обработки данных службами финансового учета, т.к. документы уже в том или ином виде приходят к ним в рамках учетной системы. b. Возможность передать в систему финансового учета с любой степенью детализации (не меньшей чем в оперативном учете). И, соответственно, с такой же степенью детализации возможно посчитать себестоимость готовой продукции. c. При желании можно получать оперативные финансовые показатели, основанные на оперативной деятельности (например, ежедневная себестоимость партий готовой продукции). d. Теоретически, жизнь оперативного и финансового учета в одной системе возможна, но вам придется мириться со всем проблемами, обозначенными выше: регулярные обновления информационной системы, недоступность в связи с выполнением регламентных процедур, и дополнительно ваш финансовый учет будет вестись с той же степенью детализации что и оперативный. Оно вам надо? 2. Минусы a. Любая интеграция (в данном случае подсистем учета) требует затрат на реализацию и поддержку корректной работы. b. Кроме самой интеграции надо задуматься об инструментах, которые подтверждают правильность ее работы (напр. разработать стыковочные отчеты). c. Если есть потребность в корректировке данных, то надо делать их в месте первичного возникновения (при повторном обмене информацией скорректированные не в том месте данные могут затереться и породить хаос). В завершение Это наш подход к решению задачи интеграции оперативной системы и системы финансового учета, который показывает свою работоспособность у клиентов. Главное на что хочется обратить внимание в конце, что если вы планируете развивать детальность своей системы учета от финансовой до оперативной, то система оперативного учета – это не расширенная система финансового учета. Это отдельная система для данных, которую лучше реализовывать на разных контурах и в разных базах.
  15. «Экспертам от экспертов» Ни для кого уже не секрет, что современный рынок производителей продуктов питания отличается высокой конкуренцией. Кроме этого, федеральные сети держат производителей практически в кабальных условиях — чтобы войти в сеть и продолжать сотрудничать с ней, необходимо выполнить целый ряд требований, которые постоянно дополняются. В связи с этим становится во весь рост вопрос снижения себестоимости готовой продукции для повышения конкурентоспособности предприятия. И, если посмотреть на возможные варианты снижения этой самой себестоимости, то их не так-то и много. К нашему огорчению производители чаще всего выбирают короткий путь и снижают себестоимость за счёт рецептурных изменений (удешевляют ингредиенты, используют заменители). Такой путь неизбежно приводит к снижению качества продукта и к потере имиджа в глазах покупателей. А вот восстановить репутацию после этого крайне сложно. Если покупатель один раз разочаровался в продукте и отвернулся от производителя, то нужно приложить неимоверные усилия, что обратно завоевать его доверие. И получается, что такой прямой рецептурный способ снижения себестоимости быстр и лёгок, но влечёт за собой «побочные эффекты» в виде снижения качества продукции и, как следствие, потери рыночных позиций. А есть ли какой-то альтернативный способ? Конечно есть, и о нём мы сегодня и поговорим. Это более сложный, более длинный, но в долгосрочной перспективе более правильный способ. Это способ снижения себестоимости за счёт контроля производства и сокращения потерь по производственному процессу. ПРОЦЕССНЫЙ ПОДХОД СНИЖЕНИЯ СЕБЕСТОИМОСТИ Начнём с того, что же это такое — процессный подход? Он заключается в том, что мы осуществляем контроль технологических операций с точки зрения потери выходов продукции. То есть наша задача – выстроить контроль выходов продукции по технологии производства, который позволит обнаружить и «подкрутить» те места, где происходит сверхнормативная потеря, расход или выбраковка продукции. У производителей продуктов питания мы выделяем следующие потери: Технологические – потери, которые возникают в процессе производства. Это, например, операции, в которых происходит потеря веса продукции: дефростация, заморозка, термообработка, охлаждение, остывочные камеры, посол, сушка и т.д. В том числе готовая неупакованная продукция, которая ждёт упаковки. Брак и порча, которые возникают либо по технологическим причинам, либо по халатности сотрудников производства. И это тоже в общем-то те резервы, которые мы можем использовать. Такие потери в любом производстве неизбежны, но за счёт выяснения их причин и управления этими потерями, мы получаем понимание – каким образом можно снизить их количество. Непроизводственные – это потери, которые непосредственно не связаны с процессом производства: следствие недостатков в технологии и организации производства. Например, простои продукции, штрафы, воровство. КАК ОРГАНИЗОВАТЬ ПРОЦЕССНЫЙ ПОДХОД СНИЖЕНИЯ СЕБЕСТОИМОСТИ? Первый шаг — определить операции по технологии производства, на которых возникают потери (термообработка, охлаждение, дефростация, заморозка, сушка, посол, хранение готовой неупакованной продукции и т.д.). Второй шаг после выделения операций – это организация на них оперативного учёта таких основных параметров как: время выполнения операции Операции, описанные выше, всегда критичны ко времени выполнения. И, к примеру, если мы передержали продукт в дефростере, то мы его не только разморозили, но ещё и подсушили. А может даже и подзапекли )) То есть у продукции явно произошла сверхнормативная потеря полезного естественного веса сырья и, само собой, порча. объём входа и выхода продукции На входе-выходе по производственным операциям необходимо контролировать – какое количество продукции зашло, какое вышло. Это даёт точный расчёт процента потерь. А когда мы можем видеть этот процент, то можем и управлять им. Также можем определить – соответствует этот процент нормативному или не соответствует. объём брака Объём брака необходимо отслеживать как в законченном цикле производства, так и отдельно по каждой операции. Передержали мы, например, продукт на какой-то операции, или вдруг оборудование дало сбой, или рабочий опрокинул тару с сырьём. Вот и возник брак, который мы сразу должны зафиксировать. объём расхода вспомогательных, упаковочных материалов Необходимо обеспечить учёт и контроль используемых дополнительных, вспомогательных, упаковочных материалов. Это также влияет на себестоимость продукции и качеством этого учёта не стоит пренебрегать. Конечно существуют дополнительные параметры, которые тоже неплохо было бы учитывать, но вопрос их учёта состоит уже привязан к наличию соответствующих инструментов учета. Вести его возможно только с помощью автоматизации, а вручную — довольно сложно, трудоёмко и неточно. Такими дополнительными параметрами могут быть: партионный учёт У каждой продукции есть условия и сроки хранения. При их нарушении будут возникать порча и потери. Но вопрос не только в различном физическом хранении партий, но и различии в документальном оформлении и ведении учёта этих партий. Но и это ещё не всё. Для полного партийного учёта требуется и соответствующая физическая идентификация партии, обычно осуществляемая соответствующей маркировкой товара (напр., нанесение штрих-кода) или его упаковкой. учёт выполнения операций по единицам оборудования Так, например, операция термообработки выполняется с большим количеством термокамер. У каждой термокамеры есть свои параметры, от которых может зависеть выход продукции. И необходимо вести учёт не в целом по камере, а по конкретной печке, которая в ней находится. Третий шаг — это контроль межоперационных остатков. А именно – контроль времени нахождения этих остатков между операциями и объёмы этих остатков для того, чтобы исключить внезапную пропажу этого продукта. То есть мы должны знать – если у нас вышло с этой операции такое количество продукции, то на следующую операцию должно зайти столько же. Возможно, с небольшим отклонением, предусмотренным нормами. Это обеспечит контроль непроизводственных потерь, в том числе и воровства. Уверен, что на каждом пищевом производстве, в том или ином виде, эта информация в производстве учитывается. Но стоит честно задать себе вопрос – устраивает ли вас этот способ учёта? Можете ли вы свободно получить нужную информацию? А на сколько она точна и достоверна? Можно ли её проанализировать и на основании её принимать какие-то решения? Если вы честно ответите на эти вопросы, то согласитесь, что качество учёта на вашем производстве недостаточно высоко. Обычно, когда мы проводим обследования на пищевых предприятиях, то выясняем, что учёт на производстве ведётся либо в бумажном журнале, либо в Excel. Но информация такими способами учитывается не вся и не всегда. А уж когда данные с производства запрашивают для руководства, то на основании этой неполной информации сотрудники «рисуют» отчёты, которые в конечном счете и получает руководство. То есть, это уже своего рода псевдоучёт, а не настоящий учёт. Мы подводим к тому, что организация корректного учёта на производстве обеспечивает прозрачность и достоверность данных, на основании которых мы можем принимать взвешенные управленческие решения. А такие решения и приведут к снижению себестоимости продукции. ПОЧЕМУ ОРГАНИЗАЦИЯ УЧЁТА НА ПРОИЗВОДСТВЕ ВЕДЁТ К СНИЖЕНИЮ СЕБЕСТОИМОСТИ? Во-первых, как мы уже упоминали выше, такая организация даёт оперативную достоверную информацию и понимание о том – на каких именно операциях, на каких именно участках происходят сверхнормативные потери(дополнительный расход сырья, вспомогательных материалов и т.д.), то есть те дополнительные издержки, которые несутся сверх нормы и закладываются в себестоимость. Когда мы понимаем причины возникновения сверхнормативных потерь, мы можем точечно применить определённые усилия. Например, данные показали, что на конкретном оборудовании показатели выхода продукции скачут то в одну, то в другую сторону. При анализе мы выяснили, что происходит сбой в работе оборудования и теперь мы можем принять решение – отремонтировать это оборудование, или в худшем случае — заменить его. Если же причина в качестве работы сотрудников, то для исправления ситуации можно применить управленческие «пряники-кнуты» для рабочих, руками которых организуется этот процесс. Во-вторых, такой учёт оказывает «общеуправленческий эффект». Имеется в виду, что когда мы начинаем наблюдать за операциями, контролировать их, мы неизбежно повышаем дисциплину самого процесса производства. Сам факт контроля уже улучшает показатели процесса. При этом высшим пилотажем считаем решение, когда, в дополнение к этому учёту, стоится система, которая сама обеспечивает нужные технологические параметры. То есть контроль технологии производственной нормы, заложенный в систему, не даёт возможности отклониться от выполнения этих нормативов. Примерами такой системы могут быть инструменты рецептурного контроля. Это автоматизированный инструмент, который помогает сотруднику определить – какой объём сырья может быть использован; сразу его контролирует и, если вдруг возникают отклонения, не даёт завершить операцию. Таким образом, система сама обеспечивает определённый рецептурный контроль за объёмом сырья в рамках нормативов, которые допускаются. Другой пример автоматизированного инструмента, который позволяет обеспечить технологию – это мониторинг операций, которые привязаны ко времени: сушка, дефростация и т.д. Система может показывать время, конец операций и реагировать при каких-либо отклонениях от нормы. ВМЕСТО ЗАКЛЮЧЕНИЯ Такой процессный подход для снижения издержек и потерь в производстве как средство снижения себестоимости является не самым простым, но в долгосрочной перспективе более правильным и более выигрышным. При его использовании мы получаем не только возможность снизить себестоимость, но и получаем дополнительный букет выгод: Сохраняем и даже где-то увеличиваем качество продукции. Звучит это немного парадоксально — снизили себестоимость, а качество повысили. Но по факту это так. За счёт того, что мы получили порядок на производстве и контроль над технологией, в том числе оказываем воздействие и на качество продукции. Повышаем порядок и дисциплину исполнения работ на производстве. Повторимся – когда мы контролируем что-то, то мы неизбежно повышаем дисциплину этого учёта. Получаем основу для организации прослеживаемости движения партий и продукции в производстве, которая является сейчас очень актуальной задачей и для менеджмента компании, и для представителей торговых сетей, и для государства (ГИС «Меркурий» явно намекает на желание видеть партионный учет у мясопереработчиков и молочников). Впрочем, тема прослеживаемости производства — это тема уже отдельного ликбеза.
×

Important Information

Обновлены следующие документы: Terms of Use Privacy Policy