Интерфейсы промышленного уровня ERP–системы. Часть 1

Чем отличается промышленный уровень внедрения системы 1С:ERP от типового решения? В статье описывается, чем обусловлена трансформация в работающую систему при внедрении коробочного ERP-продукта с базовыми интерфейсами и процессами в производстве. Статья написана на основании опыта реально выполненных проектов с наглядными примерами.

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

При этом существенно, что функциональность интерфейсов в 1С:ERP можно условно поделить на два типа:

Документы хозопераций. Отражение хозопераций в «посмертном» учете. Поскольку состав хозопераций, отражаемых в бухгалтерском, налоговом, управленческом учете, основные принципы их отражения и процессы заполнения документов, справочников можно считать общепринятыми, унифицированными, то как правило получается подбирать (за некоторыми исключениями) методические решения ведения учета с использованием только типового функционала.
Автоматизированные интерфейсы (рабочие места) для оперативной работы. В таких интерфейсах как правило работают операторы, диспетчеры, кладовщики, менеджеры, логисты и т.п. Данные интерфейсы в конечном итоге манипулируют с множеством разных взаимосвязанных объектов системы (документы, справочники, регистры) в онлайн режиме (информация может в реальном режиме времени меняться). Работа пользователя не сводится к вводу документов хозопераций и формированию проводок, ведению необходимой справочной НСИ, как у бухгалтерии. На первый план в таких интерфейсах выходит производительность работы пользователя, а именно следующие критерии:

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

В 1С:ERP с этой целью разработаны специальные типовые рабочие места. Эти рабочие места построены исходя из типовой модели оперативной работы пользователей. Но именно на этом “оперативном” уровне на конкретных предприятиях нет унифицированных методик и максимально полно проявляется специфика бизнеса. Редко бывает, чтобы типовой АРМ оказался подходящим на 100% и его использование оказалось в принципе возможным, исходя из вышеозначенных критериев.

Например, АРМ диспетчера цеха. Даже в одной отрасли на одном предприятии, но для разных цехов/участков, разного вида планируемого оборудования или материалов могут возникнуть принципиально различные требования к интерфейсу! А мы имеем в коробочном решении дело с одним АРМом на все случаи жизни…

Здесь опасно то, что при моделировании можно получить приемлемые результаты – система вроде бы формально отрабатывает процессы, заказчик принимает модель, но упускается из виду исполнение вышеназванных критериев, не анализируется трудоемкость работы в системе, ее устойчивость при вводе ошибочных или рассогласованных данных, откате назад операций и т.д. И при запуске системы оказывается, что необходимо множество доработок, а это непредвиденные затраты и срыв сроков. Хорошо, если это объявлено заранее как вторая итерация внедрения – разработка специальных интерфейсов на основе реальной практики работы в системе. Но на это надо закладываться заранее!

Типичные жалобы клиентов при попытках «насаждения» пользователям типового функционала без учета специфики:

«Мне только полдня надо на ввод данных в вашу систему, а когда мне делать основную работу???”
«Зачем тут столько реквизитов, глаза разбегаются! И это все заполнять???»
«Нам нужно выполнять свою работу, а не разбираться в особенностях устройства 1С ERP»
«Вы в новой системе все усложнили, зачем? Тут ввести надо и там, это проверить и тут посмотреть, куча каких-то манипуляций…. Я не гарантирую, что не будет ошибок. Раньше все было в одном окне и все просто, и система не отнимала столько времени».

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

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

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

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

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

Приведем примеры реального опыта с производственных предприятий.

Пример 1. Предприятие по производству упаковочных материалов для пищевых продуктов. Специфика – процессное производство, флексография.

На предприятии несколько производственных участков. Изделие может проходить через один участок или последовательно несколько участков в зависимости от заказа клиента. На каждом участке к изделию добавляются материалы. Производство строго позаказное.

При моделировании столкнулись с вопросами:

У оператора цеха нет времени на работу типовыми документами, вводами на основании, множеством окон и т.д. Ему нужен понятный и четко структурированный интерфейс без лишней информации, адаптированный под его конкретную работу.
На каждом виде оборудования есть свои особенности, соответственно под каждый вид оборудования нужен свой интерфейс.
Количество тех. операций не нормировано однозначно. Например, такие операции, как приладка, подготовка оборудования могут возникать спонтанно по разным причинам. Соответственно, их нельзя запланировать, но нужно фиксировать. В этом плане типовое планирование и назначение тех. операций 1С:ERP не подходит.
Заказчику требуется сквозной учет рабочего времени работы оборудования. В любой момент времени должно быть известно, что происходило на рабочем центре, нужна история операций.

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

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

Почему потребовались производственные интерфейсы? Если даже отбросить неудобства и сложность типовых рабочих мест коробочного решения, то останется ключевая причина, почему это необходимо – для целей выполнения требований ГОСТ по пищевой промышленности необходимо обеспечивать прослеживаемость партий сырья в производстве. А именно – требуется знать, из какого ролика сырья получился ролик готовой продукции. Ролик – серия с уникальным штрих-кодом. В рамках одного производственного этапа по одному заказу клиента может списываться множество роликов полуфабрикатов/сырья, выпускаться множество роликов полуфабрикатов/продукции. Между ними должна быть связь многие ко многим с возможностью точечного указания из какого ролика на входе получился ролик на выходе. В типовом документе «Этап производства» реализовать такую схему без доработок невозможно. Кроме того, у Заказчика есть дополнительные требования, например, непрерывный учет рабочего времени оборудования и регистрация его состояний с точностью до секунды.

Основная причина отказа от работы в типовых рабочих местах – нежелание нагружать сотрудников «лишней» информаций, которая им потом не потребуется. Сотрудники должны выполнять свою работу, а не разбираться в особенностях устройства 1С:ERP. Кроме того, внедрение без производственных интерфейсов требовало корректировки бизнес-процессов – дополнительная нагрузка сотрудников работой, которую они ранее не выполняли.

Покажем, как выглядела бы работа с типовыми документами 1С:ERP:

Ввод количества материалов по этапу производства. На вкладке обеспечение требуется вручную посчитать общее количество материалов по фактически использованным сериям, т.к. заранее неизвестно, какое количество по сериям должно быть отгружено под этап:

Ввод количества материалов по сериям на вкладке расход путем сканирования ШК серий. Была сделана доработка, которая позволяет при сканировании ШК заполнять полный остаток серии, т.к. серии не делимые (ролики):

Для ввода новых серий множество «лишних нажатий»:

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

С учетом всех вышеописанных неудобств и необходимостью доработок в документе «Этап производства», в любом случае потребовалась бы доработка, которая оптимизирует ввод данных в этом документе.

Поэтому самый рациональный вариант – разработать производственные интерфейсы «с нуля», заточенные под функции операторов оборудования, независимые от особенностей ERP. Но при этом не вмешиваться в модель данных 1С:ERP, максимально облегчить обновления.

В результате разработан и используется специализированный интерфейс промышленного уровня: