CC BY
34
Соловейчик К.А.
РАЗРАБОТКА СИСТЕМЫ ИНТЕГРАЦИИ ПОДСИСТЕМЫ ДИСПЕТЧИРОВАИИЯ С ОСНОВНОЙ УЧЕТНОЙ СИСТЕМОЙ МАШИНОСТРОИТЕЛЬНОГО ПРЕДПРИЯТИЯ
Аннотация. В результате разработки системы интеграции подсистемы диспетчироеания с основной учетной системой машиностроительного предприятия с целью роста экономически эффективной глубины передела впервые был создан алгоритм, позволяющий интегрировать комплексную подсистему диспетчироеания машиностроительного предприятия с семейством программных продуктов, разработанных на платформе « 1С:Предприятие 8» для отслеживания обеспеченности производственного процесса, а также передачи данных о затратах, понесенных в производственном процессе, для расчета производственной себестоимости.
Ключевые слова. Глубина передела, процессы управления, машиностроение, управление промышленным производством.
Soloveichik К.А.
DEVELOPMENT OF THE INTEGRATION SYSTEM OF THE DISPATCHING SUBSYSTEM WITH THE MAIN ACCOUNTING SYSTEM OF THE MACHINE-BUILDING ENTERPRISE
Abstract. As a result of the development of integration system for dispatching subsystem with the main accounting system of machine-building enterprise in order to increase cost-effective depth redistribution, an algorithm was established for the first time in order to integrate complex dispatching subsystem of engineering enterprises with a family of software products developed on the platform "1С: Enterprise 8" to monitor the provision of production process as well as the cost of data transmission incurred in the manufacturing process for calculating the cost ofproduction.
Keywords. Process stage quotient, depth redistribution, management processes, mechanical engineering, industrial production management.
В продолжение цикла статей [2, 3] по методологическим вопросам оптимизации производственного планирования, автоматизации и компьютеризации процессов управления производством, вызванных необходимостью роста глубины передела промышленной продукции [9], данная статья рассматривает вопросы экономики и управления машиностроительного производства в части диспетчеризации с использованием оптимизационного математического аппарата, подробно изложенного в [1, 4, 5]. Также использованы уже упоминавшиеся в предыдущих статьях источники [7, 8, 10-12]
Подмодуль интеграции системы диспетчирования с основной учетной системой предназначен для осуществления информационного взаимодействия на уровне исходных данных, используемых подси-
ГРНТИ 55.01.75 О Соловейчик К. А., 2017
Кирилл Александрович Соловейчик - доктор экономических наук, доцент, заведующий кафедрой процессов управления наукоемкими производствами Санкт-Петербургского политехнического университета Петра Великого, вице-президент Торгово-промышленной палаты Санкт-Петербурга, президент ОАО «ЛЕНПОЛИГРАФМАШ». Контактные данные для связи с автором: 197376, Санкт-Петербург, наб. реки Карповки, 5 (Russia, St. Petersburg, Karpovki emb., 5). Тел.: 8 (812) 234-85-95.
стемой диспетчирования для заполнения документов оперативного производственного учета, а также выходных данных, используемых для проведения в учетной системе итоговых расчетов по заработной плате и выпуску товарной продукции. В ходе разработки подмодуля интеграции была спроектирована следующая последовательность действий по проведению первоначальной интеграции (рисунок 1):
Рис. 1. Последовательность действий по подготовке и проведению первоначальной интеграции
1. Первоначально проходит выгрузка структуры каждой базы. Выгрузка предполагается с использованием типовых средств используемой программной платформы, при которой конфигурация информационной базы сохраняется в файл формата XML [6].
2. Далее проводится настройка правил обмена, в которых указывается, как направление движения информации (двустороннее, одностороннее), так и соответствие полей базы-источника и базы-приемника.
3. Проводится тестовый обмен. На данном этапе базы обмениваются данными в соответствии с первоначально разработанными правилами обмена, а также выявляется реальное время проведения обмена данными.
4. Проходит тестирование и устранение ошибок. Выявляются по возможности все возникшие проблемы, связанные с отклонением в поведении подмодуля интеграции от заданных правил осуществ-
ления интеграции. После устранения части ошибок интеграции может проводиться очередной тестовый обмен и устранение дальнейших ошибок. Таким образом, процесс может быть итеративным.
5. Проводится контрольный тестовый обмен, выполняющийся на копиях актуальных версий информационных баз, и последующая проверка обмена, с тем чтобы гарантировать корректность и усилить надежность переноса данных.
6. Проводится обмен на реальных системах в максимально сжатые сроки, чтобы в меньшей степени затрагивать работу пользователей с интегрируемыми системами.
7. После успешного выполнения первоначальной интеграции могут быть установлены настройки для осуществления обмена данным на регулярной основе.
Подмодуль интеграции задает параметры обмена экземплярами объектов информационных баз. Алгоритм проведения обмена экземплярами объектов, предназначенных для обмена, представлен на рисунке 2.
да нет
Объект присутствует
Рис. 2. Алгоритм осуществления интеграции подсистемы диспетчирования с учетной системой
Согласно представленному алгоритму, подмодуль интеграции получает информацию об измененных объектах в подсистеме диспетчирования и в учетной системе. Если объекты изменены в одной из систем, измененный объект переносится в другую информационную систему. В процессе переноса подмодуль интеграции проверяет данные, содержащиеся в ключевых полях синхронизируемых объектов. В случае если переносимый объект уже имеется в базе-приемнике, объект обновляется в этой базе. В противном случае, если объект не был найден по ключевым полям (в т.ч. по уникальному идентификатору - СиЮ). объект переносится в базу-приемник целиком.
Не все объекты, присутствующие в системах, требуют проведения синхронизации, поскольку не все объекты присутствуют в обеих базах одновременно и не каждый объект должен быть доступен пользователям взаимодействующей базы. Исходя из этого, определен конечный перечень объектов для обмена (таблица 1).
Таблица 1
Параметры обмена объектами подсистемы диспетчеризации и учетной системы
Тип объекта Наименование объекта в подсистеме диспетчирования Направление обмена Ключевые поля
Справочник Номенклатура Двусторонний Артикул
Справочник Статья затрат Двусторонний оиго
Справочник Номенклатурная группа Двусторонний оиго
Справочник Единицы измерения Двусторонний оиго
Справочник Техкарты производства Двусторонний оиго
Справочник Спецификации Двусторонний оиго
Справочник Рабочие центры Двусторонний оиго
Справочник Группы заменяемости РЦ Двусторонний оиго
Справочник Подразделения Двусторонний Код
Справочник Организация Двусторонний Код
Справочник Физические лица Двусторонний Код
Регистр Кадровая история сотрудника Из учетной системы в подсистему диспетчеризации Код элемента справочника "Физические лица"
Справочник Смена Двусторонний Код
Справочник Графики работ Двусторонний оиго
Справочник Профессии рабочих Двусторонний Код
Справочник Склады Из учетной системы в подсистему диспетчеризации оиго
Справочник Контрагенты Из учетной системы в подсистему диспетчеризации оиго
Справочник Технологичестие операции Двусторонний оиго
Справочник Классификатор единиц измерения Двусторонний оиго
Справочник Валюта Из учетной системы в подсистему диспетчеризации Код
Регистр Курс валют Из учетной системы в подсистему диспетчеризации оиго
Документ Акт выполненных работ Из подсистемы диспетчеризации в учетную систему оиго
Документ Внутренний заказ Двусторонний оиго
Документ Заказ на производство Из учетной системы в подсистему диспетчеризации Номер запуска в учетной системе (в пределах года). Код документа в подсистеме диспетчеризации.
Документ Закрытие заказов на производство Двусторонний оиго
Документ Отчет мастера смены Из подсистемы диспетчеризации в учетную систему оиго
Документ Отчет о составе смены Из подсистемы диспетчеризации в учетную систему оиго
Документ Сдельный наряд Из подсистемы диспетчеризации в учетную систему оиго
Документ Формирование потребностей Двусторонний оиго
Поскольку структура данных подсистемы диспетчеризации с учетной системой схожа, многие объекты могут быть синхронизированы путем сопоставления глобального уникального идентификатора, не повторяющегося для обеих синхронизируемых информационных баз. Подчеркнем, что имеются особенности сопоставления отдельных объектов. К примеру, номенклатура сопоставляется по артикулу, вносимому пользователями. При этом в подсистеме диспетчеризации и учетной системе должна быть реализована проверка вводимых артикулов на уникальность. Документ «Заказ на производство» может быть однозначно идентифицирован по номеру запуска и году (составное ключевое поле), однако поле «Номер запуска» содержится в разных реквизитах данного документа в подсистеме диспетчеризации и учетной системе, поэтому в правилах обмена необходимо предусмотреть поиск значений в соответствующих реквизитах. Кадровая история сотрудников также имеет особенности: в подсистеме диспетчеризации не ведется учет по сотрудникам организации, поскольку кадровый учет не является одной из основных функций данной подсистемы, поэтому сопоставление информации о сотрудниках необходимо производить через нахождение ключевых полей, связанных с сотрудниками-физическими лицами.
Проектирование подмодуля интеграции системы диспетчирования с учетной системой «¡(^Управление производственным предприятием» для осуществления интеграции с учетом разработанного алгоритма осуществлялось с использованием средства автоматизации под названием «¡(^Конвертация данных». Данный инструмент предназначен для составления правил обмена объектами между информационными системами в пользовательском режиме.
В первую очередь, типовыми механизмами платформы «1С:Предприятие» была выгружена структура информационных систем в файлы формата XML. Полученные файлы XML были загружены в средство автоматизации «1С:Конвертация данных», которое смогло распознать и наглядно предоставить структуру каждого объекта. В соответствии с разработанными соответствиями между базами произведена настройка правил обмена объектами. Элементы справочника «Номенклатура», содержащего перечень материалов, комплектующих, деталей и сборочных единиц, предлагается находить по артикулу во время обмена. Данное поле, по сути, является ключевым, и при настройке обмена оно отмечается жирным шрифтом. По данному объекту осуществляется двусторонний обмен, что означает, что добавленная в учетную систему номенклатурная позиция при очередном обмене перейдет в подсистему диспетчирования.
Документ «Сдельный наряд», формируемый в подсистеме диспетчеризации, содержит информацию по сдельной заработной плате рабочих. Предполагается переносить данный документ только в одностороннем режиме в учетную систему. Соответствие предполагается находить по внутреннему уникальному идентификатору. Документ «Отчет мастера смены» хранит информацию о выпущенном производственным подразделением количестве номенклатуры (деталей, сборок, изделий). Соответствие предполагается находить его по внутреннему уникальному идентификатору. Так же, как и документ «Сдельный наряд», данный документ предполагается переносить только в одностороннем режиме в учетную систему. Документ «Заказ на производство» первоначально формируется в учетной системе на основании заказов покупателей. В данном документе хранятся сведения об изделиях, которые необходимо запустить в производство. Предполагается односторонний перенос данного документа из учетной системы в подсистему диспетчирования, при этом соответствие предполагается находить по реквизиту «Номер запуска» (в учетной системе) и «Код» (в подсистеме диспетчирования), однозначного определяющему объект в рамках одного года.
Далее был разработан программный продукт, обеспечивающий процесс диспетчеризации производства, а также обеспечивающий контроль выполнения технологического процесса создания готовой продукции в соответствии с алгоритмом, подробно описанным в [3]. Диспетчеризация производства задействует целый ряд документов. Источником данных и разрезом аналитики для производственного учета является производственный заказ.
Производственная служба выполняет запуск изделий в производство путем формирования производственной программы на основании набора заказов на производство. В результате сохранения производственной программы можно получить маршрутные карты производства, по которым рабочие смогут выполнять последовательность операций. Для отображения структуры изделия с полным раз-узлованием конструкторами и сотрудниками производственной службы используется разработанный отчет о составе изделия.
Сотрудники отдела снабжения могут определять потребность в материалах под запуск с помощью отчета «Сводный дефицит». Диспетчеры и экономисты цехов, а также мастера участков имеют возможность отражать в программе факт завершения операций документом «Отчет об исполнении операций». Отметка о прохождении контроля качества производится несколькими документами и осуществляется после отметки о завершении выполнения операции одним или несколькими рабочими. По мере выпуска изделий или деталей факт поступления готовой детали на склад фиксируется разработанным документом «Сдаточная накладная».
Итоговые агрегированные сведения о результате производственного процесса за период попадают в документы выпуска для последующей передачи в учетную систему для начисления заработной платы сотрудникам и для расчета себестоимости конечных изделий. Разработаны отчеты, позволяющие отслеживать производственный процесс по мере его выполнения и видеть не только итоговые, но и промежуточные сведения для использования производственными службами. Для учета работ, которые не были заранее зафиксированы в маршрутной карте, разработаны документы «Наряд», разделенные на 2 вида: рабочий наряд и доплатной наряд. Примеры макетов документов приведены в таблицах 2-4.
Таблица 2
Макет шапки документа
Номер: Д515 от: 25.06.2015 15:06:49 Статус: Создан
Таблица 3
Макет закладки «Основная»
Номенклатура: ДЦ8.416.054 - Колесо зубчатое V Доплатной наряд
Описание работ: Капролоновый блок =38x800x850.
Операция: Фрезерная
Шифр: 62 - Несоответствие материала по качеству и размерам
Номер тарифной сетки: Разряд работ: Расценка шт.: РасценкаПЗ:
Время шт.: 0,000 Стоимость шт.:
Время ПЗ: 0,000 Стоимость ПЗ:
Количество: 0,000 Сдано:
Таблица 4
Макет табличной части «Сотрудники»
№ Сотрудник КТУ Коэффициент ПЗ Стоимость шт. Стоимость ПЗ Сумма к начислению Дата
Поля табличной части должны считаться по аналогии с документом «Отчет об исполнении операций». Данные из этой табличной части будут основной для заполнения «Отчета об исполнении операций». Поле «Дата» - предполагаемая дата выполнения операции сотрудником (справочно). Признак (флажок) «Доплатной наряд» (снят по умолчанию): при его установке делать обязательным для заполнения поле «Шифр», а при снятии - делать это поле недоступным. Поле «Шифр»: выпадающий список из справочника «Виды дополнительных работ». Вид элементов выпадающего списка в формате: «Код - Наименование», например «60 - Внешние дефекты литья». Поле «Описание работ» - текстовое поле. Не должно быть доступно для редактирования, если проведенный документ имеет статус «К выполнению» или «Выполнен». Поля «НТС», «Разряд работ», «Время шт.», «Время ПЗ», «Расценка шт.», «Расценка ПЗ» должны быть доступны для изменения только для пользователя с ролью «оу пНормировщик».
При изменении номера тарифной сетки и рабочего автоматически заполняется расценка (в соответствии с организацией, указанной в документе, либо организацией, указанной в свойствах пользователя). Т.к. в тарифной сетке значение ставки одно, то расценка штучная будет совпадать с расценкой ПЗ. Имеется возможность изменить расценку нормировщиком. Информация о сданном количестве деталей автоматически рассчитывается по документам «Отчет об исполнении операции», созданным на основании наряда на выполнение работ. При заполнении поля «Маршрутная карта» автоматически заполняются остальные незаполненные поля: «Номенклатура», «Спецификация», «Технологическая
карта», «Производственная программа», «Организация», «Подразделение», «Заказ», «Конечная продукция». При изменении документа пользователем с ролью «оупНормировщик» автоматически меняется статус на «Отнормирован», если «Время шт.» или «Время ПЗ» больше нулевого значения, а также заполнен номер тарифной сетки и разряд работ. При добавлении сотрудников в табличную часть автоматически меняется статус «К выполнению».
Также реализован механизм отбора операций мастером смены для формирования сменно-суточного задания. Для выполнения диспетчером задачи по фиксации в программе факта завершения операции создан интерфейс, позволяющий отбирать операции по наименованию спецификации изготавливаемой детали. На интерфейс добавлена закладка «Сменно-суточные задания», отображаемая только при установленной опции в настройках программы (в разделе «Оперативное управление производством»): Использовать сменно-суточные задания. Разработан документ «Отчет об исполнении операции», позволяющий зафиксировать выполнение операции и исполнителей (рабочих). Вызывается при завершении операции из обработки «Диспетчирование производства». Возможно создавать вручную и добавлять операции подбором. На закладке «Выпуск» автоматически заполняется номенклатура и количество деталей из маршрутной карты, но только для тех операций, по которым имеется выпуск.
Для калькуляции заработной платы сотрудников и объема фактического производства изделий и деталей имеются документы «Сдельный наряд» и «Отчет мастера смены». Для упрощения формирования этих документов был разработан механизм в виде обработки «Формирование документов мастера смены», который позволяет отобрать перечень выполненных за период операций и сформировать по ним необходимые документы.
Для регистрации в программе исполнения операций по кооперации другим подразделением (цехом) разработан документ «Исходящий наряд». Документ формируется диспетчером цеха по завершении операции, после которой идет операция, назначенная программой на выполнение в другом производственном подразделении. Разработанный документ «Исходящий наряд» необходим для понимания стороннему подразделению необходимости выполнить технологическую операцию по маршрутной карте. Для этого в интерфейсе диспетчеризации рядом со списком операций добавлена кнопка, по нажатию которой создается документ «Наряд исходящий» с данными, и у операции меняется значение статуса на «Исх наряд».
Для реализации функционала исполнения операций по исходящим нарядам на форме списка исходящих нарядов добавлена кнопка исполнения операций. При нажатии кнопки «Создать отчет об исполнении операции» открывается отчет об исполнении операции. Количество, доступное для проводки, ограничено двумя условиями, связанными логическим знаком И: [Кол во для проводки] < = [Кол-во в МК] - [Сумма количеств в ООИО для данной МК для данной операции];
[Кол во для проводки] < = [Кол-во в наряде] - [Сдано]'.
После проводки отчета об исполнении операции по наряду, в наряде изменяется значение поля «Сдано» на: Сдано + проведенное количество. После проводки неполного количества статус наряда меняется на «Выполняется». После проводки последней операции (Количество = Сдано) статус наряда изменяется на «Выполнен». Для определения величины взаиморасчетов между подразделениями разработаны документы «Акт выполненных работ». Согласно разработанной и принятой в эксплуатацию терминологии: собственные детали - детали, закрепленные за данным подразделением как за цехом-сдатчиком (т.е. детали, изготавливаемые по маршрутным картам, в свойствах которых указано данное подразделение, сдающее эти детали); несобственные детали - детали, операции в которых закреплены за данным подразделением, но в которых подразделение не является цехом-сдатчиком.
Документ содержит 3 табличные части: по собственным деталям - содержит перечень деталей, изготавливаемых данным подразделением; по несобственным деталям - содержит перечень операций, которые выполнялись данным подразделением для других подразделений; по дополнительным работам - содержит перечень операций, которые выполнялись данным подразделением по рабочим/доплатным нарядам, в качестве подразделения в которых указано данное подразделение.
Табличные части заполняются по нажатию на кнопку «Заполнить» на основе данных документов «Отчет об исполнении операции» и «Маршрутная карта» по отборам из шапки документа. В табличной части по собственным деталям заполняются данные по тому количеству, которое было указано в документах «Приемная накладная» по маршрутной карте. В табличной части по несобственным дета-
лям и по дополнительным работам заполняются данные по тому количеству, которое было указано в документах «Отчет об исполнении операции» с отметкой прохождения ОТК (отдел технического контроля).
В программном продукте предусмотрен учет запасов материалов на складах, однако для регистрации в программе информации о расходовании материалов в производстве был добавлен новый функционал создания требований-накладных. Исходная информация для создания этих документов - разработанный отчет по сводному дефициту материалов под запуск. Для создания сотрудником отдела снабжения документов «Требование-накладная» создана обработка, в которой реализованы следующие требования: оОтбор маршрутных карт (МК) по производственной программе, отбор материалов и комплектующих по выбранным МК; отображение статуса отоваренности МК и дефицита материалов по отобранным МК; возможность создания документа «Требование-накладная» и заполнение состава создаваемого документа.
Обработка «Формирование требований-накладных» разбита на 3 области:
1-я область должна отображать перечень маршрутных карт в отобранных производственных программах (с флажками для отбора МК в перечне). Табличная часть содержит следующие поля: Деталь -номер детали (ссылка на деталь); Производственная программа - номер документа (ссылка на документ); Заказ на производство - номер документа (ссылка на документ); Отоварено - признак отоваренности МК (если все заявленные в МК материалы и комплектующие (с учетом параметров отборов) отпущены по требованиям-накладным).
2-я область обновляется при нажатии кнопок «Сформировать» либо «Обновить» и содержит следующие поля табличной части: Вид номенклатуры; Ед. изм.; Заявлено - количество материалов и комплектующих, требуемых для выбранных МК; Складской остаток = свободный остаток материалов + неиспользованный остаток, хранимый под резерв данного заказа на производство; Складской дефицит - рассчитывается как большее из чисел: 0 или разница между заявленным количеством и количеством, выданным по требованиям, и складским остатком; Дефицит по требованиям = тт(Заявленное количество - количество, выданное по требованиям; Складской остаток). По двойному клику производится расшифровка по документам складского движения за последние 7 дней (основные документы: оприходования, поступления товаров и услуг, требования-накладные, перемещения). Зеленым выделяются строки, по которым материалы отпущены в производство в полном объеме по требованиям-накладным. Красным выделяются строки с отрицательным складским остатком.
3-я область содержит список сформированных требований-накладных и кнопку «Создать», по нажатию на которую создается документ «Требование-накладная», заполненный строками из 3-й области «Сводного дефицита». Заполнение состава документа производится с помощью кнопки «>», которая переносит из 2-й области в 3-ю материалы с количеством, равным значению в колонке «Дефицит по требованиям».
В программе реализован механизм проверки прохождения технического контроля при завершении операции: при создании документа «Отчет об исполнении операций». Добавлена возможность вариативной поддержки механизма ОТК для подразделений путем создания списка «Настройка ОТК для подразделений». В нем содержится перечень всех подразделений и поле «Использовать процесс ОТК», в котором проставляется галочкой, использовать или нет процесс ОТК для данного подразделения. Если для подразделения, указанного в строке операции, установлен признак «Использовать процесс ОТК», то при завершении операции для неё устанавливается статус операции «Требуется проверка ОТК». Если нет, то устанавливается статус «Завершена». Для фиксации факта прохождения технического контроля разработан документ «Предъявление номенклатуры для контроля качества». При проведении документа «Предъявление номенклатуры для контроля качества» плановое количество в последующих операциях прежней маршрутной карты сокращается на величину неисправимого брака, полученного по сумме операций в документе «Предъявление номенклатуры для контроля качества» по данной маршрутной карте.
На форме диспетчеризации реализован механизм, при котором после завершения операции (или указания количества деталей, соответствующих качеству, если в подразделении ведется учет ОТК), на которой был выпуск согласно маршрутной карте, будет производиться увеличение значения в реквизите «Произведено». На форме диспетчеризации производства кнопка ОТК активна только для операций с количеством «Требует ОТК» больше 0 и только для роли «Сотрудник ОТК» (либо «Полные
права»). При нажатии кнопки ОТК создается документ ОТК «Предъявление номенклатуры для контроля качества». Этот документ должен изменять значение нескольких полей, отображаемых в отчете об исполнении операции.
В обработке «Формирование документов выпуска» доработан механизм формирования документов с учетом ОТК: при установленной настройке «Использовать процесс ОТК» для подразделения, указанного в операции внутри документа «Отчет об исполнении операции», сдельный наряд и отчет мастера смены должны заполняться только если у операции установлен статус «ОТК пройден» или «Завершена». Если у операции установлен статус «ОТК пройден», то в документы выпуска попадают данные по тому количеству, которое соответствует качеству согласно документам ОТК.
Для отображения структуры изделия с полным разузлованием был разработан отчет «О составе изделия». В качестве исходных данных отчет использует перенесенные из системы РБМ спецификации и технологические карты производства. Отчет имеет 2 закладки:
1. Закладка «Полный состав» имеет установленный по умолчанию параметр «С учетом сборок» и табличную часть с полями: Наименование - наименование детали (с видом воспроизводства «Производство»); Подразделение - цех и участок (по технологической карте); Применяемость (количество деталей в вышестоящей детали); Применяемость на изделие (количество деталей в изделии с учетом количества деталей в иерархии); Сборка - вышестоящая деталь. Если снят флажок «С учетом сборок», значение поля «Применяемость на изделие» суммировать по повторяющимся в сборках деталям.
2. Закладка «Разузлование номенклатуры» отображает табличную часть, строки которой выводятся в виде дерева: Наименование - наименование детали (с видом воспроизводства «Производство»); Подразделение - цех и участок (по технологической карте); Применяемость (количество деталей в вышестоящей детали); Применяемость на изделие (количество деталей в изделии с учетом количества деталей в иерархии).
Поскольку подсистема планирования может выбирать из одной группы взаимозаменяемости рабочих центров те рабочие центры, которые находятся в разных подразделениях, имеется необходимость учитывать тарифные сетки этих подразделений. Для того, чтобы связать тарифные сетки с подразделением, был добавлен регистр сведений «Виды тарифов подразделений». Это позволило связать подразделение с тарифной сеткой по значению в колонке «Вид тарифа». Проведено заполнение данных в колонке «Вид тарифа» в регистре сведений «Тарифная сетка» для получения соответствия с добавленным регистром.
Разработан алгоритм в виде последовательности действий программы по получению необходимого тарифа: сначала система определяет условие труда по подразделению рабочего центра в регистре сведений «Виды тарифов подразделений»; потом система узнает профессию по выполняемой операции через регистр сведений «Профессии технологических операций»; организация, НТС и разряд рабочего есть в МК; если определенные данные о профессии и виду тарифа отсутствуют в тарифной сетке, то вместо них используется пустое значение; по данным Организация, Подразделение, НТС, Разряд рабочего и Профессия находится нужный тариф в тарифной сетке.
По мере разработки элементов подмодуля диспетчеризации производилась их тестовая эксплуатация в производственных подразделениях ХОЛДИНГ ЛЕНПОЛИГРАФМАШ, а затем уже и введение в промышленную эксплуатацию. Внедрение проходило последовательно в организациях ХОЛДИНГ ЛЕНПОЛИГРАФМАШ, а именно в ООО «ЛПМ-Механика», ООО «ЛПМ-Система», ОАО «ЛЕНПОЛИГРАФМАШ», ООО «Полиграф Пласт», ООО «ЛПМ-Авангард». Сотрудникам соответствующих организаций был предоставлен доступ к программе на базе платформы 1С:Предприятие 8.3, в которой имелся разрабатываемый подмодуль диспетчирования. Изменения в подмодуле (проводимые как следствие выявления недочетов и ошибок в ходе процедуры тестирования) автоматически отражались у пользователей, поскольку каждый пользователь подключается к единой базе, расположенной на сервере обслуживающей организации.
Для удобного просмотра состава изделия конструкторами и перечня необходимых операций технологами ОАО «ЛЕНПОЛИГРАФМАШ» был разработан отчет по составу изделия с учетом имеющихся у сотрудников требований, в т.ч. возникших в ходе эксплуатирования системы РБМ. Остальные организации также имели возможность просматривать составы своих и заводских изделий, однако наиболее полезным отчет оказался именно для сотрудников ОАО «ЛЕНПОЛИГРАФМАШ». т.к. заводские изделия имеют сложную структуру и в большей степени требуют удобного отображе-
ния. В ходе тестирования были выявлены и устранены замечания, связанные с отбором по дате утверждения спецификации, а также с информированием об отсутствующих спецификациях, утвержденных на конкретную дату.
Поскольку на этапе внедрения подмодуля диспетчеризации планирование производства не было задействовано в программе, необходим был функционал формирования маршрутных карт производства непосредственно на этапе запуска изделий в производство (на этапе создания документа «Производственная программа»). Этот механизм был разработан таким образом, что маршрутные карты создаются на ту же дату, что и сама производственная программа. Для диспетчеризации была важна именно последовательность выполнения маршрутных карт и последовательность операций в каждой маршрутной карте, а также нормативное время и нормативная стоимость по нормативам и расценкам, введенным нормировщиками в системе PDM.
Кроме того, важным шагом была разработка механизма объединения маршрутных карт, благодаря чему на одну деталь в каждом запуске хранится одна маршрутная карта производства, что упрощает и ускоряет процесс нахождения обрабатываемой детали в ходе диспетчеризации. Апробация механизма формирования маршрутных карт и их объединения проводилась на заводских заказах ОАО «ЛЕНПОЛИГРАФМАШ». В ходе выполнения этого процесса был выявлен и устранен недочет, вызванный отсутствием информации о том, на какие конечные изделия направлено изготовление детали, указанной в маршрутной карте. Для этих целей была проведена доработке документа «Маршрутная карта производства»: в документ добавлен список заказов и изделий по этим заказам, на изготовление которых идет данная деталь (с указанием количества деталей).
Однако следует учесть, что сам вопрос диспетчеризации производства является более широким, нежели его изучение в части серийного машиностроительного производства. Это связано с тем, что для каждого вида производства свойственны присущие только ему особенности диспетчеризации. Например, планирование загрузки покрасочной камеры или печи могут быть схожи по своим параметрам, но кардинально отличаться от планирования единичного производства или непрерывного производства. Это дает нам основание для продолжения работы в области разработки и автоматизации алгоритмов диспетчеризации для различных видов промышленных производств.
ЛИТЕРАТУРА
1. Аркин П.А., Соловейчик К.А., Аркина К.Г. Исследование операций. СПб.: Изд-во Политехи, ун-та, 2016. 232 с.
2. Аркин П.А., Соловейчик К.А., Аркина К.Г. Методология оптимизационных подходов к процессам управления производством в машиностроении // Известия Санкт-Петербургского государственного экономического университета. 2017. № 1 (103), ч. 2. С. 69-77.
3. Аркин П.А., Соловейчик К.А., Аркина К.Г. Реализация методологии оптимизационных подходов при разработке алгоритма модуля диспетчирования производства на машиностроительном предприятии // Известия Санкт-Петербургского государственного экономического университета. 2017. № 2 (104). С. 94-100.
4. Аркин П.А., Соловейчик К.А., Аркина К.Г. Организационно-экономическое моделирование. СПб.: Изд-во Политехи. ун-та, 2016. 262 с.
5. Аркин П.А., Соловейчик К.А., Аркина К.Г. Оптимизация процессов управления наукоемкими производствами: нелинейное программирование. СПб.: Изд-во Политехи, ун-та, 2016. 213 с.
6. Организация конвертации данных и обмена данными с помощью конфигурации "Конвертация данных 2.0". [Электронный ресурс]. Режим доступа: http://its.lc.ra/db/metod8dev/content/2943/hdoc (дата обращения 13.05.2016).
7. Прилуцкий М.Х., Власов С.К Многостадийные задачи теории расписаний с альтернативными вариантами выполнения работ // Системы управления и информационные технологии. 2005. № 2 (19). С. 44-47.
8. Пщелинский А. С. Оптимизация межфирменных взаимодействий и внутрифирменных управленческих решений: диссертация на соискание ученой степени доктора экономических наук. М., 2002. 314 с.
9. Соловейчик К.А., Аркин П.А. Методические вопросы стимулирования роста глубины передела промышленной продукции субъектами Российской Федерации // Известия Санкт-Петербургского государственного экономического университета. 2015. № 4 (94). С. 25-30.
10. Kestner W., Blecker T., Hersatt С. Innovative Logistics Management. Schmidt Erich Verlag, 2008.
11. MonkKF., Wagner B.J. Concepts in enterprise resource planning. Boston: Thomson Course Technology, 2013.
12. Stadtler H., Kilger C. Supply Chain Management and Advanced Planning: Concepts, Models, Software and Case Studies. Berlin: Springer, 2008.
