Главная » Публикации » Автоматизация предприятий » Принципы построения информационной системы управления производственным предприятием

 

Принципы построения информационной системы управления производственным предприятием


Многие руководители и менеджеры предприятий пытаются подобрать себе такой программный продукт, который позволил бы им с наименьшими трудозатратами перейти от учёта деятельности к управлению предприятием. На рынке в настоящий момент представлен большой спектр продуктов для построения системы управления производственным предприятием – от простых учётных до сложных систем класса ERP. Все эти системы имеют свои особенности, свою бизнес-логику. Тем не менее для успешного внедрения информационной системы на базе выбранного программного продукта необходимо, чтобы логика, заложенная в программный продукт, соответствовала основным бизнес-процессам на предприятии, особенно в части оперативного учета и планирования.

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

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

* оперативность учета – бухгалтерский учет ведется, как правило, с задержкой на 5 - 20 дней, в то время как для принятия управленческих решений часто надо обладать информацией в режиме реального времени;

* глубина учёта – для управленческого учета свойственна более глубокая детализация, чем для бухгалтерского. В качестве примера можно привести контроль материальных потоков. Для управленческих целей зачастую необходимо отслеживать полный маршрут движения ТМЦ, вплоть до наличия их на отдельных производственных участках. Для бухгалтерского учёта такая детализация является совершенно излишней.

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


Рис. 1

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

 

Оперативный учет

Бухгалтерский учет

Подразделения


Оперативные подразделения

произвольная детализация:

цех;

цеховая кладовая;

производственный участок

Центры затрат (аналитика на счетах)

Объекты производственной аналитики


Объекты производственного учета

произвольная детализация:

номенклатура;

заказ;

заказ + номенклатура

Объекты производственных затрат (аналитика на счетах)

Статьи затрат


Статьи нормирования

Статьи затрат (аналитика на счетах)


 

 

 

 

 

 

 

 

Таблица 1. Объекты учета для разных подсистем

Разделение подсистем на уровне объектов учета и документов позволяет упростить документооборот, сделать отдельные документы более понятными и удобными в работе, избежать противоречий при настройке системы прав, увеличить производительность системы.

Наряду с разделением оперативного и бухгалтерского учета при разработке программного продукта необходимо иметь в виду требования, касающиеся соответствия идеологии системы типовым процессам управления производственным предприятием, а также поддержку непрерывного цикла управления, начиная от планирования продаж и заканчивая отгрузкой продукции покупателю. Укрупнено такая замкнутая цепочка управления представлена на рис. 2.


Рис. 2

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

Нормативная подсистема

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

Для реализации этих потребностей в системе должны быть предусмотрены специальные возможности. Одной из них является механизм использования дополнительных характеристик номенклатуры. В качестве таковых могут быть указаны любые свойства материала или продукции (срок годности, цвет, серия, плотность, размер и т. д.). Весь учет по местам хранения материалов или продукции будет в этом случае вестись в разрезе дополнительных характеристик. Их использование позволяет, таким образом, уменьшить количество номенклатурных позиций, а также всегда иметь информацию о наличии и движении ТМЦ в разрезе указанных свойств.

Состав изделия описывается с помощью механизма спецификаций. Каждая спецификация включает в себя:

* материальный состав (материалы и полуфабрикаты) изделия;

* побочную продукцию и возвратные отходы;

* технологические операции;

* оборудование;

* человеческие ресурсы;

* прочие ресурсы;

* прочие затраты.

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

Подсистема оперативного управления

Такая подсистема должна позволять:

* отслеживать и контролировать материальные потоки на складах и в производстве;

* планировать выпуск товарной продукции и формировать производственные планы;

* рассчитывать потребность в материальных и прочих ресурсах, необходимых для выполнения планов;

* следить за состоянием производства, контролировать выполнение производственных заказов и выпуск продукции.

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

Как правило, при организации оперативного учёта необходимо вести его в разрезе мест хранения, номенклатуры (с учетом дополнительных характеристик) и производственных заказов. Для более сложных случаев в качестве объекта учёта можно использовать сочетание заказа и номенклатуры, которое позволяет организовать детальный контроль исполнения заказов.

