Проблема комплексной автоматизации предприятий. Проблема интеграции информационных систем внутри предприятия. Интеграция ERP и MES, MES и SCADA
проблему комплексной автоматизации управления, т.е. построение комплексной информационной системы управления (КИС), включающей в себя системы «внутри предприятия» ERP, MES, SCADA. Системы ERP и MES интегрируются между собой, и, в свою очередь, системы MES и SCADA интегрируются между собой (SCADA является источником информации для MES). Также источником первичной информации для MES могут быть CAE (информация технологической подготовки производства: технологическая база знаний - PDM) и CAD/CAM (инженерная база знаний о конструкторской документации (КД) изготавливаемого изделия, - PDM, т.е. инженерная PDM - не для каждого производства). При этом, верхний управленческий уровень представлен технологией OLAP. Исходя из такого определения, общую формулу КИС «внутри предприятия» можно записать:
6. Конкурентные преимущества использования информационных систем предприятий. Что даёт внедрение подобных систем: упорядочивание и структуризация информации, стандартизация технологии работы предприятия, оперативный контроль и планирование бизнес-процессов, контроль за временем и качеством выполнения заказов, создание единого информационного пространства, организация эффективного взаимодействие с филиалами и региональными подразделениями
------------------------------ ------------------------------ ------------------------------
7. Архитектура КИС. Уровни архитектуры КИС (информационно-логический, прикладной, системный, аппаратный, транспортный). Двухзвенная, трехзвенная, распределённая архитектура, достоинства и недостатки.
Архитектура КИС состоит из нескольких уровней.
Информационно-логический уровень.
Представляет собой совокупность потоков данных и центров (узлов) возникновения, потребления и модификации информации. Может быть представлен в виде модели, на основании которой разрабатываются структуры баз данных, системные соглашения и организационные правила для обеспечения взаимодействия компонентов прикладного программного обеспечения.
Прикладной уровень.
Представляет собой совокупность прикладных программ и программных комплексов, которые реализуют функционирование информационно-логической модели. Это могут быть системы документооборота, системы контроля над исполнением заданий, системы сетевого планирования, АСУ ТП, САПР, бухгалтерские системы, офисные пакеты, системы управления финансами, кадрами, логистикой, и т.д. и т.п.
Системный уровень.
Операционные системы и сетевые средства.
Аппаратный.
Средства вычислительной техники.
Транспортный.
Активное и пассивное сетевое оборудование, сетевые протоколы и технологии.
Рисунок 3.3 - Распределенная архитектура системы
Более 95 % данных, используемых в управлении предприятием, могут быть размещены на одном персональном компьютере, обеспечив возможность его независимой работы.
А минимизация трафика между элементами сделает вполне доступной стоимость эксплуатации такой связи. Конечно, реализация такой системы не элементарна, и требует решения ряда проблем, одна из которых своевременная синхронизация данных.
Рисунок 3.2 - Трехуровневая клиент-серверная архитектура (Three-tier architecture)
Плюсы данной архитектуры очевидны. Благодаря концентрации бизнес-логики на сервере приложений, стало возможно подключать различные БД. Теперь, сервер базы данных освобожден от задач распараллеливания работы между различными пользователями, что существенно снижает его аппаратные требования.
Но, тем не менее, узким местом, как и в двухуровневой клиент-серверной архитектуре, остаются повышенные требования к пропускной способности сети, что в свою очередь накладывает жесткие ограничения на использование таких систем в сетях с неустойчивой связью и малой пропускной способностью (Internet, GPRS, мобильная связь).
Рисунок 3.1 - Двухуровневая клиент-серверная архитектура
При всей простоте построения такой архитектуры, она обладает множеством недостатков, наиболее существенные из которых - это высокие требования к сетевым ресурсам и пропускной способности сети компании, а также сложность обновления программного обеспечения из-за “размазанной” бизнес-логики между АРМом и сервером БД. Кроме того, при большом количестве АРМов возрастают требования к аппаратному обеспечению сервера БД, а это, как известно, самый дорогостоящий узел в любой информационной системе.
Основные задачи, решаемые информационными системами управления предприятием. Задачи решаемые на уровне руководства предприятия, финансово-бухгалтерских служб, служб управления производством, службы маркетинга, службы сбыта и снабжения, службы складского учета.
Основные задачи ИСУП
| Уровни и службы управления | Решаемые задачи |
| Руководство предприятия | обеспечение достоверной информацией о финансовом состоянии компании на текущий момент и подготовка прогноза на будущее; обеспечение контроля за работой служб предприятия; обеспечение четкой координации работ и ресурсов; предоставление оперативной информации о негативных тенденциях, их причинах и возможных мерах по исправлению ситуации; формирование полного представления о себестоимости конечного продукта (услуги) по компонентам затрат |
| Финансово-бухгалтерские | полный контроль за движением средств; реализация необходимой менеджменту учетной политики; оперативное определение дебиторской и кредиторской задолженностей; контроль за выполнением договоров, смет и планов; контроль за финансовой дисциплиной; отслеживание движения товарно-материальных потоков; оперативное получение полного набора документов финансовой отчетности |
| Управление производством | контроль за выполнением производственных заказов; контроль за состоянием производственных мощностей; контроль за технологической дисциплиной; ведение документов для сопровождения производственных заказов (заборные карты, маршрутные карты); оперативное определение фактической себестоимости производственных заказов |
| Службы маркетинга | контроль за продвижением новых товаров на рынок; анализ рынка сбыта с целью его расширения; ведение статистики продаж; информационная поддержка политики цен и скидок; использование базы стандартных писем для рассылки; контроль за выполнением поставок заказчику в нужные сроки при оптимизации затрат на транспортировку |
| Службы сбыта и снабжения | ведение баз данных товаров, продукции, услуг; планирование сроков поставки и затрат на транспортировку; оптимизация транспортных маршрутов и способов транспортировки; компьютерное ведение контрактов |
| Службы складского учета | управление многозвенной структурой складов; оперативный поиск товара (продукции) по складам; оптимальное размещение на складах с учетом условий хранения; управление поступлениями с учетом контроля качества; инвентаризация |
9. Классификация ИС предприятий. Классификация по уровню функциональности и интегрированности, по возможностям поддержки корпоративного управления, по степени реализации возможностей поддержки уровней управления (оперативного, тактического, стратегического).
Уровень функциональности ИС- Наиболее простые ИС - локальные, реализующие отдельные функции управления (бухгалтерский учет, логистика и т.д.). Такие ИС применяются в настоящее время в основном на малых предприятиях, однако они вытесняются многофункциональными и полнофункциональными ИС, т.е. системами, в которых реализованы либо большинство, либо практически все функции управления.
Опыт показывает, что полнофункциональная ИС не может работать эффективно, не будучи интегрированной.
Интегрированная информационная система (ИИС) основана на единой программно-аппаратной платформе и общей базе данных
Возможность поддержки управления сложными структурами -корпорациями.
К корпоративным можно отнести средние и крупные интегрированные системы Таким образом, оба этих класса систем следует рассматривать как интегрированные корпоративные информационные системы
Поддержка управления корпорацией на различных уровнях:
- оперативный уровень (системы обработки данных/транзакций (СОД)); - регистрация в базе данных и обработка элементарных событий, сопутствующих протеканию бизнес-процессов. Основная задача, стоящая перед ИС оперативного уровня, - обеспечить высокую скорость прохождения информационных потоков, связывающих участников бизнес-процессов.
- тактический уровень (информационные системы управления (ИСУ)); - процедуры среднесрочного (от нескольких дней до нескольких недель) планирования, анализа и организации работ. Если на оперативном уровне мы имеем дело с отдельным заказом и сопутствующими его выполнению транзакциями, то на тактическом уровне рассматриваются уже такие объекты, как, например, свод заказов для формирования производственной программы. Результаты решения подобных задач предназначены для менеджеров среднего звена
стратегический уровень (системы поддержки принятия решений (СППР)). - уровне рассматриваются вопросы выпуска и продвижения на рынок новой продукции, поиска новых рынков сбыта, выбора источников финансирования, привлечения инвесторов, инжиниринга и реинжиниринга бизнес-процессов.
10. Основные эксплуатационные требования к КИС. Требования: системности, комплексности, модульности, открытости, адаптивности, надежности, безопасности, масштабируемости, мобильности, простоты в изучении, поддержки внедрения и сопровождения со стороны разработчика.
Требования эти таковы:
· Системность;
· Комплексность;
· Модульность;
· Открытость;
· Адаптивность;
· Надежность;
· Безопасность;
· Масштабируемость;
· Мобильность;
· Простота в изучении;
Поддержка внедрения и сопровождения со стороны разработчика
Жизненный цикл КИС. Особенности этапов жизненного цикла КИС Жизненный цикл КИС включает следующие этапы проектирования:
1. Анализ
Обследование и создание моделей деятельности организации, анализ (моделей) существующих КИС, анализ моделей и формирование требований к КИС, разработка плана создания КИС.
2. Проектирование
Концептуальное проектирование, разработка архитектуры КИС, проектирование общей модели данных, формирование требований к приложениям.
3. Разработка
Разработка, прототипирование и тестирование приложений, разработка интеграционных тестов, разработка пользовательской документации.
4. Интеграция и тестирование
Интеграция и тестирование приложений в составе системы, оптимизация приложений и баз данных, подготовка эксплуатационной документации, тестирование системы.
5. Внедрение
Обучение пользователей, развертывание системы на месте эксплуатации, инсталляция баз данных, эксплуатация.
6. Сопровождение
Регистрация, диагностика и локализация ошибок, внесение изменений и тестирование, управление режимами работы КИС.
11. Классификация автоматизированных систем. По характеру объекта управления: АСУП, АСУТПП, АСУТП, АСОД, АСНИ. Функции выполняемые подобными системами.
· По характеру объекта управления АСУ делят на:
· АСУ предприятия (АСУП);
· АСУ технологическими процессами производства (АСУТПП);
· АСОУ (автоматизированная система организационного управления) - для управления коллективами людей в экономических и социальных системах.
· АСОД (автоматизированная система обработки документооборота);
· АСНИ – управление научными исследованиями.
АСУП (АС управления предприятием) применяется на уровне от предприятия до цеха, АСУТП (АС управления технологическими процессами)
Функции АСУП:
· календарное планирование производства, потребностей в мощностях и материалах;
· оперативное управление производством;
· сетевое планирование проектов;
· управление проектированием изделий;
· учет и нормирование трудозатрат;
· учет основных фондов;
· управление финансами;
· управление запасами (складским хозяйством);
· управление снабжением – статистика закупок, контракты на закупку;
· маркетинг (статистика и анализ реализации, контракты на реализацию, прогноз, реклама).
Процедуры, выполняющие эти функции – бизнес-функции.
Маршруты, состоящие из бизнес-функций - бизнес-процессы
Функции SCADA:
· сбор первичной информации от датчиков;
· хранение, обработка и визуализация данных;
· управление и регистрация аварийных сигналов;
· связь с корпоративной информационной сетью;
· автоматизация разработки прикладного ПО.
К разработке программ для PLC обычно привлекаются не профессиональные программисты, а заводские технологи. Поэтому языки программирования должны быть простыми, обычно построенными на визуальных изображениях ситуаций. Используются схемные языки.
12. Реинжиниринг бизнес-процессов. Цель, задачи и этапы реинжиниринга бизнес-процессов.
Целью реинжиниринга бизнес-процессов (РБП) является системная реструктуризация материальных, финансовых и информационных потоков, направленная на упрощение организационной структуры, перераспределение и минимизацию использования различных ресурсов, сокращение сроков реализации потребностей клиентов, повышение качества их обслуживания.
решение следующих задач:
· определение оптимальной последовательности выполняемых функций, которое приводит к сокращению длительности цикла изготовления и продажи товаров и услуг, обслуживания клиентов, следствием чего служат повышение оборачиваемости капитала и рост всех экономических показателей фирмы;
· оптимизация использования ресурсов в различных бизнес-процессах, в результате которой минимизируются издержки и обеспечивается оптимальное сочетание различных видов деятельности;
· построение адаптивных бизнес-процессов, нацеленных на быструю адаптацию к изменениям потребностей конечных потребителей продукции, производственных технологий, поведения конкурентов на рынке и, следовательно, повышение качества обслуживания клиентов в условиях динамичности внешней среды;
· определение рациональных схем взаимодействия с партнерами и клиентами и как следствие, рост прибыли, оптимизация финансовых потоков;
· синхронизация и координация одновременно выполняемых процессов.
Важнейшими принципами реинжиниринга бизнес-процессов являются следующие:
1. Несколько рабочих процедур объединяются в одну, происходит «горизонтальное сжатие процесса». В результате достигается многофункциональность рабочих мест.
2. Исполнители принимают самостоятельные решения, осуществляется «вертикальное сжатие процесса». Следствием является повышение ответственности, заинтересованности в результатах своего труда работника.
3. Шаги процесса выполняются в естественном порядке, обеспечивается «распараллеленность процесса». В этом случае работа выполняется в том месте, где это целесообразно.
4. Процесс имеет многовариантное исполнение, повышается адаптивность процесса к изменению внешней среды.
5. Уменьшается количество проверок, минимизируется количество согласований.
6. Менеджер процесса (case-manager) обеспечивает единую точку контакта с клиентом.
Преобладает смешанный централизованно-децентрализованный подход, в результате реализации которого происходит делегирование полномочий по принципу "сверху-вниз".
13. Жизненный цикл КИС. Особенности этапов жизненного цикла КИС. Жизненный цикл КИС. Особенности этапов жизненного цикла КИС Жизненный цикл КИС включает следующие этапы проектирования:
Анализ. Обследование и создание моделей деятельности организации, анализ (моделей) существующих КИС, анализ моделей и формирование требований к КИС, разработка плана создания КИС.
Проектирование.Концептуальное проектирование, разработка архитектуры КИС, проектирование общей модели данных, формирование требований к приложениям.
Разработка. Разработка, прототипирование и тестирование приложений, разработка интеграционных тестов, разработка пользовательской документации.
Интеграция и тестирование. Интеграция и тестирование приложений в составе системы, оптимизация приложений и баз данных, подготовка эксплуатационной документации, тестирование системы.
Внедрение.Обучение пользователей, развертывание системы на месте эксплуатации, инсталляция баз данных, эксплуатация.
Сопровождение. Регистрация, диагностика и локализация ошибок, внесение изменений и тестирование, управление режимами работы КИС.
14. Основные принципы реализации проекта внедрения КИС.Основные принципы реализации и этапы внедрения КИС.
o Эффективность внедрения должна оцениваться отдачей от инвестиций «возвратом стоимости вложений
o В ходе внедрения необходимо строго придерживаться утвержденных плана и графика, игнорируя возможность добавления в систему новых необязательных требований и возможностей, иначе реализация проекта внедрения корпоративных информационных систем затянется до бесконечности
o Бизнес-процессы предприятия-заказчика должны быть скрупулезно описаны и проанализированы перед внедрением, а не в процессе выполнения проекта.
o Внедрение должно выполняться по модульно и начинаться с модулей, которые способны достаточно быстро принести реальную отдачу.
o В процессе обследования предприятия должна быть внимательно проанализирована существующая программно-аппаратная платформа и определены пути ее интеграции (с внедряемой корпоративной информационной системой
o Успешное внедрение корпоративной информационной системы возможно только при тесной обратной связи с заказчиком и полной (реальной) поддержке группы внедрения руководством предприятия.
15. Организация выполнения проекта внедрения КИС. Типовая последовательность действий по выполнению проекта внедрения КИС.
Для эффективного управления проектом внедрения корпоративной информационной системы необходимо четко определить последовательность действий по его выполнению, имеющих конкретные цели, ограниченных во времени и допускающих независимые процедуры верификации.
В ее полномочия должны входить:
· принятие решений по утверждению корпоративных стандартов и их корректировки;
· принятие оперативных решений в ходе выполнения работ;
· оценка деятельности работы сотрудников, входящих в группу внедрения, и принятие управленческих решений по отношению к ним (поощрение и наказание).
Решения в ходе выполнения проекта внедрения корпоративной информационной системы должны приниматься оперативно, т. к. ожидание долгих согласований способно значительно затянуть проект. Специалисты предприятия, входящие в группу внедрения, обязательно должны пройти обучение. После обучения внедренческая группа разрабатывает детальный план проекта внедрения, в который включены такие вопросы, как обязанности участников проекта, сроки начала и окончания работ, а также другие, вытекающие из них, параллельно решаемые задачи. В рамках отдела АСУП должна быть создана группа поддержки проекта, задачей которой является поддержка функционирования корпоративных информационных систем как на этапе внедрения, так и в процессе ее последующей эксплуатации. В каждом подразделении должны быть выделены и подготовлены квалифицированные пользователи, обеспечивающие поддержку эксплуатации функциональных модулей КИС.
16. Причины неудачных внедрений КИС. Основные причины неудачных проектов внедрений КИС.
Основные причины неудачных внедрений корпоративных информационных систем заключаются в следующем:
· явная недооценка руководством и сотрудниками предприятия-заказчика (участвующимиво внедрении) сложности процесса внедрения КИС;
· слабая организация выполнения проекта внедрения корпоративных информационных систем и отсутствие реальной поддержки со стороны первых лиц предприятия;
· неготовность руководства заказчика (и самого предприятия, в целом) к конструктивным структурным изменениям и оптимизации процессов деятельности предприятия;
· включение в группу внедрения сотрудников исключительно службы АСУП, а не высококвалифицированных представителей автоматизируемых подразделений.
17. Развитие методологий проектирования систем управления предприятий от MRP к CSRP (ERPII). Эволюция стандартов от MRP к CSRP.
o в конце 40-х - начале 50-х годов в коммерческих организациях появились первые ЭВМ, практически никому не приходило в голову распределять обработку данных между различными машинами
o в начале 80-х персональных компьютеров позволило автоматизировать ведение учета и обработку данных даже небольшим компаниям, не имеющим высококвалифицированного управленческого и технического персонала.
o К концу 80-х годов идея создания единой модели данных в рамках целого предприятия заинтересовала ряд международных промышленных компаний, которые искали способ упростить управление производственными процессами. Первым шагом в данном направлении стала разработка концепции MRP
Основная цель концепции MRP заключалась в минимизации издержек, связанных со складскими запасами (в том числе и на различных участках производства). В основе этой концепции лежит понятие ВОМ (Bill Of Material - спецификация изделия, ответственность за которую возложена на конструкторский отдел), отражающее зависимость спроса на сырье, полуфабрикаты и другие продукты от плана выпуска готовой продукции.
У концепции MRP есть серьезный недостаток - что при расчете в рамках этой концепции потребности в материалах не учитываются ни имеющиеся производственные мощности, ни их загрузка, ни стоимость рабочей силы. Этот недостаток был исправлен в концепции MRPII (Manufacturing Resource Planning - планирование производственных ресурсов). MRPII позволяла учитывать и планировать все производственные ресурсы предприятия
По мере развития концепции MRPII к ней постепенно добавлялись возможности учета остальных затрат предприятия. Так появилась концепция ERP (Enterprise Resource Planning - планирование ресурсов предприятия), называемая иногда также планированием ресурсов в масштабе предприятия (Enterprise-wide Resource Planning). В основе ERP лежит принцип создания единого хранилища данных (репозитария), содержащего всю деловую информацию, накопленную организацией в процессе ведения бизнеса, в частности финансовую информацию, данные, связанные с производством, управлением персоналом, и любые другие данные. Наличие репозитария избавляет от необходимости передавать данные от приложения к приложению.
Самый новый из стандартов систем управления предприятиями - CSRP (Customer Synchronized Resource Planning) - помимо всего прочего охватывает и взаимодействие с клиентами, оформление нарядов/заказов и технических заданий, поддержка заказчика на местах и т.д.
Суть концепции CSRP главным образом состоит в том, чтобы интегрировать заказчика (клиента, покупателя) в систему управления предприятием. Согласно данной концепции не отдел сбыта, а непосредственно сам покупатель размещает заказ на изготовление продукции, сам отвечает за правильность его исполнения и при необходимости отслеживает соблюдение сроков производства и поставки. При этом само предприятие может очень четко отслеживать тенденции спроса на его продукцию.
18. Системы класса MRP. История развития систем MRP, назначение систем класса MRP, основные функции MRP систем.
История систем MRP
Как мы уже обсуждали, любая производственная компания борется за конкурентоспособность своих товаров на рынке.
Основными целями производственных компаний являются:
- снижение реальной себестоимости продукции;
- повышение производительности производства за счет эффективного планирования производственных мощностей и ресурсов.
С начала 60-х г.г., когда появилась возможность хранения и анализа больших объемов данных (время первых операционных систем и вычислительных комплексов для предприятий), стала развиваться отрасль разработки программного обеспечения для предприятий.
Задача планирования потребностей в материалах (Materials Requirements Planning, MRP) оказалась той первой задачей, которая привела к созданию целой индустрии программного обеспечения для управления предприятием.
Решение задачи планирования потребностей в материалах реализуется с помощью алгоритма, который также носит название MRP-алгоритма.
MRP-алгоритм – это алгоритм оптимального управления заказами на готовую продукцию, производством и запасами сырья и материалов.
MRP-методология – это реализация MRP-алгоритма с помощью компьютерной системы.
Реализация системы, работающей по этой методологии представляет собой компьютерную программу, позволяющую оптимально регулировать поставки комплектующих в производственный процесс, контролируя запасы на складе и саму технологию производства. Главной задачей MRP является обеспечение гарантии наличия необходимого количества требуемых материалов и комплектующих в любой момент времени в рамках срока планирования, наряду с возможным уменьшением постоянных запасов, а следовательно разгрузкой склада.
В настоящее время MRP системы присутствуют практически во всех интегрированных информационных системах управления предприятием.
Изначально MRP системы разрабатывались для использования на производственных предприятиях с дискретным[1] типом производства, например:
- сборка на заказ (Assembly-To-Order, ATO);
- изготовление на заказ (Make-To-Order, MTO);
- изготовление на склад (Make-To-Stock, MTS);
- серийное (RPT).
Если предприятие имеет процессное производство (Process Industry, Continuous-Batch Processing), то применение MRP-методологии оправдано в случае длительного производственного цикла.
«…MRP системы редко используются для планирования материальных потребностей в сервисных, транспортных, торговых и других организациях непроизводственного профиля, хотя потенциально идеи MRP-систем могут быть с некоторыми допущениями применены и для непроизводственных предприятий, деятельность которых требует планирования материалов в относительно длительном интервале времени…»
MRP системы базируются на планировании материалов для оптимальной организации производства и включают непосредственно функциональность MRP, функциональность по описанию и планированию загрузки производственных мощностей CRP (Capacity Resources Planning) и имеют своей целью создание оптимальных условий для реализации производственного плана выпуска продукции.
Структура MRP системы
Терминология:
1. Материалы - все сырье и отдельные комплектующие, составляющие конечный продукт. В дальнейшем мы не будем делать различий между понятиями "материал" и "комплектующий".
2. MRP-система, MRP-программа - компьютерная программа, работающая по MRP алгоритму.
3. Статус материала является основным указателем на текущее состояние материала. Каждый отдельный материал, в каждый момент времени, имеет статус в рамках MRP-системы, например:
– материал есть в наличии на складе;
– материал есть на складе, но зарезервирован для других целей;
– материал присутствует в текущих заказах;
– заказ на материал планируется.
Как видно, статус материала отражает степень готовности этого материала быть пущенным в производственный процесс.
4. Страховой запас (safety stock) материала необходим для поддержания процесса производства в случае возникновения непредвиденных и неустранимых задержек в его поставках. По сути, в идеальном случае, если механизм поставок полагать безупречным, MRP-методология не постулирует обязательное наличие страхового запаса, и его объемы устанавливаются различными для каждого конкретного случая, в зависимости от сложившейся ситуации с поступлением материалов. Подробней об этом будет рассказано ниже.
5. Потребность в материале в MRP-программе представляет собой определенную количественную единицу, отображающую возникшую в некоторой момент времени в течение периода планирования необходимость в заказе данного материала.
Различают понятия полной потребности в материале, которая отображает то количество, которое требуется пустить в производство, и чистой потребности, при вычислении которой учитывается наличие всех страховых и зарезервированных запасов данного материала. Заказ в системе автоматически создается по возникновению отличной от нуля чистой потребности.
Формула вычисления чистой потребности такова:
Чистая потребность = полная потребность – инвентаризовано на руках – страховой запас – зарезервировано для других заказов