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

Новость об отмене поддержки УПП грянула «нежданно-негаданно». И реально застала врасплох сотни промышленных предприятий по всей стране, долгое время успешно работавших на привычной платформе. Обсуждения на тему «зачем» и «почему» буквально взорвали интернет. Однако, как говорится, «слезами горю не поможешь», поэтому сегодня совсем не об этом. Насущный вопрос: на что переходить? Вот на него отвечать и будем. В необходимости перемен компания 1С выбора не оставила. А вот пути отступления можно рассмотреть разные. Даже не так: это необходимо сделать, чтобы не прогадать и не оказаться в ситуации несоответствия задач на предприятии инструментам их решения. Кажется, что это нереально? («Ведь другие же как-то работают» / «Ведь 1С знает, что предлагает»). Не буду забегать вперед. Опишу варианты, а выводы – за вами. 2 основных варианта: 2 типовых решения Что может предложить сейчас рынок? Базовое предложение компании 1С: все, у кого не ERP, переходите на «1С:ERP». Или на «1С:Комплексная автоматизация 2.0.», в зависимости от сложности бизнес-процессов. Вспомним суть: 1С:ERP – флагманское решение компании 1С, направленное на автоматизацию полного перечня бизнес-процессов на предприятии. 1C:КА – его «усеченная» и, как следствие, более дешевая версия для торговых компаний. Или тех, кому не сильно важен детальный оперативный учет. Например, если не требуется его позаказной детализации. Однако, если бы мы ограничились сравнением, тогда бы получилась статья «для всех» и «не о чем», а мы пишем непосредственно для вас – пищевиков. Поэтому, рассматривая каждый из вариантов, будем акцентировать внимание особенности задач пищевого предприятия промышленного масштаба. Итак, на пищевом предприятии полного цикла (от приемки сырья до поступления готового продукта на полки магазинов) существует Две области задач: Регламентированные задачи (формирование внешней/внутренней отчетности). Для этого ERP и КА подходят одинаково.Распределение затрат в этих двух системах происходит по-разному, но при наличии оперативных блоков (как раз и отличающих производственные предприятия от чисто торговых) все распределение, как правило, делается там. Оперативные задачи (производство, торговля). Вот здесь-то как раз типовые ERP и КА начинают сопротивляться. Даже не так: КА для учета в производственной компании в одиночку не справится по определению. А тем более пищевой, где производство осложнено массой РАЗНЫХ для каждого вида продукции особенностей, а также норм и требований внешних контролеров (например, для молочников учет сырья в нескольких единицах измерения, а также соблюдение баланса по жиру). Там просто нет блока для решения оперативных задач. Поэтому мы, занимаясь последние 4 года только задачами пищевиков, в оперативном производственном контуре выделяем следующие группы задач, для которых в рассматриваемых типовых вариантах практически нет требуемого функционала: Оперативный рецептурный контроль при формировании наборов/комплектов сырья, специй или ингредиентов; Оперативный контроль технологических параметров производства (температура, время обработки); Оперативный учет потерь и выходов на каждом технологическом переделе производства; Учет качественных и лабораторных отраслевых анализов на каждом технологическом этапе производства; Партионный учет движения и расхода сырья и производственных полуфабрикатов для обеспечения задачи прослеживаемости (читай пищевой безопасности); Отчасти может помочь отраслевое решение. Но, собираясь его использовать, на начальном этапе надо здраво понимать, что вы хотите получить от перехода в итоге. И снова (повторюсь в который раз!), сначала выяснить полный спектр возможностей этой типовой системы. А также примерить этот функционал на себя, чтобы потом не было мучительно больно за впустую потраченные деньги/ время/ нервы на «недовнедрение». К сожалению, большинство предприятий забывают об этом и обращают внимание только на регламентированные задачи. И слишком поздно приходят к выводу о том, что если у производства есть какая-либо отраслевая специфика, то на типовой ERP ее запускать смысла нет. И все же, если союзу «типовое + отраслевое решение (также типовое)» быть, то при наличии отраслевой части производственный блок в ERP получается не востребованный. И проще взять КА, которая дешевле в 4 раза. Подведем некий подитог: финансовый (регламентированный) блок очевиден и понятен. ЕРП и КА справятся. Важнее обращать внимание на то, как автоматизировать складские процессы, торговые, планирование, оперативный учет на производстве. А это типовой функционал ни ЕРП, ни КА не покроет. Важно помнить, что, если решение называется «типовым», это совершенно не означает, что оно подходит всем. И бесполезно пытаться втиснуться в шаблон, если туда изначально не заложено возможностей поддержки того функционала, который является специфическим именно на вашем производстве. Так что же тогда выбрать? (если ничего из предложенного не подходит) Вот здесь может помочь только отраслевая экспертиза, основанная на опыте многократного внедрения одного и того же/ вариативной совокупности решений на схожие предприятия. Мы занимаемся этим уже более 13 лет. И успели сделать выводы о том, что работает, а что – определенно нет. Если кратко: Такое решение, как «1С:ЕРП + модуль для автоматизации коммерческих или производственных функций» на практике наших клиентов функционирует очень хорошо. Суть в том, что этот модуль является решением, разработанным ИМЕННО ПОД ВАС. В нем нет ничего типового. Поэтому и работает. При чем после небольшой отладки практически безупречно. Регламентированные задачи — это область, которую можно безоговорочно доверить ERP. А вот оперативные задачи требуют индивидуального подхода. Хотя, конечно, никто не мешает вам изобретать велосипед и допиливать шаблон силами штатных ИТ-шников или франчайзи. Вот и решайте сами: взять готовое решение и интегрировать его с качественным продуктом 1С или бесконечно долго пилить все в одной системе. Кто поможет? Кстати, для тех, кто еще не определился с выбором/ хочет проконсультироваться с экспертами отрасли/ проанализировать соответствие возможностей различных систем задачам своего предприятия/ принять взвешенное решение: 21 июня в Москве мы организуем практикум для производителей продуктов питания «Переход с 1С:УПП. Куда идти и что делать?» На практикуме вы сможете: Узнать обо всех возможных вариантах архитектуры ИС после отмены УПП. Практика решений в отрасли (с ERP или без). Сделать вывод на основе мнения экспертов отрасли: Какой путь выбрать (от простой настройки учета в новой базе до переосмысления роли ИТ в бизнесе)? Оценить сроки и стоимость перехода? Выяснить — с чем вы можете столкнуться, выбрав тот или иной путь + узнать пути обхода «граблей» внедрения нового продукта. Что может удлинить/усложнить проект и как этого избежать? Пообщаться с коллегами по цеху из разных регионов, но из одной отрасли и с одинаковыми проблемами (на основе реальных кейсов узнать «как это сделано у других») Подробности о программе и порядке регистрации на сайте http://event.standart1c.ru/