Можно привести несколько случаев, когда целесообразно использовать сочетание заказа и номенклатуры в качестве объекта производственного учета. Во-первых, это удобно, если в рамках одного производственного заказа изготавливается несколько видов конечной продукции. Описывая в качестве объекта учета сочетание заказа и продукции, можно вести дополнительный контроль движения материальных потоков в разрезе частей заказа. Во-вторых, комбинированные объекты производственного учёта могут быть использованы для контроля прохождения изготавливаемого изделия по узлам, что особенно важно для сложного сборочного производства с разветвленным технологическим маршрутом. В этом случае сотрудники ПДО или начальники производства смогут контролировать исполнение плана не только по выпущенной продукции, но и по ТМЦ, находящимся в производстве, отслеживать формирование комплектов для передачи на сборку, а также резервировать ТМЦ в местах хранения под объекты производственного учета.

Рассмотрим документооборот, отражающий движение материальных потоков. Наиболее просто можно построить его на трёх основных электронных документах:

* приходном ордере (ПО), отражающем факт прихода ТМЦ в место хранения;

* расходном ордере (РО), отражающем факт отпуска ТМЦ из места хранения;

* производственном отчете, позволяющем связать выпущенную продукцию и полуфабрикаты с израсходованными материалами.

Укрупненная схема движения основных документов подсистемы оперативного учета представлена на (рис. 3):


Рис. 3

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

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

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

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


Рис. 4

Отдельно отметим, что перечисленные выше документы должны позволять перемещать материальные потоки не только по подразделениям оперативной подсистемы, но и по объектам производственного учета. Изменение объекта производственного учета, для целей которого перемещаются материальные ценности, может либо происходить одновременно с движением по местам хранения, либо выполняться отдельной операцией. Для более строгой организации документооборота могут также использоваться дополнительные документы: «Заявка на отпуск ТМЦ со склада» и «Изменение объекта производственного учета». Это позволяет более четко проконтролировать причины движения ТМЦ.

Подсистема планирования

Остановимся более детально на подсистеме планирования и заложенных в нее алгоритмах. Можно выделить два вида планирования: одно касается товарной продукции, а другое - производства. Планирование товарной продукции – это среднесрочное планирование выпуска готовой продукции или продаж. Товарные планы могут создаваться в соответствии с информацией о продажах, планах или объемах производства продукции прошлых периодов, а также на основании заявок покупателей на выпуск продукции. Товарные планы формируются на определенный период – от года до месяца, с возможностью автоматической детализации планов (например, на основании годового плана могут быть автоматически составлены полугодовые, квартальные или месячные планы). Кроме того, система должна позволять контролировать сходимость вложенных планов и производить план-факт анализ на основании информации о произведенной продукции.

Производственное планирование – это планирование производственных заданий. Производственное планирование является более детальным, чем товарное, и позволяет планировать производство с учетом характеристик и спецификаций выпускаемой продукции. Производственные планы могут быть сводными – в этом случае они отражают выпуск готовой продукции, и цеховыми - позволяющими планировать выпуск отдельных узлов и полуфабрикатов, необходимых для изготовления готовой продукции, в разрезе подразделений. Производственные планы составляются на произвольные периоды. В зависимости от типа и особенностей производства соответствующее планирование может использоваться при формировании производственных запусков, производственных программ или заказов. Производственные планы могут быть составлены на основании заявок покупателей или заказов, а также товарных планов. Кроме того, цеховые планы можно формировать на основании сводных производственных планов. Бизнес-логика процесса планирования показана на рис. 5.


Рис. 5

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

* первичное планирование;

* корректировка планов;

* уточненное планирование.

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

Формирование данных бухгалтерской подсистемы

Несмотря на относительную независимость подсистем оперативного и бухгалтерского учёта, в большинстве случаев они основываются на одних и тех же первичных операциях и данных. Для уменьшения трудозатрат на ввод информации и исключения двойного ввода в программе должна быть предусмотрена возможность ввода бухгалтерских документов на основании оперативных. Документы формируются специальными процедурами и позволяют свернуть оперативные документы, основываясь на описанных связях объектов учёта. При формировании документов оперативные документы будут попадать в бухгалтерский учёт только в том случае, если в процессе операций изменяются объекты бухгалтерского учёта – подразделения или объекты производственных затрат. В качестве примера можно привести простейший случай, когда с точки зрения оперативного учета подразделения детализированы с точностью до производственных участков и цеховой кладовой при них, а в бухгалтерской подсистеме все эти подразделения являются единым цехом. В этом случае, перемещения ТМЦ между участками, а также участками и цеховой кладовой не попадут в бухгалтерский учет – там будут отражены только агрегированные данные о приходе ТМЦ в подотчет цеху и отпуске ТМЦ из цеховой кладовой. Пример формирования бухгалтерских документов на основании оперативных представлен на (рис. 6).


Рис. 6

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

Особенности программного продукта «Производственное предприятие: управление и учёт»

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

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

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


