CC BY
117
5
ТЕХНОЛОГИЧЕСКИЕ ПРОБЛЕМЫ
СРЕДСТВА ВИЗУАЛЬНОГО МОДЕЛИРОВАНИЯ ТЕХНИЧЕСКОЙ ПОДГОТОВКИ ПРОИЗВОДСТВА
Ю.Н. Фомина
Научный руководитель - кандидат технических наук, доцент Е.И. Яблочников
Рыночные отношения, усиление значимости фактора времени выпуска продукции, улучшение информированности потребителей - все это привело к усилению конкуренции между промышленными компаниями. Для сохранения конкурентоспособности предприятиям необходимо использовать новые информационные технологии. Их разработка невозможна без системного анализа проблемной области.
Введение
В настоящее время большинство отечественных предприятий осознает необходимость реорганизации технической подготовки производства (ТПП), в частности, важность внедрения новых информационных технологий и создания автоматизированных систем технической подготовки производства (АСТПП). Современный рынок промышленных товаров и услуг претерпел за последние 10 лет существенные изменения и стал ориентироваться на удовлетворение запросов различных групп потребителей. Появились новые формы кооперации в виде виртуальных предприятий, возросла конкуренция среди производителей, увеличилась информированность заказчиков. Чтобы сохранить положение на рынке в таких условиях, компании вынуждены кардинально пересмотреть формы и способы ведения своей деятельности [1].
Перед разработчиками АСТПП ставится задача систематизации и совершенствования методов анализа проблемной области (ТПП) как ключ к созданию систем, эффективных по стоимости, производительности и надежности [2]. Чтобы выжить в современных условиях, фирма должна адаптироваться и постоянно приспосабливаться к изменяющемуся окружению. Для этого компания должна быть организована таким образом, чтобы отслеживать постоянные изменения рынка сбыта, не уступать соперникам в условиях жесткой конкуренции, совершенствовать свои внутренние процессы, расширять спектр предлагаемых товаров и услуг при одновременном снижении времени их выпуска.
Исследования показывают, что наибольший процент ошибок при разработке систем возникает в процессе анализа и проектирования. Цена (временная и денежная) обнаружения и исправления ошибок становится выше на более поздних стадиях проекта. Например, исправление ошибки на стадии проектирования стоит в 2 раза, на стадии тестирования - в 10 раз, а на стадии эксплуатации системы - в 100 раз дороже, чем на стадии анализа. Рост объема и сложности проектов является реальностью [2].
Каждый проект по разработке АСТПП является уникальным. Это следует из вариации типов систем, клиентов, организаций, технологий и т.д. Также существуют различные отправные точки для определения требований. В некоторых случаях можно использовать готовую бизнес-модель, разработанную для другой организации. Иногда основой для проектирования служит детальное техническое задание заказчика. В других случаях клиенты могут иметь весьма неопределенное представление о том, что должна выполнять создаваемая система. Возможность существования столь различных отправных точек предполагает, что аналитики должны быть способны приспособить свой подход к определению требований к любой ситуации [3].
Для решения обозначенной проблемы требуется:
• создать типовой, подходящий для большинства случаев подход к анализу исходных требований;
• провести комплексный анализ ТПП различных промышленных предприятий;
• разработать унифицированные бизнес-процессы ТПП на основании полученных данных.
Основная часть
Особенностью проектирования АСТПП является то, что на промышленных предприятиях уже существует своя система ТПП. Это, с одной стороны, дает базу для анализа, а с другой - осложняет переход компании к новой системе организации и функционирования (эволюционный и революционный подходы). Следовательно, начальная стадия проектирования подсистем АСТПП заключается в системном анализе существующей ТПП предприятия.
Необходимо обозначить цели, методы и средства выполнения такого анализа. Целью выполнения этого этапа является комплексный анализ предметной области, состоящий из выявления требований к проектируемой подсистеме ТПП (определение того, что должно быть создано) и моделирования ТПП. Этот процесс в стандартах ЕСТПП назван стадией предпроектного анализа ТПП и разработкой технического задания. Его необходимость вызвана тем обстоятельством, что технологическая подготовка производства изделий на каждом предприятии имеет свои особенности, поэтому подсистемы ТПП каждой компании являются уникальными, хотя и реализованы на базе общих принципов, зафиксированных в соответствующих стандартах ЕСТПП, ЕСКД, ЕСТД и т. д.
Несмотря на различие отправных точек, существуют шаги, которые можно сделать в большинстве случаев. Это позволяет предложить типовой рабочий процесс по определению требований (логический аппарат исследования):
• перечисление возможных требований;
• осознание контекста системы;
• определение функциональных требований;
• определение нефункциональных требований.
На первом этапе при подготовке исходных данных (возможных требований) клиенты, разработчики и аналитики выдвигают множество идей, которые, возможно, стоит использовать при проектировании системы. В любом случае их необходимо сохранить для дальнейшего анализа. Этот список используется исключительно для планирования работ.
Множество людей, вовлеченных в процесс создания системы, не являются специалистами в области ТПП, т. е. необходимо описать контекст, в котором работает система (осознание контекста системы). Это реализуется за счет моделирования предметной области ТПП.
Определение функциональных требований сводится к построению различных вариантов функциональных моделей ТПП. К нефункциональным требованиям относятся такие свойства системы, как ограничения среды, производительность, зависимость от аппаратной платформы, ремонтопригодность, расширяемость, надежность и пр. [3].
Уровень формулировки требований особенно важен как стартовая точка при описании реализации. Документы, созданные на уровне формулировки требований, имеют наиболее продолжительный жизненный цикл, и в силу их близости к описанию проблем бизнеса они чрезвычайно полезны для проработки информационных систем. По этой причине уровень формулировки требований имеет наивысший приоритет - образует связь между пользователями и первоначальным описанием их проблем [4].
При предпроектном анализе описание ТПП производится поверхностно и ориентировано на цели и язык пользователя, поэтому используются, в основном, полуформа-
лизованные описательные методы. Создание различных типов моделей и проработка каждой из них по уровням описания в сочетании с формулировкой проблем бизнеса и составляет процесс анализа [4]. Предпроектный анализ в общем случае предполагает исследование предметной области ТПП в трех направлениях: информационном, функциональном и организационном. На основе полученных данных строится концептуальная модель ТПП предприятия.
Организационный анализ приводит к построению иерархической структуры компании.
С помощью функционального анализа выясняются функциональные связи и последовательности выполнения функций, задач и процедур ТПП. Данный анализ основывается на многоуровневом рассмотрении ТПП: на основе декомпозиции каждая функция разделяется на задачи, а те, в свою очередь, разделяются на процедуры. Это означает, что на каждом уровне модель должна давать ответы на вопросы пользователей с заданной степенью детализации. Такое исследование в практике создания информационных систем получило название бизнес-моделирования, а содержание функциональных моделей названо бизнес-процессом. Функциональный анализ выполняется на основе соответствующей методической и инструментальной поддержки, а также с учетом информации о предприятии (конкретном и среднем).
Информационный анализ заключается в исследовании информационных потоков, циркулирующих между функциональными компонентами ТПП. Информационный анализ выполняется для определения взаимодействия между подразделениями ТПП и состава передаваемой документации.
Ранее предложенная в стандартах ЕСТПП методика предпроектного анализа ТПП не нашла широкого применения на промышленных предприятиях, так как не была обеспечена соответствующими инструментальными средствами.
После определения цели анализа необходимо рассмотреть современные методы и средства его реализации (инструментарий).
Для функционального анализа ТПП целесообразно использовать:
• методологию SADT и разработанные на ее основе стандарты IDEF0, IDEFX и IDEFIX, а в качестве инструментальных средств - пакет Platinum BPwin 4.0 фирмы Computer Associates;
• методологию ADONIS (пакет ADONIS фирмы BOS Information Technologies Consulting);
• методологию UP и разработанный на ее основе пакет Rational Rose фирмы Rational Software Corporation.
Рассмотрим кратко указанные средства моделирования.
Пакет BPwin рекомендуется для небольших предприятий и основан на использовании стандартов IDEF0, IDEFX и IDEFIX, что позволяет обеспечить семантическую строгость, необходимую для гарантии правильности и непротиворечивости получаемых моделей, а также наглядность и полноту их отображения.
Функциональное моделирование BPwin выполняется с помощью диаграмм IDEF0. В диаграмме первого уровня (IDEF0), пример которой приведен на рис. 1, фиксируются все подсистемы, отражающие основные функции ТПП.
В соответствии с поставленной целью на диаграммах (диаграммах декомпозиций) следующих уровней детализации фиксируются результаты декомпозиции блоков вышестоящих уровней. Необходимо отметить, что функциональный анализ на базе диаграмм IDEF0 не является полным, так как в них не фиксируются правила перехода от одних функций к другим и правила ветвления процесса ТПП. Диаграммы IDEF0 используются на первом этапе функционального анализа ТПП для первичной оценки бизнес-процессов ТПП [2]. Наиболее полный функциональный анализ достигается на основе стандарта IDEF3, так как позволяет более точно определить правила функцио-
нирования анализируемой ТПП. Диаграммы в нотации IDEF3 позволяют представить бизнес-процессы с указанием последовательности выполнения функций за счет использования символов логики (последовательные и параллельное исполнение этапов, условие ЕСЛИ (да, нет)), но не содержат указаний о механизмах управления и исполнителях (рис. 2).
Положенияпо организации и функционированию ТПП
Чертежи изделий
Планируемый объем основного производства
База имеющаяся
Покупные изделия, СЕ и детали СТО
Материалы и полуфабрикаты g
НСИ Экономическая для целесообразность ТПП
ГОСТы, ОС Ты, СП для ТПП
Нормативы планирования
Аесгы приемки ТП
Комплекты текно логических документов
Чертежи СТО
Технологическая оснастка
Отдел главного Отдел главного металлурга термиста
Отдел главного гальваника
Т ехно логическая по дг отовка пр оизв о длва
Рис. 1. Модель верхнего уровня бизнес-процесса «Техническая подготовка
производства» в нотации ЮЕР0
Чонплск-
шь&оя» 30 куш КПП ИИ
Рис. 2. Модель бизнес-процесса «Проектирование технологического процесса» в нотации IDEF3
Таким образом, при использовании методологии SADT нельзя ограничиться одним стандартом, к примеру, IDEF0 или IDEF3. Тем самым при разработке с ее помощью комплексной модели ТПП не удается сохранить целостность, семантическую строгость получаемых моделей.
Функциональный анализ на базе ADONIS основан на составлении карты компании. Она представляет собой комплексное описание бизнеса и включает модели бизнес-процессов, документов, рабочей среды и др. Диаграмма более низкого уровня выступает в виде подпрограммы. Параметры функций содержат события, исполнимей, временные и стоимостные характеристики процесса. Организационные модели позволяют задавать структуру отделов и число исполнителей. Все данные представляют единую структуру, что увеличивает прозрачность системы и позволяет легко ее оценивать и модифицировать. Таким образом, методология ADONIS превосходит суммарные
возможности диаграмм IDEF0 и IDEF3. На рис. 3 представлена диаграмма бизнес-процесса в нотации ADONIS с использованием логических переходов.
Рис. 3. Модель бизнес-процесса «Проектирование технологического процесса»
в нотации ADONIS
К достоинствам данной системы относится возможность визуализации процессов - получение данных о временных и денежных затратах на процесс. Использование ADONIS удобно еще и тем, что диаграммы ADONIS могут быть выполнены в нотации UML и использованы на последующих этапах UP.
Функциональный анализ на базе UP предполагает использование диаграмм прецедентов и диаграмм деятельности в нотации UML. Именно в них основным структурным элементом является функциональная компонента ТПП: данный тип диаграмм используется при описании бизнес-процессов автоматизируемой предметной области, определении требований к будущей программной системе, а также отражает объекты системы и задачи, ими выполняемые. Принципиальное различие между ними состоит в том, что в диаграммах прецедентов функция (прецедент) определяется по отношению к внешнему субъекту (актору), что существенно ограничивает возможность ее дальнейшей детализации. В отличие от этого, в диаграммах деятельности процесс не имеет подобных ограничений, что позволяет детализировать диаграммы до того уровня, при котором они непосредственно могут быть использованы для построения алгоритмов бизнес-процессов в создаваемой системе (в данном случае в АСТПП). Этот тип диаграмм позволяет показать не только последовательность процессов, но их ветвление и синхронизацию [4].
В диаграммах деятельности имеется возможность выполнить разделение бизнес-процесса по различным подразделениям предприятия, в которых он выполняется. Пересекать линию дорожки могут только переходы, которые при этом обозначают вход потока управления в соответствующую службу или выход из него. Пример диаграммы деятельности с дорожками приведен на рис. 4.
Модели, представленные на рис. 2- 4, отображают один и тот же бизнес-процесс, но выполнены с помощью различных методик. Сравнение существующих методологий позволит найти наиболее наглядное, удобное и информационноемкое средство визуализации процессов, наилучшим образом подходящее для моделирования ТПП. Подобный анализ требует большой подготовительной работы, а именно детального исследо-
вания процессов функционирования ТТП, а также получения навыков по эксплуатации автоматизированных систем моделирования.
Далее представлены результаты проведения различных видов анализа.
Рис. 4. Модель бизнес-процесса «Проектирование технологического процесса» в виде диаграммы деятельности УМЬ
Результатом функционального анализа является получение комплекса функциональных моделей, отражающих ТПП конкретного предприятия с заданным уровнем детализации. Необходимо отметить, что достаточно часто функции на моделях изображаются без указания управляющих элементов (выдача распоряжение или заданий на выполнение работ). Таким образом, теряются этапы типа комплектования и перемещения, которые, в свою очередь, зависят от элементов, связанных с планированием и составлением графиков выполнения работ. Учет управляющих компонентов может значительно изменить функциональную модель. Отсутствие указанных элементов существенно снижает ценность функционального анализа и может привести к серьезным ошибкам при оценке его результатов [5].
Если документы выполнены на твердом носителе, то при переходе из подразделения в подразделение требуется процедура передачи (следует формализовать сами правила передачи и заказа документов для их дальнейшего автоматизирования), в которой выполняется регистрация выходных и входных документов. Если не учитывать процедуры передачи документов, то этим самым будет занижен экономический эффект от внедрения электронного архива, при котором не нужен перенос документа из подразделения в подразделение и, кроме того, возможен одновременный доступ к документу из разных подразделений, что значительно сокращает цикл ТПП [1].
Анализ функциональной модели позволяет локализовать проблемные места, оценить преимущества новых функциональных компонентов ТПП и глубину изменений существующей организации ТПП. Детализация функциональных компонентов ТПП позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Признаками несовершенной деятельности могут быть неуправляемые и дублирующиеся работы, неэффективный документооборот (нужного
документа не оказывается в нужном месте в нужное время), отсутствие обратных связей по управлению (проведение работы не зависит от промежуточных результатов) и по входу (объекты и информация используются нерационально). Целью является сокращение времени выполнения, что должно быть выражено количественно.
Функциональный анализ дополняется информационным анализом ТПП, основанным на описании информационных потоков, циркулирующих в ТПП. Основой для создания информационной модели являются входящие и выходящие информационные потоки функциональной модели.
Каждое из рассмотренных выше инструментальных средств может фиксировать информационные потоки ТПП. Информационные потоки на диаграммах фиксируются двунаправленными стрелками, а также комментариями, которые могут быть видны или нет в зависимости от «точки зрения» (что реализовано, например, в методологии ADONIS).
При унификации процессов информационный анализ может быть выполнен различными способами. Простейшим из них является использование диаграмм деятельности, в которых вместо линий связи показаны информационные потоки между функциональными компонентами и даны указания на используемые документы в виде комментариев.
Результаты информационного анализа необходимы в дальнейшем при классификации объектов. Они отражаются как элементы описания, характеристики и атрибуты. Т. е. для создания классов необходимо оперировать данными и информационной, и функциональной модели.
Информационные потоки для каждой функциональной компоненты можно разделить на входной/выходной основной поток, входной/выходной управляющий поток, входной/выходной поток с нормативно-справочной информацией (НСИ) (рис. 5).
' i I j
----^ ФК . ---
н™ | ! н™"
Рис. 5. Информационные потоки для 1-й функциональной компоненты
На рис. 5 приняты обозначения: О - основной поток, У - управляющий поток, Н -поток с нормативно-справочной документацией, ФК; - функциональная компонента (/-й этап функциональной модели). Входной основной поток - это материал для исполнения основного назначения функциональной компоненты, преобразуемый в выходной основной поток. Входной управляющий поток содержит распоряжение (задание) на выполнение работы, для которой предназначена функциональная компонента. Выходной управляющий поток содержит информацию о завершении или не выполнении заданной работы. Управляющие потоки чаще всего фиксируются с помощью таких атрибутов, как «утвержден», «на изменении», «существует неутвержденная версия» и др. На диаграммах они могут отображаться в виде отдельных функциональных компонентов, элементов прямой и обратной связи или не показываться вообще. Входной поток с НСИ обычно содержит запрос, связанный с получением НСИ, а выходной поток - результаты выполнения запроса.
На рис. 6 показана схема информационных потоков, выраженная в виде диаграммы деятельности.
Схема информационных потоков (на рис. 6 обозначена «ИП») образована путем удаления связей из функциональной модели и добавления информационных потоков. Линии слияния (разделения) используются для указания соединения (разделения) информационных потоков, при этом сторожевое условие «И» на линии слияния означает, что выполнение задачи может начаться лишь тогда, когда на задачу поступили все необходимые для неё информационные потоки. Например, входной поток ИП^ будет сформирован только после создания потоков ОВЫ и У2 , т. е. если пришел поток О12 , то задача 2 будет выполняться лишь после того, как пришло распоряжение на ее выполнение (поток У2,ых ).
Рис. 6. Пример схемы документооборота, выдержанной в виде диаграммы
деятельности UML
Таким образом, при правильно и полно составленных диаграммах с информационными потоками в случае дальнейшей реорганизации какой-либо функциональной компоненты будет ясно, какие документированные знания нужно будет модифицировать.
Понимание важности оценки применяемых в бизнес-процессах знаний привело создателей ADONIS к разработке дополнительных средств для идентификации и структурирования содержимого соответствующих категорий знаний в виде моделей документов.
Информационный анализ не может завершиться лишь составлением диаграмм. Нужны данные об информационных потоках и документах, применяемых в ТПП. Поэтому параллельно с составлением диаграмм создаются спецификации документов для уже сформированных моделей. Описанный выше процесс необходим для создания классов объектов, при этом производится анализ всех имеющихся данных, накопленных в функциональных информационных моделях всех уровней. Необходимо отметить,
что без словаря данных невозможна эффективная интеграция подсистем ТПП как между собой, так и с системами управления предприятием.
На основе информационного анализа необходимо получить ответы на следующие вопросы:
• какие информационные связи существуют между задачами ТПП;
• имеет ли место дублирование и нерациональные потоки информации;
• какие виды и формы документов используются при решении задач ТПП, какова периодичность создания документов и их объемы;
• какие входящие документы использует каждая функциональная компонента ТПП;
• какие исходящие документы генерирует функциональная компонента ТПП;
• какие документы регламентируют выполнение функциональной компоненты ТПП;
• каковы состав и структура баз данных технологического назначения;
• наличие и формы хранения нормативной, инструктивной и нормативно-справочной информации.
Организационный анализ основан на составлении диаграммы, фиксирующей организационную структуру ТПП.
В ADONIS имеются средства для создания организационных структур: модели рабочей среды, встраиваемые в комплексную диаграмму компании. В них отражаются состав подразделения, информация о руководителе и составе исполнителей.
Организационные модели дополняются спецификацией подразделений ТПП. В этой спецификации за каждым подразделений закреплены его атрибуты: назначение, количество и состав исполнителей и т.д. На основе организационного анализа необходимо получить ответы на следующие вопросы:
• какова организационная структура и схема работ в ТПП;
• каковы функциональные связи между подразделениями ТПП;
• каковы функциональные связи между подразделениями ТПП и внешними к ТПП отделами предприятия;
• каковы характеристики подразделений ТПП.
Критерием оценки при выполнении предпроектного анализа служат функционально-стоимостные расчеты (другое распространенное название - ABC-анализ, Activity-Based Costing). ABC-анализ - это технология, применяемая для оценки затрат и количества используемых ресурсов. Она помогает распознать и выделить наиболее дорогостоящие операции для дальнейшего анализа.
В данном случае ABC-анализ необходим для определения стоимости выполнения работ в функциональных компонентах ТПП. Возможность и успешность применения ABC-анализа зависит от результатов накопленной статистики по трудоемкости решения технологических задач, по нормативной базе и применяемым программным средствам. Для каждой компоненты в функциональной модели рассчитывается прямая стоимость ее выполнения плюс стоимость накладных расходов, распределенных по всей модели с помощью некоего алгоритма. В итоге мы получаем стоимостную оценку функциональной компоненты заданного уровня детализации.
Для крупных промышленных предприятий проведение предпроектного анализа ТПП - трудоемкий и сложный процесс. Это обстоятельство осложняет проведение анализа. Здесь может быть использован подход, согласно которому утверждается, что 20 % работ составляют 80 % затрат [5].
Для проведения функционально-стоимостного анализа можно воспользоваться специализированными программными средствами, такими, например, как блок симуляции в ADONIS.
По результатам АВС-анализа оцениваются варианты бизнес-процессов ТПП и выбираются наиболее эффективные из них по стоимости, производительности и др.
Заключение
Построение компании и управление ею является очень сложной деятельностью, и ранее она осуществлялась интуитивно. Реинжиниринг бизнес-процессов ставит своей целью превратить искусство управления компанией в инженерную дисциплину. Для этого необходимо построить адекватные, понятные модели предприятия и дать возможность менеджерам анализировать последствия изменения этих моделей. Реинжиниринг бизнес-процессов обозначает совокупность методов и средств, предназначенных для кардинального улучшения основных показателей деятельности компании путем моделирования, анализа и перепроектирования существующих бизнес-процессов. Деятельность компании должна быть детально исследована, чтобы каждый, имеющий с ней дело, в любой ситуации располагал достаточной информацией для принятия наилучшего решения. Известно, что сложные вещи проще воспринимаются, если они каким-либо образом зрительно представлены, а не только описаны. Формальный способ визуализации чего-либо - построение моделей. Следует понимать, что модель - это более или менее верное представление моделируемой сущности, выполненное с заданной степенью детализации [3].
Существуют различные методики моделирования бизнеса. В данном случае рассмотрены следующие три из них: SADT, UP и ADONIS. Сравнительный анализ этих методов применительно к предметной области ТПП до сих пор еще не проводился, тем самым увеличивается значимость проведенной работы. Главным недостатком рассмотренных выше методов моделирования, за исключением ADONIS, является то, что они позволяют лишь формализовать описание бизнес-процессов, но не подходят для системного формирования функциональных структур и оптимизации деятельности компании. ADONIS же дает возможность комплексного подхода к анализу за счет всестороннего описания (функционального, организационного и информационного) предметной области, реализованного в единой карте компании.
Подобные методики позволяют создать концептуальную модель предприятия. Благодаря им можно непосредственно представлять в моделях плохо формализуемые знания менеджеров о бизнес-процессах, в частности о рабочих процедурах. На их основе строятся рабочие модели и осуществляется связь между менеджерами и программистами.
Литература
1. Яблочников Е.И. Автоматизация технологической подготовки производства в приборостроении. СПб: СПбГУ ИТМО, 2002. 92 с.
2. Марка Д., Мак-Гоуэн К. Методология структурного анализа и проектирования. М.: Метатехнология, 1993. 240 с.
3. Ойхман Е.Г., Попов Э.В. Реинжиниринг бизнеса: реинжиниринг организаций и информационные технологии. М.: Финансы и статистика, 1997. 336 с.
4. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя. М.: ДМК, 2000. 432 с.
5. Куликов Д. Д., Яблочников Е. И. Методологические аспекты автоматизации технологической подготовки роизводства. // Вестник информационных и компьютерных технологий. 2004. №4. С. 35-42.
