Поиск в системе

Сегодня расскажем о проекте по внедрению системы автоматизированного прогнозирования отгрузок и формирования заявок на производство на платформе «1С» на заводе по производству сыра и цельномолочных продуктов. Что породило необходимость перемен? Основной предпосылкой к переменам стал переезд распределительного центра на другую территорию (ранее производство и склад находились бок-о-бок друг с другом). Это привело к тому, что сотрудники производства не могли оперативно отслеживать остатки на складах для обеспечения заказов клиентов и, соответственно, клиентский сервис стал снижаться за счет отсутствия необходимой продукции. Раньше склад быстро пополнялся за счет моментального реагирования производства. Теперь стали учащаться ситуации, когда заказ сделан, машина приехала, а продукции на складе нет. Появилась необходимость в системном планировании производства. Как пытались решить самостоятельно? Первым (и самым разумным из всех возможных в текущей ситуации) шагом к спасению самих себя со стороны клиента стало создание рабочей модели планирования в Excel. Это явилось отличным подспорьем для формирования внятного ТЗ для дальнейшего внедрения автоматизированного инструмента планирования. Впрочем, об этом чуть позже. НО! сбор и анализ данных в Excel были неудобными и занимали много времени. Большая география клиентов, разные каналы сбыта, разные периоды отгрузки серьезно осложняли задачу планирования в Excel. (7 000 клиентов, среди которых около 3 500 являются регулярными клиентами + уникальные пользователи интернет-магазина образовывали порядка 14 000 уникальных клиентов, требующих анализа). Метод проб и ошибок помог прийти к выводу, что для обработки информации такой сложности и объема Excel не стабилен и применим только на этапе апробации разработанных моделей. Поставленные задачи Повысить степень исполнения заказов клиентов и снизить списания по остаточным срокам годности за счет: Синхронизации работы цепочки подразделений «производство – склад – продажи» Снятия зависимости точности формирования заявки на производство от конкретных сотрудников Было принято решение сделать это с помощью внедрения автоматизированного инструмента планирования на «1С» взамен существующего файла Excel. В качестве платформы для автоматизации выбрали готовое отраслевое решение – модуль «K2FRESH» (https://k2fresh.com/pp) Пошаговый путь к цели Шаг 1. Утвердили модель планирования на какие группы разбивать клиентов? какие сценарии планирования использовать? какую информацию необходимо заносить в систему? какие отчеты система должна выдавать (в зависимости от решений, которые необходимо принять на основании этих отчетов)? Шаг 2. Доработали типовой функционал инструмента (модуль формирования заявки на производство продукта «K2FRESH») под потребности клиента. Шаг 3. Внедрили модуль на предприятии клиента и обучили конечных пользователей работе с инструментом. // Примечание: чтобы мы смогли построить точную модель, специалистам по финансам сырзавода пришлось еще больше углубиться в исследования своей клиентской базы. Клиентов поделили на тех, кто делает заказы регулярно и тех, чьи заказы не поддаются закономерности. И сделали вывод, что первых можно планировать с применением различных статистических методов, в зависимости от характера спроса. А со вторыми должен дополнительно поработать отдел продаж, чтобы вносить их в план производства заранее. Эффекты от внедрения системы 1. Синхронизировалась работа цепочки подразделений «производство – склад – продажи» Система выдает два отдельных задания: на выработку конкретного вида продукции на упаковку и маркировку И сразу становится понятно – что производить и в каких объемах, во что и когда фасовать, какую этикетку наносить на готовую продукцию. Особенно автоматизированная система помогает в ситуации, когда запускается резервуарный объем производства (например, 400 литров ряженки). Невозможно 200 литров расфасовать, а 200 — оставить. Именно поэтому в задании на производство учитываются не просто заказы, а еще и технологические особенности производства. Будет ли покрыт заказ при запуске такой партии? Чем покрывать недостатки? Куда девать излишки? Система позволяет принимать решение в момент планирования, а не по факту образовавшейся нехватки на складе готовой продукции или появлении избытков полуфабрикатов. 2. Повысилась точность планирования отгрузок за счет детализации характеристик клиентов и применения к каждой группе клиентов заранее настроенных автоматизированных правил. 3. Снизилось влияние человеческого фактора на уровень точности заявки на производство Данные о заказах и отгрузках стали собираться более надежно за счет того, что вся информация о привязке клиентов к регионам появилась в одной базе. При внесении изменений заданный алгоритм сам синхронизирует данные, и информация не теряется. Потребность в бдительности сотрудника отпала сама собой. Этот эффект проявил себя еще на этапе тестового запуска, когда система автоматически нашла несколько заказов, которые потерял человек. Интересный момент. В полном объеме функционала система на предприятии заработала летом (в сезон отпусков). На тот момент функцию планирования осуществляли 3 человека. И несмотря на опасения, продиктованные прошлым опытом работы в Excel, 2 из них смогли спокойно уйти в отпуск одновременно, и 1 оставшийся отлично справлялся с планированием. Что раньше считалось чем-то из области научной фантастики. Одним словом, бездушный программный алгоритм оказался гораздо эффективнее живого человека и смог помочь добиться нужного уровня клиентского сервиса. Немного цифр Увы. Из-за подписанных соглашений о конфиденциальности мы не можем осветить реальные конечные цифры уровня клиентского сервиса и списания по остаточным срокам годности (( При этом можем обозначить уровень соответствия заявки на производство спросу. С внедрением автоматизированного модуля планирования «K2FRESH» он составил 98,5%. Сложности в процессе внедрения Основной сложностью в ходе проекта стала необходимость сотрудников-планировщиков перестраиваться с одного инструмента на другой. В Excel можно было поменять все данные вручную, а в автоматизированной системе – нет. Впрочем, это небольшое неудобство быстро перестало быть неудобством. Вывод Excel – вполне рабочий инструмент планирования. Но если вы собираетесь расти в продажах, то ошибки, связанные с человеческим фактором в планировании заданий на производство, могут сильно вам помешать обеспечить поступившие заказы клиента. Задумайтесь об автоматизации. Удобно, когда уже есть готовое программно-методическое решение (https://k2fresh.com/pp), которое можно взять и настроить под себя, и нет необходимости «придумывать велосипед». С чистого листа такой проект оказался бы намного продолжительней и финансово более затратным. Автоматизация процессов планирования задания на производство — это уже не «ноухау». Скорее это современный и адекватный способ обеспечить поддержание высокого уровня клиентского сервиса при одновременном снижении количества списаний готовой продукции из-за превышения остаточных сроков годности.

Зачастую, принимая решение об автоматизации интеграции с ГИС Меркурий и воплощая эту самую интеграцию в жизнь, задача рассматривается как буквальная — обеспечение фактической способности передачи данных об отгружаемом товаре. Просто и безапеляционно. Нужно передавать данные, так мы и передаем. Но стоит задуматься о том, насколько успешен такой подход, и почему послевкусие от таких внедрений оставляет желать лучшего? Делимся: По опыту многих внедрений становится понятно, что по настоящему приносить пользу может только комплексное решение по автоматизации ряда процессов, предшествующих самой передаче данных в Меркурий. Решение, которое делает проще работу не только (и не столько) по передаче информации, но по её аккумуляции. А структуру передаваемой информации более обширной и полезной для конечного клиента, получающего отправленное нами ЭВСД. Конкретнее: Так почему же нельзя автоматизировать исключительно интеграцию с ГИС Меркурий, не автоматизируя прилегающие процессы? (Ответим, рассмотрев каждый процесс с точки зрения его влияния на участие в формировании требуемой информации). О каких процессах идёт речь? Автоматизация процессов маркировки групповой упаковки и логистических мест Автоматизация фиксации выпуска на этапе маркировки Автоматизация списания сырья в производственной партии Автоматизация складских процессов, в частности, наборка продукции в разрезе партий Автоматизация элементов функций транспортной логистики Как их автоматизация влияет на аккумуляцию данных в системе (в разрезе необходимых аналитик для передачи в ГИС Меркурий)? Хочется рассматривать эти процессы совместно и в рассмотрении идти с конца цепочки. Данные в Меркурий должны быть переданы в разрезе партий продукции (а в некоторых случаях и в разрезе логистических мест и упаковок). Залогом того, что в Меркурий будут переданы данные ровно о той продукции, которая фактически отгружена со склада, может быть только автоматизированный учёт наборки. Чаще всего, используется считывание штрих кода с упаковки продукции или логистической единицы. Во всех остальных случаях — ручной ввод. А ручной ввод — это надежда на острый глаз и трезвый ум вводящего, что, вероятно, не надёжно. Собственно для того, чтобы штрихкод был считан, он конечно же должен быть нанесён. И не абы-какой, а позволяющий проидентифицировать не только сам товар, но и его партию и дату производства. С учётом регулярно меняющихся требований по составу этого штрихкода, управляемость возможностью редактирования этикетки становится насущной необходимостью. Применение типографской этикетки становится неприемлемым. Прежде чем на продукцию будет выписано исходящее ЭВСД, она конечно же должна быть произведена. Гарантией попадания достоверной информации о выпуске в Меркурий может служить своевременная фиксация в учётной системе факта выпуска готовой промаркированной продукции. Тогда мы гарантированно сможем передать информацию для формирования соответствующей производственной партии в Меркурий. И да, стоит отметить, что выпускать продукцию в Меркурии “из ничего” уже не модно. И не модно и неудобно! Гораздо удобнее задать спецификацию с пропорциями потребляемого сырья на конкретный вид продукции и наслаждаться его автоматическим распределением в производственной партии. Вот и получается, что управляемо отмаркированная, вовремя выпущенная и правильно проидентифицированная на этапе наборки продукция существенно упрощает получение информации, в структуре удобоваримой для передачи в ГИС Меркурий. Делаем выводы: Результат адекватной работы автоматизированных процессов, о которых мы ведем речь выше — стройно собирающаяся в системе информация, в том виде, в котором её можно легко потреблять. В этом случае её передача в ГИС меркурий становится делом техники. Если вы то же почувствовали в себе потребность сделать систему не только удовлетворяющую внешним требованиям, но и удобную в использовании и вам требуется помощь…. Обращайтесь. Мы так умеем)