Публикации

Проблемы компьютерных информационных систем промышленных предприятий и пути их решения

НПФ "Авиамотор"

Введение

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

Состояние вопроса

Сегодня, наверное, уже не осталось промышленных предприятий, которые не используют в своей деятельности CAD/CAM/CAE систем [1]. Концентрация у конструкторов, технологов мощных систем поддержки принятия инженерных решений в значительной мере улучшает качество выполнения отдельных этапов технической подготовки производства разрабатываемого изделия. Но предполагаемый многими руководителями и разработчиками экономический эффект, на который рассчитывали при внедрении, не соответствует ожиданиям. На приобретение компьютеров, сетевого оборудования, программного обеспечения, на обучение персонала и т.п. направлены большие финансовые средства. Покрытие этих расходов должно было произойти за счет улучшения качества выполнения проектных работ, сокращения сроков их выполнения, что в свою очередь должно привести к сокращению издержек производства и снижению себестоимости продукции. Такие тенденции прослеживаются, но заметных успехов пока нет. Поэтому большинство машиностроительных предприятий уже приходит к осознанию того, что им необходим не просто набор программного обеспечения, решающего те или иные производственные задачи. Необходима система программ, позволяющая работать в едином информационном пространстве для упрощения процедур ввода и передачи информации между подразделениями [2]. Сегодня на рынке программного обеспечения предлагается большое количество систем, которые, по мнению разработчиков, позволяют удовлетворить любые требования пользователей. Казалось бы, есть все основания для бурного развития и внедрения информационных систем на предприятиях. Но те системы, которые удалось освоить предприятиям, зачастую не решают и половины конкретных производственных задач.

Рассмотрим причины сложившейся ситуации. На всех машиностроительных предприятиях сегодня эксплуатируется большое количество различных систем "Поддержки принятия решения", что вызвано многообразием решаемых задач. Отсюда следует, что любое подразделение предприятия требует индивидуального подхода к решению собственных задач со стороны разработчиков программного обеспечения. Но с другой стороны, разработчики программного обеспечения не могут ориентироваться на одно подразделение конкретного предприятия. Их задача заключается в том, чтобы охватить как можно больший сегмент рынка. Поэтому, они анализируют деятельность однотипных подразделений многих предприятий и выявляют общие требования к проектируемой системе. Сегодня уже существует достаточно большое количество таких систем и модулей с различной степенью специализации. К ним можно отнести все известные на сегодня CAD/CAM/CAE - системы, системы бухгалтерского и складского учета. Однако парадокс разработчика заключается в том, что чем больший опыт различных предприятий обобщит разработчик, тем меньше программное обеспечение будет удовлетворять всем требованиям каждого конечного пользователя.

Теперь несколько слов о состоянии разработки информационных систем [3]. Во-первых, хочется отметить, что почти все информационные системы предприятий, предлагаемые сегодня на рынке программного обеспечения, берут свое начало с систем "Поддержки принятия решений" по каким-то конкретным проблемам. Так, очень часто, системы бухгалтерского учета увеличивая свои функциональные возможности, предлагаются как информационные системы предприятия. CAD системы перерастают в PDM (Product Data Management) - системы управления данными. Расширяя свои функциональные возможности, эти системы остаются ограниченными возможностями ядра (первоначальной системой принятия решения). Эти ограничения не позволяют развиваться системе и удовлетворять возрастающие требования пользователя.

Во-вторых, со стороны пользователей возникает требование интеграции всех систем "Поддержки принятия решения", действующих на предприятии, в единую информационную систему. Однако, в силу специфики каждого подразделения предприятия, эти системы имеют свои функциональные и индивидуальные особенности, которые не позволяют им непосредственно интегрироваться в информационную систему предприятия, поскольку эта процедура регламентируется очень жесткими требованиями и ограничениями. Как правило, все программные продукты, разрабатываемые независимо, без учета принципиальных требований информационной системы верхнего уровня, не могут быть интегрированы в эту систему. Если при разработке не учтены обязательные ограничения, требования информационной системы к своим модулям, то разработанный программный продукт не сможет стать частью этой системы. Исходя из приведенного анализа, можно сделать следующие заключения:

* любые компьютерные системы "Поддержки принятия решений" путем простого объединения при помощи интерфейсов не смогут образовать информационную систему;

* невозможно развитие любой системы принятия решений до рамок информационной системы предприятия в силу ограничений ядра;

* пользователи в любой информационной системе хотят видеть решение своих конкретных задач.

Цели и задачи

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