Магистерская работа: Управление инженерными данными на этапе концептуального проектирования ракеты-носителя

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

Процесс моделирования подразделяется на 4 уровня:

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

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

) Структурный уровень, когда определена структура операторов, описывающих взаимосвязь входных, выходных и внутренних переменных.

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

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

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

Теперь определимся, что же будет смоделировано. Под процессом будем понимать бизнес-процесс (БП). Разберёмся, что же такое БП и что понимается под его моделью.

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

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

Вход в БП - ресурс, необходимый для выполнения БП.

Выход БП - это результат (продукт, услуга) выполнения БП.

Документооборот - это система документов обеспечения деятельности организации.

Модель - это графическое, текстовое, символьное описание БП, либо их взаимосвязанная совокупность.

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

¾      только повышение результативности и эффективности процессов может обеспечить организации конкурентоспособное будущее;

¾      реальная деятельность представляет собой процессы;

¾      необходимо решать не отдельные проблемы деятельности при помощи текущих административных мер, а устранять причины возникновения этих проблем;

¾      большинство проблем возникает на границах между подразделениями организации; эти проблемы можно устранить, только рассматривая деятельность как процесс.

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

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

Количественная оценка БП это его эффективность.

Показатели эффективности БП - параметры БП, характеризующие взаимоотношения между достигнутыми результатами и использованными ресурсами.

В данном случае ресурсы - это информация, документы, файлы, финансы, материалы, персонал, оборудование, инфраструктура, среда, программное обеспечение, необходимое для выполнения БП.

Возникает вопрос по какой причине принимается решение по моделированию бизнес-процессов компании. Как правило основной причиной является снижение конкурентоспособности предприятия. Моделирование БП направлено на установление причины снижения эффективности политики проводимой организацией(снижение прибыли при неизменном или увеличивающемся количестве затрачиваемых ресурсов). То есть моделирование направлено на достижение «технологической прозрачности» деятельности компании и изучение перспективы развития организации. Результатом моделирования БП являются:

¾      сведения о функционировании подразделений и сотрудников;

¾      сведения о правильности распределения прав и обязанностей руководителей;

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

Имея модель предприятия, всех его бизнес-процессов, сориентированных на конкретную цель, компания открывает возможность его совершенствования.

.2.1 Модель процесса концептуального проектирования «как есть»

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

В ходе анализа существующей схемы бизнес-процессов для каждого подразделения выявляются следующие параметры:

¾      что поступает в подразделение «на входе»;

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

¾      кто является ответственным за выполнение каждой из функций;

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

¾      что является результатом работы подразделения «на выходе».

Для лучшего понимания работы проектного отдела для начала рассмотрим упрощённую схему работы проектного отдела (рисунок 2.6).

Рисунок 2.6-Схема работы проектного отдела.

Рассмотрим по подробнее работу проектного отдела. Для модели "как есть", в качестве примера, рассмотрим работу проектного отдела в ракетно-космическом центре "ЦСКБ - Прогресс". Проектирование осуществляется следующим образом: проектант, работая на сервере PDM-системы Windchill, проектирует мастер - геометрию. Так как все данные хранятся на сервере в одном экземпляре, исключена возможность их неактуальности.

Затем делает с МГП ассоциативно связанные Теоретический Чертеж в Creo, что исключает ошибки из-за отсутствия импорта геометрии между разными САПР. Далее проектант согласовывает и утверждает модели с чертежами в среде Windchill и на бумажных носителях. Проектант с Листами Запуска на модели и чертежи должен согласовать документацию с вышестоящим начальством начиная с начальника группы, далее процесс проходит через начальника отдела, технологов и т.д. вплоть до утверждения чертежей заказчиком.

Согласование в бумажном виде происходит часто не оперативно, и документы задерживаются на одном из этапов согласования, останавливая тем самым производство. Сразу после утверждающей подписи на соответствующих «бумагах», документам и моделям на сервере в Windchill присваивается статус "выпущено". Далее с выпущенными объектами могут начинать работать другие подструктуры предприятия.

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