Сегодня поговорим о выборе информационной системы. Тема порой пугающая. Но для любого предприятия рано или поздно она становится актуальной. Как правило, проблемы бух. учета не возникает, так как требования к его ведению условно схожи для предприятий с разной структурой организации. Однако, когда речь заходит о производственном и оперативном учете, неизбежно возникает проблема выбора. Все компании сталкиваются с одними и теми же проблемами — ведение учета, прозрачность техпроцессов, контроль прибыли и затрат. И до определенного уровня развития организации обходятся условно недорогими организационными или методическими способами учета. Но с ростом объемов переработки и выпуска, а также меняющихся требований законодательства проблема автоматизации учета становится острее. И это отражается сразу на всех сферах деятельности предприятия: производство, продажи, маркетинг, логистика, склад, и еще целый комплекс направлений. Разумеется, для решения вопросов автоматизации на Российском рынке есть ряд предложений. Но мы будем рассматривать только решения, разработанные на платформе 1С:Предприятие, т.к., на наш взгляд, этот рынок наиболее развивающийся и гибкий относительно отечественных аналогов менее рискованный относительно западных решений А если быть точным, то это единственный действительно удобный механизм, что подтверждено массовостью его использования и популярностью среди потребителей. Итак, рассмотрим Варианты ИС для автоматизации оперативного и производственного учета Типовое решение 1С На первый взгляд, это самый простой способ. И обратившись в любую рядовую франчайзи 1С, первым, что вам предложат, будет типовая система для решения учетных задач. Среди них хорошо отработанные и обновляемые решения бухгалтерского учета и зарплаты. Но когда речь заходит об учете производственных процессов, проект становится дорогим и неэффективным. Разработчики типовых решений стремятся сделать свой продукт универсальным. Но производство на тракторном заводе и сыродельном комбинате настолько разное, что невозможно гармонично совместить все нюансы их работы в одном продукте. Система получается, с одной стороны, перегружена излишними настройками и неудобствами, а с другой, лишена необходимого учета процессов, обусловленных спецификой производства. Получается бесконечно дорабатываемая система, которая не просто не удобна пользователям, но и не выполняет требуемые функции. Из-за объема доработок, проект по внедрению универсальной системы проходит достаточно долго, а также обязывает на дорогостоящее сервисное обслуживание, без которого система не сможет работать автономно. Только вдумайтесь: иногда стоимость сервисного обслуживания в год может оказаться равной полной стартовой стоимости проекта. На нашем опыте реализация данного сценария выглядела следующим образом: К нам поступила заявка от клиента (Маслосырзавода). Запросом была доработка типовой ERP. «Она же универсальная! В чем же сложность?» И мы стали дорабатывать. Скажем проще: убирать лишнее и добавлять недостающее. Что нам пригодилось из типового: Справочники (контрагенты, номенклатура и т.д.) Первичные документы (заказы клиентов, реализация товаров и услуг) Механизм приема заказов, установок цен и взаиморасчетов Что разработали сами: Система складской логистики (документы внутренних движений, регистры) Блок транспортной логистики Системы комплектации товаров Системы мониторинга комплектации и хранения остатков Интеграция с базами бухгалтерского учета Итог: От системы, взятой за основу, (чтобы упростить работу), осталась незначительная часть. И даже ее пришлось дорабатывать, чтобы пользователям было удобно. Конечно, мы сдали полностью готовую и функционально законченную систему. Клиент успешно работает в ней и по сей день. Но из-за большого количества доработок сроки и трудоемкость проекта почти в 3 раза превысили ожидаемые. Отраслевые решения На рынке есть IT компании, которые успели накопить опыт доработки типовых продуктов для определенных направлений производственных предприятий и залицензировать свои решения. Такие решения называют отраслевыми. Как правило, они закрывают минимальные потребности учета. А именно, те шаблонные функции, без которых работа молокозавода/ маслосырзавода/ мясокомбината не возможна в принципе. Поэтому решившему все-таки втиснуться в отраслевой продукт (которое построено на основе типового решения), в любом случае придется мириться с неудобствами и сложной логикой работы. То есть, подстраивать себя под систему. А хочется, чтобы, наоборот, система была адаптирована и лояльна к потребностям предприятия и конечного пользователя. Отраслевое решение закрывает учетные задачи с особенностями отраслевой специфики , но: функции управления, например планирования, остаются от универсального решения и как следствие слабо применимы приходится использовать неоправданно усложнённую систему, что сильно влияет на трудоёмкость проекта внедрения, и что не менее важно, на трудоёмкость сопровождения системы. Сделаем вывод, что работать с отраслевыми решениями можно. Но на входе в проект надо понимать, что эта система не является 100% подходящей и требует существенного объема доработок. Однако очевидно меньшего, чем при внедрении типового решения. К тому же, стоимость лицензий, как правило выше, чем для типовых, и обновления выходят редко. Поэтому тем, кто надеется на скорость и простоту внедрения данного продукта, советуем хорошенько подумать еще раз. Узкопрофильное решение Итак, когда мы пытались подстраивать типовые решения под нужды конкретных предприятий, получалось дорого для заказчика, долго для нас и не всегда удобно для пользователя. Когда внедряли отраслевое решение, получалось чуть быстрее, чуть удобнее для пользователя, но сроки и стоимость отличалась не сильно. Опыт работы предыдущих 2-х типов проектов привел нас к тому, чтобы не дорабатывать универсальный функционал, а разработать систему под конкретные предприятия. При этом мы опирались исключительно на опыт совместной работы консультантов и методологов с крупнейшими производителями продуктов питания и изучением всех деталей их бизнес-процессов. Особенностями данной системы является: Модульность. Система состоит из блоков (производства, транспортной и складской логистики, учета маркетинга и продаж), которые комбинируются под потребности предприятия. Лучшие отраслевые практики. Мы решали одни и те же задачи уже столько раз, что заранее знаем, с чем придется столкнуться. И свой продукт, разумеется, разработали максимально адаптивным (и продолжаем делать это с каждым новым проектом). Это прямо влияет на снижение сроков внедрения. Происходит это за счет того, что доработок становится меньше, чем у аналогичного типового или отраслевого продукта. Внимание методологов к запросам пользователей позволило создать интуитивно понятный интерфейс и логику работы системы. Это делает ее максимально удобной и легкой в поддержке. Функционал только тот, который нужен. Это упрощает понимание системы и снижает стоимость поддержки. Мы не говорим, что этот продукт идеален и не требует доработок. Требует. И надо помнить об этом всегда. Однако то, что мы дорабатываем в этом случае – это кастомизация существующих блоков, а не разработка новых. Подытожим сказанное При выборе системы нужно опираться не только на маркетинговую информацию, а более глубоко оценивать систему по таким параметрам как: адаптивность для пользователя стоимость и сложность поддержки и обновлений системы (и возможность делать это своими силами) риски несоответствия функционала системы задачам предприятия Так что советуем при подходе к проекту смотреть в первую очередь на опыт, который имеет компания в области решения аналогичных задач. А также на успешность этого опыта.

