3.9. Моделирование бизнес-процессов
Проект внедрения АСУП (система ERP) состоит из трех этапов:
бизнес-моделирование деятельности предприятия для выработки планов развития предприятия и его корпоративной информационной системы;
пилотное тестирование и разработка прототипа будущей системы (результатом данного этапа является настройка АСУП на специфику предприятия и выход на опытную эксплуатацию);
развертывание АСУП и выход на промышленную эксплуатацию системы.
Моделирование бизнес-процессов (бизнес-моделирование) сводится к формализованному и понятному всем заинтересованным сторонам описанию процессов предприятия и их взаимодействия через материальные, финансовые и информационные потоки. При создании бизнес-модели формируется понятийный аппарат консультантов, разработчиков, пользователей и руководителей предприятия, позволяющий выработать единое представление о том, что и как должна делать АСУП.
Необходимость трехуровневого моделирования обосновывается наличием трех взаимосвязанных видов деятельности на предприятии:
Вид А - это выполнение бизнес-процессов, реализующих основные задачи предприятия (производство и реализация изделий или оказание услуг). Описание деятельности вида А именуется физической моделью. Средствами выполнения бизнес-процессов являются АСУП и система менеджмента качества (СМК).
Вид В является логическим моделированием, направленным на улучшение деятельности вида А. Логическое моделирование заключается в анализе и проектировании бизнес-процессов предприятия. Логическое моделирование подразумевает наличие описания текущих и желаемых бизнес-процессов предприятия. Основными средствами логического моделирования являются методики, основанные на языке UML и спецификации IDEF1X. Предприятие, осуществляя реорганизацию бизнес-процессов, не получит устойчивого эффекта, если не будет опираться на информационную поддержку. Таким образом, АСУП должна развивать физическую модель предприятия в соответствии с выбранным курсом развития.
Вид С является концептуальным моделированием, направленным на улучшение деятельности вида В, что подразумевает постоянное отслеживание передового опыта, заключенного в мировых стандартах управления (ERP, CALS, ИСО 9001:2000 и т.п.). Деятельность вида С обычно реализуется на основе разработки функциональных моделей IDEF0.
Наряду с моделями UML и IDEF0, для моделирования бизнес-процессов предприятия находит применение ряд других графических средств моделирования. Это диаграммы цепей стоимости (VCD - Value Chain Diagram), управляемая событиями цепь процессов (EPC - Event-driven Process Chain), диаграммы описания потоков (PFDD - Process Flow Description Diagrams).
VCD представляет собой диаграмму укрупненной последовательности функций, используемых для получения добавленной стоимости продукта, в то время как EPC предназначена для детального моделирования процессов. Диаграммы EPC похожи на диаграммы состояний или диаграммы деятельности UML, но дополняются столбцами, в которых отображаются участвующие в операциях организационные единицы, источники данных и программное обеспечение. PFDD напоминают известные диаграммы потоков данных.
Переход от логической модели к физической может осуществляться с помощью систем Rational Rose и ERwin. При этом классы логической модели преобразуются в сущности реляционной модели IDEF1X и формируется описание структуры базы данных.
Средство моделирования Rational Rose совместно с генератором отчетов Rational SoDА позволяет формировать из логической модели отчеты по заранее описанному шаблону документа с соблюдением бизнес-логики предприятия. Средствами Rational Rose может генерироваться программный код для клиентской части АСУП предприятия.
На третьем этапе внедрения АСУП выполняется нормативное моделирование. Под нормативным моделированием понимается определение временных и стоимостных характеристик процессов предприятия (т.е. их нормирование). На уровне нормативного моделирования разрабатываются нормативы предприятия. Соблюдение нормативов реализуется в рамках нормативного управления предприятием.
Базовые данные для нормативного управления разбиваются на три группы:
данные по производственно-организационной структуре предприятия (оргструктура, территориальная структура и топология предприятия, учетная политика по движению материалов и расчету текущей стоимости запасов);
данные по контрагентам (информация о поставщиках и потребителях, сроках и графиках поставки, прайс-листы поставщиков);
данные по изделиям, полуфабрикатам и материалам (кодификация номенклатуры, спецификация изделий, технологические карты изготовления, параметры планирования, стоимостные характеристики, характеристики контроля запасов).
При внедрении решаются задачи тестирования модели нормативного управления. Тестирование включает процедуры:
перенесение данных по производственно-организационной структуре предприятия и по контрагентам из логической модели в базу данных АСУП;
подготовка исходных данных для проектирования кодификации номенклатуры предприятии;
расчет оптимального размера заказа для всех комплектующих;
моделирование (т.е. проигрывание на реальных данных) поведения системы управления запасами с различными видами политик заказов (с фиксированным размером заказа, с фиксированным интервалом времени между заказами и т.д.);
моделирование возможности появления сбоев в поставках запасов (для расчета нормативов страховых запасов и оценки устойчивости системы к выходу в дефицитное состояние) для случаев: отсутствия задержек поставок, наличие единичных сбоев в поставках, наличие многократных сбоев в поставках;
моделирование возможности появления сбоев в потреблении запасов предприятием (разработка рекомендаций для управления запасами ).
3.10. PDM -управление проектными данными
Системы автоматизированного проектирования относятся к числу наиболее сложных и наукоемких автоматизированных систем. Наряду с выполнением собственно проектных процедур необходимо автоматизировать также управление проектированием, поскольку сам процесс проектирования становится все более сложным и зачастую приобретает распределенный характер. На крупных и средних предприятиях заметна тенденция к интеграции САПР с АСУП и системами документооборота. Для управления столь сложными интегрированными системами в их составе имеется специальное программное обеспечение - системная среда САПР или АС, называемая в настоящее время системой управления проектными данными или системой PDM (Product Data management). Системы более общего характера, связанные с управлением данными на всех этапах жизненного цикла изделий и интеграцией различных промышленных автоматизированных систем, получили название систем управления жизненным циклом изделий или систем информационной поддержки изделий PLM (Product Lifecycle Management).
История систем управления проектными данными непосредственно связана с развитием систем автоматизированного проектирования. Появление системных сред в САПР ознаменовало переход от использования отдельных не связанных друг с другом программ, решающих частные проектные задачи, к применению интегрированной совокупности таких программ.
Интегрирующим компонентом в 70-е г.г. стала единая БД САПР. Однако попытки использовать имевшиеся в то время СУБД не приводили к удовлетворительным результатам в силу разнообразия типов проектных данных, распределенного и параллельного характера процессов проектирования, с одной стороны, и недостаточной развитости баз данных, с другой стороны.
Специализированные СУБД, ориентированные на САПР, были созданы в 80-е годы. Однако они не учитывали или в недостаточной степени удовлетворяли требованиям обеспечения целостности данных, управления потоками проектных работ, многоаспектного доступа пользователей к данным. И лишь на рубеже 80-90 г.г. появились системы управления проектными данными, названные в то время Framework или системными средами, сначала в САПР электронной промышленности, а позднее и в САПР машиностроения, где они и получили наименование PDM. На протяжении 90-х годов роль системных сред неуклонно повышалась. Во-первых, из-за роста сложности проектируемых объектов и необходимости сокращать сроки проектирования. Во-вторых, из-за необходимости интеграции систем проектирования с системами управления предприятием и технологическими процессами. Благодаря развитию Интернет, Web и CALS-технологий такая интеграция стала возможной в глобальном масштабе.
Современные системы управления проектными данными называют PDM. Они предназначены для информационного обеспечения проектирования и выполняют следующие основные функции:
хранение проектных данных и доступ к ним, в том числе ведение распределенных архивов документов, их поиск, редактирование, маршрутизация, создание спецификаций;
поиск, структурирование и визуализация данных;
управление конфигурацией изделия, т.е. ведение версий проекта, управление внесением изменений;
управление проектированием (проектами), обеспечение совместной работы разработчиков над проектом;
защита информации;
интеграция данных (поддержка типовых форматов, конвертирование данных).
Основной компонент систем PDM - банк данных (БнД). Он состоит из системы управления базами данных и самих баз данных (БД). Межпрограммный интерфейс в значительной мере реализуется через информационный обмен с помощью банка данных. PDM отличает легкость доступа к иерархически организованным данным, обслуживание запросов, выдача ответов не только в текстовой, но и в графической форме, привязанной к конструкции изделия. Поскольку взаимодействие внутри группы проектировщиков в основном осуществляется через обмен данными, то в системе PDM часто совмещают функции управления данными и управления параллельным проектированием. К важнейшим функциям PDM относятся управление проектами и управление конфигураций изделий.
В информационных моделях приложений фигурируют сущности (типы данных) и связи между ними. Установление сущностей, их атрибутов, связей и атрибутов связей означает структурирование проектных данных. Структура изделий обычно может быть представлена иерархически, в виде дерева. Иерархическая форма удобна при внесении и отслеживании изменений в модели, например, при добавлении и удалении сущностей, изменениях их атрибутов, введении новых связей. Поэтому одной из первоочередных функций PDM является поддержка интерактивной работы пользователя при создании моделей изделий (процессов), структурирование описаний проектируемых объектов, предъявление пользователю этой иерархической структуры вместе с возможностями навигации по дереву и получению нужной информации по каждой указанной пользователем структурной компоненте. Например, в системе PDM STEP Suite элементы дерева, представляющего структуру изделия, могут соответствовать сборочным узлам, агрегатам, блокам, отдельным деталям. Навигация по дереву позволяет просматривать относящиеся к структурным единицам документы, геометрические модели, чертежи и другие атрибуты.
В системе PDM, разработанной в свое время фирмой Cadence для своей САПР, была предусмотрена иерархическая организация проектных данных, описывающих проектируемые СБИС (сверхбольшие интегральные схемы), с выделением уровней библиотек, категорий, ячеек, видов. Ячейка - базовый объект, который может иметь несколько различных представлений (видов). Ячейки объединяются в родственные группы - категории, а категории - в библиотеки. Разработчик с помощью системной среды имел доступ к проектным данным, мог создавать свои библиотеки, ячейки, виды. Интерфейс с пользователем поддерживается визуализацией данных проекта одновременно в нескольких окнах. Для визуализации данных разных аспектов в PDM имеется ряд браузеров. Типичные изображения структуры изделия, создаваемые браузерами, представляются иерархическим списком или графически в виде дерева изделия или его фрагментов. В других окнах могут быть помещены различные виды, такие как 2D чертеж или 3D изображение; описания моделей; принципиальные схемы; атрибуты объекта (исполнитель, номер версии, дата утверждения и т.п.). Иногда для визуализации и редактирования данных в PDM конкретной фирмы привлекаются браузеры и редакторы других изготовителей. Для примера на рис.8 показан небольшой фрагмент дерева изделия. Обычно на экране дисплея рядом с названием компонента структуры высвечивается также присвоенный ему код. Выбор любого компонента (узла дерева) позволяет, во-первых, получить в появляющихся окнах требуемую информацию о компоненте, во-вторых, для компонента, являющегося сборкой, раскрыть следующий по иерархии фрагмент, в котором данный компонент будет представлен уже корневым узлом.
Рис. 8. Фрагмент дерева изделия
Целостность данных поддерживается в процессе управления конфигурацией проекта, а также тем, что нельзя одновременно изменять один и тот же объект разным разработчикам, каждый из них должен работать со своей рабочей версией. Другими словами, необходимо обеспечение синхронизации изменения данных, разделяемых многими пользователями.
Для этого выполняется авторизация пользователей и разрабатываются средства ведения многих версий проекта. Во-первых, пользователи подразделяются на классы (администрация системы, руководство проектом и частями проекта, группы исполнителей-проектировщиков) и для каждого класса вводят определенные ограничения, связанные с доступом к разделяемым данным; во-вторых, доступ регламентируется по типам разделяемых данных. Данным могут присваиваться различные значения статуса, например: «правильно»; «необходимо перевычисление»; «утверждено в качестве окончательного решения» и т.п.
Например, каждому пользователю в зависимости от его роли назначается уровень прав доступа. На низшем уровне пользователь может только просматривать данные. На высшем уровне, присваиваемом старшему администратору, допускаются любые модификации данных любого проекта и архивов. В функции лица, являющегося системным администратором, входят упорядочение данных с их распределением по дискам, контроль за правами доступа пользователей, связь с внешними системами (управление импортом-экспортом данных) и др.
Типичная схема разделения рабочего пространства между параллельно работающими пользователями показана на рис. 9.
Рис. 9. Информационные связи разработчиков с зонами базы данных
Следующими важными функциями PDM являются управление документами и документооборотом. Проектная документация характеризуется разноплановостью и большими объемами. В процессе проектирования используют чертежи, конструкторские спецификации, пояснительные записки, ведомости применяемости изделий, различного рода отчеты и др. Кроме того, в интегрированных автоматизированных системах проектирования и управления в документооборот входит большое число документов, связанных с процедурами маркетинга, снабжения, планирования, администрирования и т.п.
Важно обеспечить автоматический учет влияния и распространения вносимых в проект изменений на другие части проектной документации. Для подготовки, хранения и сопровождения необходимых документов, в том числе чертежей и схем, в PDM включают специализированные системы управления документами и системы управления документооборотом или адаптируют полнофункциональные системы делопроизводства, разработанные независимо от конкретных PDM. Следует отметить, что параллельное проектирование (совмещенное проектирование), интеграция автоматизированных систем проектирования и управления на современных предприятиях возможны только в распределенной среде. Распределенные хранение и обработка информации в большинстве случаев осуществляются на базе применения технологий SOAP, CORBA или DCOM, языков Java и XML. Данные проекта при этом находятся в хранилищах данных, т.е. в нескольких базах распределенного банка данных. Находят применение трехзвенные распределенные системы с уровнями сервер баз данных - сервер приложений - клиенты. Принимаются меры по защите информации, типичные для корпоративных информационных систем. Разработаны рекомендации по внедрению операций с электронными цифровыми подписями.
Интеграция данных на ранних этапах развития PDM связывалась только с организацией сквозного проектирования изделий в рамках конкретной САПР. В настоящее время в связи с развитием CALS-технологий основным содержанием проблемы интеграции стало обеспечение интерфейса САПР с другими автоматизированными системами. Проблема решается с помощью поддержки типовых форматов, например, путем конвертирования данных из общепринятых форматов во внутренние представления конкретных САПР.
В CALS-технологиях взаимодействие систем основано на стандартах STEP, поэтому в ряде PDM имеются конверторы из предложенного в STEP языка Express.
Адаптация САПР к условиям конкретных предприятий может быть осуществлена с помощью языков расширения. Язык расширения - язык программирования, позволяющий адаптировать и настраивать системную среду на выполнение новых проектов. Язык расширения должен обеспечивать доступ к различным компонентам системной среды, объединять возможности базового языка программирования и командного языка, включать средства процедурного программирования. Для большинства языков расширения базовыми являются Lisp или C.
3.11. SCM-системы
SCM (Supply Chain Management) - управление цепочками поставок. Системы SCM предназначены для автоматизации и управления всеми этапами снабжения предприятия и для контроля всего товародвижения на предприятии. Система SCM позволяет значительно лучше удовлетворить спрос на продукцию компании и значительно снизить затраты на логистику и закупки. SCM охватывает весь цикл закупки сырья, производства и распространения товара. Исследователи, как правило, выделяют шесть основных областей, на которых сосредоточено управление цепочками поставок: производство, поставки, месторасположение, запасы, транспортировка и информация. В составе SCM-системы можно условно выделить две подсистемы:
SCP - (Supply Chain Planning) - планирование цепочек поставок. Основу SCP составляют системы для расширенного планирования и формирования календарных графиков. В SCP также входят системы для совместной разработки прогнозов. Помимо решения задач оперативного управления, SCP-системы позволяют осуществлять стратегическое планирование структуры цепочки поставок: разрабатывать планы сети поставок, моделировать различные ситуации, оценивать уровень выполнения операций, сравнивать плановые и текущие показатели.
SCE - (Supply Chain Execution) - исполнение цепочек поставок в режиме реального времени. Смотри также DRP (Distribution Resources Planning) (wikipedia.org)
Функции SCM систем. По мере развития соответствующего программного обеспечения и его интеграции с ERP-продуктами корпоративные системы управления стали выходить за традиционные рамки автоматизации операций внутри предприятия. Появились и новые термины: обычный контур управления (продажи-производство-закупки) стали называть back-office (внутренней системой), а функции взаимодействия с контрагентами и заказчиками - front-office (внешней системой). Но, поскольку предприятиям в условиях современной конкуренции вместо простого реагирования на спрос необходимо направить все усилия на удовлетворение потребностей клиентов, без формирования внешней цепочки уже не обойтись. В результате, в совокупности с внутренней цепочкой образуется интегрированная цепочка поставок, звеньями которой служат все объекты, материальные и информационные потоки, взаимосвязи предприятия, его поставщиков, дистрибьюторов и клиентов, вплоть до конечного потребителя. В каждом звене этой сложной цепи неизбежны потери времени, ресурсов, денег. Но если все операции, необходимые для поставки изделия клиенту, рассматривать как звенья единого бизнес-процесса и управлять ими с этой позиции, то можно достичь существенного снижения издержек, уменьшения объема незавершенного производства и увеличения доходности сбыта.
SCM-решения создают оптимальные планы использования существующих технологических линий, подробно расписывающие, что, когда и в какой последовательности надо изготавливать с учетом ограничений мощностей, сырья и материалов, размеров партий и необходимости переналадки оборудования на выпуск нового продукта. Это помогает добиться высокого удовлетворения спроса при минимальных затратах. В SCM-системах нового поколения поддерживаются технологии отслеживания статуса товара (детализированные до уровня ассортиментной единицы и даже отдельной упаковки) на любом этапе прохождения его по цепочке поставок. В тех отраслях, в которых 40-60% затрат приходится на закупки, оптимизация бизнес-процессов такого рода обеспечивает конкурентное преимущество и определяет прибыльность бизнеса в целом. SCM-модули оптимизации закупок помогают реализовать стратегию поиска поставщиков на основе анализа затрат.
Внедрение SCM-решений по управлению логистикой и ее оптимизации позволяет снизить расходы на хранение, транспортировку и дистрибуцию продукции. Уже сейчас многие отечественные производители и дистрибьюторы столкнулись с усиливающейся конкуренцией со стороны вторгающихся на наш рынок международных компаний, ростом расходов на складскую и транспортную логистику и необходимостью налаживания прямых связей с поставщиками и клиентами. Мировые лидеры используют SCM, чтобы иметь конкурентные преимущества перед игроками второго и третьего эшелона. (www.frontstep.ru)
«По данным AMR Research и Forrester Research, с внедрением SCM компании получают такие конкурентные преимущества, как уменьшение стоимости и времени обработки заказа (на 20-40%), сокращение закупочных издержек (на 5-15%), сокращение времени выхода на рынок (на 15-30%), уменьшение складских запасов (на 20-40%), сокращение производственных затрат (на 5-15%), увеличение прибыли (на 5-15%)».
«Оптимизация управления цепочкой поставок в российской компании позволяет увеличить прибыль на 50-130%. Эффективно выстроенная цепочка поставок может стать стратегическим конкурентным преимуществом, как производителя, так и ритейлера. Она позволяет достигать настолько низкой себестоимости, что у компании появится возможность вытеснить конкурентов с рынка без потери прибыльности». Преимущества управления цепочками поставок:
ускорение оборота, сокращение материальных запасов на складах и общей стоимости хранения продукции;
повышение удовлетворенности заказчиков с помощью онлайновой системы размещения заказов и настройки продуктов;
гибкость проектирования, а также высокая скорость вывода продуктов в серию и снятия их с производства в соответствии с требованиями заказчиков и рынка;
сокращение сроков разработки и вывода продуктов на рынок, что приводит к росту рыночной доли компании;
сохранение высокого качества продуктов, несмотря на передачу больших объемов работ внешним подрядчикам.