Рассмотрим деятельность проектного отдела ещё более подробно (уровень конкретных документов). Для этого используем методологию ARIS, основные моменты которой описаны выше, а именно нотацию aeEPC

.2.2 Нотация aeEPC

Нотация aeEPC построена на базе ARIS eEPC и описывает адаптированные расширенные цепочки процесса, управляемого событиями. В основе имеет принцип моделирования потоков работ. Использует различные символы логики ветвления и слияния бизнес-процессов. При этом на диаграмме отображаются входящие и исходящие документы, информация, иной инфраструктуры ЕИП при помощи специальных объектов. С помощью нотации эффективно описываются все процессы.

Для получения более полных знаний о методологии и других нотациях воспользуйтесь пособием «Интегративное проектирование единого информационного пространства предприятия» написанным А.В. Иващенко, С.С. Кожевниковым, М.Е Кременецкой. [14]

Графические элементы для описания процесса с использованием нотации aeEPC

Рисунок 2.7 - Графические элементы нотации aeEP

Рисунок 2.7 продолжение - Графические элементы нотации aeEPC

Для того чтобы разобраться в потоках документов и работ проектного отдела обратимся к приложению А.

Из диаграммы видно, что работа проектного отдела начинается на основании приказа по предприятию о разработке технического предложения (ТП)по заказу сразу после заключения контракта между директором и заказчиком. Этим приказом определяется начальник проектной группы по конкретному изделию. Затем проектанты отдела выпускают техническое решение по вопросу создания ТП. В нём прописывается перечень необходимых работ, исполнители сроки исполнения заданий. После согласования этого решения с высшим руководством проектного отдела, высшим руководством предприятия, высшим руководством отдела-разработчика и отдела исполнителя техническое решение переносится на кальку и выпускается листок запуска. Листок запуска прикрепляется к запущенному проекту, содержит отметки о согласованиях, номера и названия документов, номера чертежей, наименования моделей и рассылается по отделам исполнителям. После этого архиватор заносит сведения о решении в «ЛОЦМАН», а проектант заносит решение в Windchill, калька сдаётся в архив. Затем проектанты составляют (этим всегда занимается один и тот же человек, ответственный за составление ФИД, листов запуска и т.п.) «Форму исходных данных» (ФИД). ФИД - это документ, сопровождающий создаваемое изделие, включающий все пункты решения о выполнении тех или иных работ, сроки исполнения работ, исполнителей и визы проверяющих. По выполнении работы исполнителем оформляется карточка контроля, и оформленная карточка отправляется на подпись проверяющему. После окончания всех работ вся отчётная документация стекается к начальнику отдела, и проектанты проектного отдела подготавливают отчёт о выполненных технического решения.

Весь этот поток документации можно представить в виде схемы, показанной в приложении Б. Для ознакомления с вышеупомянутыми документами обратимся к приложению В. Итак, проектанты предоставляют отчёт начальнику отдела. Так же начальник проектного отдела получает выполненное ТП. Оно согласовывается с начальником конструкторского отдела, начальником технологического отдела и заказчиком (отметка в листе запуска). Если документы подписываются всеми участниками, то проектанты приступают к разработке тактико-технического задания (ТТЗ) на основании технического решения. Если же хотя бы одного участника согласования что-то не устраивает, ТП возвращается на стадию разработки на основании служебной записки, дорабатывается и снова согласовывается (отметка листе запуска). Количество итераций не ограничено. Так же в редких случаях возможен вариант отказа от заказа. Это может произойти на основании разрыва контракта со стороны заказчика в силу невозможности удовлетворить исполнителем его требований или же со стороны исполнителя если заказ невозможно выполнить в силу каких либо обстоятельств.

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