О ЧЕМ РЕЧЬ Сегодняшний материал будет интересен представителям финансовых подразделений и представителям производства. Впрочем, отговаривать от чтения всех остальных точно не буду. Поговорим о том – как корректно выстроить связку систем финансового и оперативного учета на производстве продуктов питания. Начнем с того, что автоматизированные системы финансового учета (как минимум бухгалтерского) есть почти на всех предприятиях. А в последнее время конкуренция на рыке производителей продуктов питания заставляет активно заниматься внедрением автоматизированных систем оперативного учета для получения более широкого спектра данных и принятия оперативных управленческих решений. И вот тут возникает вопрос – каким образом организовать и автоматизировать контур оперативного учета? Вести все в одной базе и расширять финансовый контур до детальности оперативного? Разделить их так, чтобы оперативные данные велись в одном контуре, а в финансовый только транслировались необходимые аналитики? Вести их в одной базе или в разных? Сегодня мы поделимся своим опытом и подходами к решению этой задачи. ПРИЧИНЫ РАЗДЕЛЕНИЯ СИСТЕМ Мы на практике решали задачу и путем расширения финансового учета до требований детального учета на производство в единой информационной системе, и выполняли проекты, где контуры оперативного и финансового учета были реализованы в отдельных базах. Дело в том, что финансовый и оперативный учет ведутся для разных целей и обладают принципиально разными свойствами, хотя и основываются на одних исходных данных. В свете этого важно решить один из ключевых вопросов – вопрос границы оперативного и финансового учета и момента перехода данных из одной системы в другую. В итоге мы остановились на том, что наиболее экологичное решение – разделять контуры оперативного и финансового учета (и лучше их делать в разных базах). 3 основные причины почему нам видится разделение данных задач на разные подсистемы: Финансовый учет ведется, как правило на основании бухгалтерских документов и с задержкой на 5-20 дней. В то время как для принятия оперативных решений часто надо обладать информацией практически в режиме реального времени. Системы оперативного учета подстроены под производственные процессы предприятия и изменяются существенно реже нашего «шального» законодательства, поэтому и останавливать систему MES-учета для получения очередного обновления регламентированной отчетности – задача, не несущая никакого профицита для бизнеса. Режим работы MES-систем должен быть организован 24/7, и, соответственно, нельзя останавливаться, когда идут долгие регламентные процедуры (например, по расчету себестоимости) так необходимые для финансовых служб предприятия. Реализация проектов, где финансовый контур детализировался до оперативного приводил к тому, что финансовый учет существенно усложнялся. Наш опыт реализации проектов оперативного учета привел нас к следующим правилам интеграции подсистем финансового и оперативного учета: Необходимо сворачивать аналитики учета до требуемых для экономического анализа // Каждому объекту финансовой подсистемы должно быть поставлено в соответствие несколько объектов оперативной подсистемы. Эта связь должна быть использована в дальнейшем при автоматическом формировании документов финансового учета на основании оперативных документов. Упрощайте схемы движения материальных потоков для формирования себестоимости // Для финансового учета не нужно учитывать все возможные места возникновения затрат и рабочие центры, достаточно взять минимальный объем для получения целевой схемы учета затрат. // Например, когда с точки зрения оперативного учета подразделения детализированы с точностью до производственных участков и цеховой кладовой при них, а в финансовой подсистеме все эти подразделения являются единым подразделением. В этом случае перемещения ТМЦ между участками, а также между участками и цеховой кладовой не попадут в финансовый учет. В финансовом учете будут отражены только агрегированные данные о приходе ТМЦ на подотчет цеху и об отпуске ТМЦ из цеховой кладовой . Определяйте единые точки ввода для справочной информации // Для каждого справочника (подразделения, продукция, номенклатурные группы и т.д.) надо определить систему, в которой элементы справочника будут первично рождаться. Это позволит избежать захламления справочников «дублями». Откажитесь от счетов учета и прочих «бухгалтерских штучек» в системе оперативного учета // Непонятные для оперативных работников реквизиты документов могут вводить их в ступор и тормозить скорость работы людей в системе. Такие вещи должны настраиваться для автоматического обмена в рамках интеграции подсистем. При этом надо сохранять возможность ручной корректировки в системе финансового учета (например, счетов учета и статей затрат). Увеличивайте периоды обмена подсистем, но не забывайте про минимальную потребность обеспечения финансового учета первичными данными. // Такой подход позволит уменьшить нагрузку на систему оперативного учета и увеличить ее производительность. Таким образом, труд финансово-экономических служб существенно упростится, если использовать механизм автоматического формирования финансовых данных на основании оперативных. При таком взаимодействии все технические и экономические службы предприятия получают достоверные и структурированные данные обо всех производственных процессах в режиме реального времени в виде сформированных сводных отчетов в виде таблиц и графических образов. Еще один момент, на который надо обратить внимание – на каком месте в общей информационной системе предприятия данные должны перетекать из одной системы в другую. Любой документ, отражающий оперативную деятельность в системе – это факт передачи ответственности (в т.ч. материальной). Поэтому важно понять – в каком месте будет происходить фиксация факта передачи этой ответственности. Рассмотрим это на примере операции выпуска готовой продукции на склад. Причем сразу оговоримся, что данная операция подразумевает под собой 2 факта: Отражение выпускающим/передающим подразделением факта выпуска/передачи. Подтверждение принимающим подразделением факта его получения в полном объеме. Варианты реализации этих операций следующие: Данные операции можно отражать в системе оперативном учете целиком и затем транслировать в систему финансового учета. В данном случае мы имеем проблему в работе приемщика в 2-х системах, так как факт отгрузки будет фиксироваться уже в системе финансового учета. Можно отражать первую операцию в системе оперативного учета, а подтверждение факта приемки в системе финансового учета. В данном случае придется поддерживать двухстороннюю интеграцию, либо формирование каких-то сводных отчетов из 2-х систем для того чтобы удостовериться в единообразии данных. С точки зрения упрощения работы пользователей второй вариант более удобен, но он требует более грамотного технического подхода и более трудоемок в реализации. Если у вас есть возможность, то лучше склонятся именно к нему. ПЛЮСЫ И МИНУСЫ РАЗДЕЛЕНИЯ КОНТУРОВ УЧЕТА Плюсы a. Уменьшение ручной обработки данных службами финансового учета, т.к. документы уже в том или ином виде приходят к ним в рамках учетной системы. b. Возможность передать в систему финансового учета с любой степенью детализации (не меньшей чем в оперативном учете). И, соответственно, с такой же степенью детализации возможно посчитать себестоимость готовой продукции. c. При желании можно получать оперативные финансовые показатели, основанные на оперативной деятельности (например, ежедневная себестоимость партий готовой продукции). d. Теоретически, жизнь оперативного и финансового учета в одной системе возможна, но вам придется мириться со всем проблемами, обозначенными выше: регулярные обновления информационной системы, недоступность в связи с выполнением регламентных процедур, и дополнительно ваш финансовый учет будет вестись с той же степенью детализации что и оперативный. Оно вам надо? 2. Минусы a. Любая интеграция (в данном случае подсистем учета) требует затрат на реализацию и поддержку корректной работы. b. Кроме самой интеграции надо задуматься об инструментах, которые подтверждают правильность ее работы (напр. разработать стыковочные отчеты). c. Если есть потребность в корректировке данных, то надо делать их в месте первичного возникновения (при повторном обмене информацией скорректированные не в том месте данные могут затереться и породить хаос). В завершение Это наш подход к решению задачи интеграции оперативной системы и системы финансового учета, который показывает свою работоспособность у клиентов. Главное на что хочется обратить внимание в конце, что если вы планируете развивать детальность своей системы учета от финансовой до оперативной, то система оперативного учета – это не расширенная система финансового учета. Это отдельная система для данных, которую лучше реализовывать на разных контурах и в разных базах.