logo
Konspekt_lektsy_3_St

Cals - технологии

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

Всего можно выделить три группы CALS-технологий:

Перечисленные набор методы реализации стратегии CALS (создания ЕИП), в настоящее время подробно рассмотрены и реализованы в ряде исследований и на предприятиях.

Рассмотрим основные этапы по внедрению CALS - технологий. Для более наглядного представления ниже приведена схема рис. 5.15.

Рисунок 5.15. Этапы внедрения CALS — технологий на предприятии.

Программа работ по созданию ЕИП предприятия должна включать в себя следующие этапы:

Цель анализа - выявить существующее взаимодействие между бизнес-процессами информа­ционного обеспечения и оценить их рациональность и эффективность. Для этой цели с использова­нием CASE-технологий (CASE - Computer Aided System Engineering) разрабатываются модели, со­держащие детальное описание выполняющихся процессов в их взаимосвязи.

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

Системы управления данными об изделии в настоящее время достаточно широко реализова­ны и представлены на российском рынке. Поэтому перед каждым предприятием будет стоять зада­ча, какую систему выбрать и как ее применять для решения конкретных задач. Задача выбора и при­обретения технических средств (компьютеров и сетевого оборудования) тесно связана с задачей выбора PDM-системы.

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

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

С целью внедрения CALS-технологий формируется рабочая группа

Рабочая группа должна:

а) обеспечивать взаимодействие сотрудников предприятия при реализации всех этапов внедрения CALS-технологий;

б) включать пользователей PDM-системы (конструкторов, технологов) и ее разработчиков - программистов, системных аналитиков.

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

Обучение является долговременным непрерывным процессом и особенно важно в самом на­чале пути для понимания аспектов бизнеса, которых коснется PDM. К сожалению, направить на обучение все предприятие целиком нереально. Поэтому большая часть задач ложится на рабочую группу, члены которой должны пройти обучение по соответствующим CALS технологиям и про­граммным продуктам. Для обучения рабочей группы могут быть использованы материалы НИЦ «CALS-технологий», а также опыт внедрения технологий на ряде предприятий.

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

Реинжиниринг бизнес-процессов

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

Основными целями разработки консалтинговых проектов являются:

• представление деятельности предприятия и принятых в нём технологий в виде иерархии диаграмм, обеспечивающих наглядность и полноту их отображения;

• формирование на основании анализа предложений по реорганизации организационно-управленческой структуры;

• упорядочивание информационных потоков (в том числе документооборота) внутри предприятия;

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

Разработка консалтинговых проектов включает следующие этапы.

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

Первым шагом собственно разработки является предварительное изучение задачи. Предварительное изучение должно ответить на ряд вопросов:

• В чём недостатки существующей ситуации?

• Какие улучшения возможны?

• На кого окажет влияние новая система?

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

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

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

В рамках этапа 2 (проведение обследования деятельности предприятия) осуществляется:

• предварительное выявление требований, предъявляемых к будущей системе;

• определение организационной, штатной и топологической структур предприятия;

• определение перечня целевых задач (функций) предприятия;

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

• определение перечня применяемых на предприятии средств автоматизации.

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

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

На этапе 3 (построение моделей деятельности предприятия) осуществляется обработка результатов обследования и построение моделей деятельности предприятия следующих двух видов:

• модели «как есть», представляющей собой «снимок» положения дел на предприятии (организационная и штатная структура, взаимодействия подразделений, принятые технологии, автоматизированные и неавтоматизированные бизнес-процессы и т.д.) на момент обследования. Это позволяет понять, что делает и как функционирует данное предприятие с позиций системного анализа. На основе автоматической верификации это выявляет ряд ошибок и узких мест, и сформулировать ряд предложений по улучшению ситуации;

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

Главным результатом детального изучения является построение системного проекта (модели требований), являющегося первой фазой разработки собственно системы автоматизации (именно, фазой анализа требований к системе), на которой требования заказчика уточняются, формализуются и документируются. Системный проект строится на основе модели «как должно быть» и результатов обследования предприятия в части выявления требований к будущей системе.

Для построения каждой из требуемых моделей необходима интенсивная работа 6-7 квалифицированных системных аналитиков в течение 2-4 месяцев.

После выбора системного проекта на основе выявленных и согласованных требований осуществляется разработка предложений по автоматизации (этап 5), включающих:

• составление перечня автоматизированных рабочих мест предприятия и способов взаимодействия между ними;

• анализ применимости существующих систем управления предприятиями (прежде всего классов MRP и ERP) для решения требуемых задач и формирование рекомендаций по выбору такой системы;

• совместное с заказчиком принятие решения о выборе конкретной системы управления предприятием или разработке собственной системы;

• разработка требований к техническим средствам;

• разработка требований к программным средствам;

• разработка предложений по этапам и срокам автоматизации.

На этапе 6 на основании принятых решений по автоматизации осуществляется преобразование системного проекта в технический проект (модель реализации), включающее следующие действия:

• уточнение логической модели (разработка подробной логики каждого процесса с использованием диаграмм потоков данных и спецификаций процессов);

• проектирование физической базы данных;

• построение иерархии функций модулей, подлежащих программированию;

• оценка затрат на реализацию.

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