Затем проектанты составляют списки недостающих для работы над проектом изделий в библиотеках Creo. Системные администраторы и программисты отдела связываются со смежными предприятиями-поставщиками и запрашивают у них недостающие модели изделий и добавляют их в библиотеку своего отдела. Так же они обеспечивают доступ к тем или иным файлам конкретному сотруднику в системе Windchill.

Теперь всё готово для проектирования агрегата. На основании технического решения и листа запуска проектная группа создаёт УСП и ТЧ. Остановимся на создании УСП. При проектировании в системе Creo работники опираются на нормативно-технологическую документацию. По завершении процесса УСП проектанты оформляют контрольную карточку и всё это отправляют на проверку начальнику проектной группы. УСП отправляется в системе Windchill, а контрольную карточку и лист запуска проектант несёт сам проверяющему и после подписания забирает их для отчёта о проделанной работе.

В Windchill документу присваивается статус «на проверке». Если ошибок в построениях нет и отклонений от ТТЗ не обнаружено, то контрольной карточке ставится подпись проверяющего, а в Windchill документу присваивается статус «проверено». Или же, если найдены недочёты контрольная карточка не подписывается, и проверяющий отправляет УСП обратно разработчику. В Windchill документу присваивается статус «доработать». После доработки МГП снова отправляется к ведущему инженеру-конструктору. Он её проверяет, подписывает, если его всё устроило или опять отправляет на доработку. Количество итераций не ограничено. После проверки УСГП отправляется на согласование к главному конструктору и начальнику проектного отдела. Если нареканий нет, то УСП согласуется (отметка в ЛЗ и в ТР). Если кого то из участников согласования что - то не устраивает УСП отправляется на доработку (отметка в листе запуска) затем на проверку и снова на согласование.

Приступим к описанию процесса создания ТЧ в Creo Elements. ТЧ создаётся, затем ТЧ проверяется ведущим инженером-конструктором. Если нареканий нет (ТЧ сделан по нормативной документации и совпадает с МГП), то подписывается контрольная карточка и ТЧ отправляется на согласование в конструкторский отдел. Сопровождающая документация всё та же: ЛЗ, ТР, служебная записка на случай «не согласования». Если ТЧ проверку не прошёл, то он отправляется на доработку к разработчику и сопровождается служебной запиской. Для запуска ТЧ и УСП создаются два отдельных листа запуска. Это делается по следующим причинам:

) Заказчик расписывается только в листе запуска на ТЧ, так как проверяет только ТЧ;

) В УСП содержится много информации, которая не используется при разработке ТЧ. Следовательно, при необходимости доработки УСП доработка ТЧ не всегда нужна. Возможна обратная ситуация: при доработке ТЧ УСП изменений не требует.

После согласования ТЧ и УСП проходят проверку входного контроля. На этом этапе проверяются на соответствие нормативно - технологической документации чертёж, модель, все названия, номера и обозначения(отметка в листе запуска и ТР). Если документация прошла входной контроль то она вместе со всей сопровождающей документацией отправляется в архив и «ЛОЦМАН», где хранится в дальнейшем. В системе Windchill ей присваивается статус «выпущено».

Достоинствами этого процесса являются:

¾      экономия времени проектанта в связи с полной интегрируемостью систем Creo Elements (Pro/ENGINEER) и Windchill;

¾      актуальность данных;

¾      простота внесения изменений в КД;

Явным недостатком моделируемого процесса является долгий процесс согласования как первоначальной документации, так и вносимых в неё изменений. Это значительно увеличивает время выпуска проектной документации и затраты на выпуск проекта изделия.

Согласование только в среде Windchill невозможно из - за отсутствия электронно - цифровой подписи на предприятии.

Электронно-цифровая подпись - реквизит электронного документа, позволяющий установить отсутствие искажения информации в электронном документе с момента формирования ЭЦП и проверить принадлежность подписи владельцу сертификата ключа ЭЦП. Значение реквизита получается в результате криптографического преобразования информации с использованием закрытого ключа ЭЦП.[18]