Регулярно в ходе наших проектов мы сталкиваемся с очень важным вопросом – организацией IT-ландшафта. И традиционно сразу образуется 2 лагеря: сторонники одной большой информационной системы («лучшая интеграция та, которой не было») и сторонники использования нескольких отдельных информационных систем («под каждого воробья пушка своего калибра»). У каждого из этих подходов есть свои плюсы и минусы, которые мы не будем глубоко затрагивать в рамках этой статьи, однако попробуем раскрыть тему. Как жить безопасно, если интеграции все-таки быть? Если все-таки сложилась ситуация, при которой в нашем IT-ландшафте будет несколько различных информационных систем, то при проектировании этой схемы необходимо предусмотреть методологические аспекты: каким образом мы будем нарезать наши бизнес-процессы таким образом, чтобы они и работали органично (когда на каждом этапе в информационной системе выполняются только те операции, которые должны выполняться) и обеспечивали достаточно целостное информационное пространство, в котором работают пользователи. Попробуем разобрать традиционную для производителей продуктов питания задачу – организацию документооборота с клиентами. И выявить правильные и не правильные способы ее решения. Распространенный вопрос: отделять логистический контур от финансового или нет? Неправильная схема разделения: В логистическом контуре выписываем документ реализации, затем он выгружается в финансовую базу. После возврата документов от клиентов мы начинаем редактировать их в базе финансового учета. И при редактировании у нас получаются изменения, которые влияют на остатки товаров, важные для логистического контура. На лицо нарушение одного из базовых правил – объект должен создаваться и редактироваться в одном месте. Пример правильной схемы разделения: Документы реализации создаются и редактируются в своем контуре, затем за какой-то завершенный период (день, неделя, месяц) документы выгружаются в контур фин. учета. Таким образом получается, что документы создаются и редактируются в одном месте, а база фин. учета является потребителем выверенной информации логистического контура. Если мы методологически грамотно разделили информационные потоки – это уже очень весомый вклад в то, что системы будут функционировать нужным образом. Но у нас так же остается достаточно серьезный вопрос Техническая организация обменов Чтобы не ошибиться с выбором механизма интеграции, необходимо сначала определиться с «калибром»решаемой задачи. Итак, можно выделить 4 уровня ее масштабности: Локальный – характеризуется обменом через внешние файлы. Данный механизм мы относим к классу устаревших, но тем не менее ранее он был достаточно распространен и с некоторыми ИС является единственным доступным вариантом интеграции. Регулярный в однородных средах – подразумевается, что интегрируемые ИС находятся в одной информационной среде. Например, на одном сервере, обмениваются через COM. Такой механизм на текущий момент достаточно часто встречается и позволяет решать задачи интеграции регулярного характера. Его удобно реализовывать, когда у нас имеется относительно небольшое количество ИС. Преимуществом такого подхода является очень легкая настройка и создание программного интерфейса, которым будут пользоваться интегрируемые системы. Регулярный в гетерогенных средах – подразумевается, что интегрируемые ИС могут располагаться на разных серверах, с разными ОС, даже территориально обособлено. Речь идет об обмене через web сервисы. Одно из преимуществ такого подхода – возможность интегрировать базы в различных средах, при этом сохраняя относительно невысокую сложность настройки интеграции. Промышленный – применение отдельно стоящих решений в гетерогенных средах: шины ESB (например DATAREON) или промышленный сервер очередей (например RabbitMQ). Такие решения актуально применять, когда в обмене участвуют более 3-х ИС, когда важно обеспечить качественную передачу НСИ между всеми системами, и когда важно балансировать нагрузку между обменивающимися ИС. Инструменты проверки Когда мы решили первые 2 вопроса в нашем пути интеграции, настает время подумать о поддержке эксплуатации ИС в части интеграции. И здесь встает вопрос о том, чтобы можно было в 1 информационном пространстве сверить данные 2-х интегрируемых систем. Как один из примеров – анализ отгрузок в базах фин. учета и логистического контура. Здесь мы так же выделяем 2 подхода: Пассивный – когда ответственный за участок учета пользователь формирует отчет, который позволяет сравнивать данные за идентичный период в 2-х базах и предпринимать какие-то действия в случае расхождений Активный – когда есть некий анализатор, который регламентно получает 2 набора данных из разных баз, сравнивает их и в случае расхождения оповещает ответственного. Таким образом, если вы планируете строить не просто систему автоматизации фин. учета, а систему управления, в том числе и на оперативном уровне, то вы неизбежно придёте к архитектуре нескольких информационных баз. Наиболее успешные из автоматизированных предприятий потому и являются таковыми, что вовремя осознали ценность концепции микросервисов (когда небольшие отдельные ИС решают узконаправленные задачи), ведь выиграть в конкурентной борьбе им смогли помочь только специализированные решения, которые заточены под их особенности и способны достаточно оперативно реагировать на изменения среды. Именно на примере этих компаний мы понимаем, что для реализации таких подходов требуются надежные и удобные для внедрения и эксплуатации средства интеграции IT систем. P.S.: Интеграция – это задача, а вовсе не проблема. И, при современном уровне ее осмысления и наборе технического инструментария - больше, чем решаемая.