Предпроектное обследование промышленных предприятий

И.А. Гурина,

инж.- техн.

В.Д. Костюков,

вед. н. с., к.т.н.,

В.А. Петрик,

дир.  ракет. - косм. зав.,

А.И. Селиверстов,

зам. ген. дир.,

А.В. Цырков,

гл. констр. ЕКИТСУП, д.т.н.

ГКНПЦ  им. М.В. Хруничева, zavod-hrunichev@mail.ru, г. Москва

Представлены результаты научно-исследовательских работ по предпроектному обследованию ГКНПЦ имени М.В. Хруничева

 

В настоящее время в России резко возрос интерес к общепринятым на Западе стандартам менеджмента, однако, в реальной практике управления существует один очень показательный момент. Многих руководителей до сих пор можно поставить в тупик прямым вопросом об организационной структуре предприятия или о схеме существующих бизнес-процессов. Наиболее продвинутые и регулярно читающие экономическую периодику менеджеры, как правило, начинают чертить понятные только им одним иерархические диаграммы, но и в этом процессе обычно быстро заходят в тупик. То же самое касается сотрудников и руководителей различных служб и функциональных подразделений. В большинстве случаев, единственным набором правил, в соответствии с которыми функционирует предприятие, является комплект положений и должностных инструкций. Чаще всего эти документы составлялись много лет назад. Они слабо структурированы, плохо связаны между собой и, вследствие этого, просто пылятся на полках. До поры до времени подобный подход был оправдан, так как во время становления российской рыночной экономики понятие конкуренции практически отсутствовало, да и затраты считать не было особой необходимости - прибыль была гигантской. В результате этого, в течение последних нескольких лет наблюдается вполне объяснимая картина: крупные предприятия, выросшие в начале 90-х годов прошлого столетия, постепенно сдают свои позиции, вплоть до полного ухода с рынка. Отчасти это обусловлено тем, что на предприятии не были внедрены стандарты управления, полностью отсутствовало понятие функциональной модели деятельности и миссии. С помощью моделирования различных областей деятельности можно достаточно эффективно анализировать "узкие места" в управлении и оптимизировать общую схему бизнеса. Но, как известно, на любом предприятии высший приоритет имеют только те проекты, которые непосредственно приносят прибыль, поэтому речь об обследовании деятельности и ее реорганизации обычно идет только во время ощутимого кризиса в управлении предприятием.

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

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

·      IDEF0 - методология функционального моделирования. С помощью наглядного графического языка IDEF0, изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков - в терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы;

·      IDEF1 – методология моделирования информацион­ных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи;

·      IDEF1X (IDEF1 Extended) – методология построения реляционных структур. IDEF1X относится к типу методологий “Сущность-взаимосвязь” (ER – Entity-Relationship) и, как пра­вило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;

·      IDEF2 – методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практиче­ски отказались, и его развитие приостановилось на самом начальном этапе. Однако в настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамиче­ские модели, построенные на базе “раскрашенных сетей Петри” (CPN – Color Petri Nets);

·      IDEF3 – методология документирования процессов, происходящих в системе, которая используется, например, при исследовании технологических процессов на предприятиях. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 – каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF3;

·      IDEF4 – методология построения объектно-ориентированных систем. Средства IDEF4 позволяют на­глядно отображать структуру объектов и принципы их взаи­модействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы;

·      IDEF5 – методология онтологического исследования сложных систем. С помощью методологии IDEF5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о дальнейшем развитии системы и производится её оптимизация.[1]

В настоящее время самым распространенным является стандарт IDEF0. Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique). Несколько лет назад в России небольшим тиражом вышла одноименная книга, посвященная описанию основных принципов построения SADT-диаграмм. Исторически, IDEF0, как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing) и была предложена департаментом Военно-Воздушных Сил США. Собственно семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF=ICAM DEFinition). В процессе практической реализации, участники программы ICAM столкнулись с необходимостью разработки новых методов анализа процессов взаимодействия в промышленных системах. При этом кроме усовершенствованного набора функций для описания бизнес-процессов, одним из требований к новому стандарту было наличие эффективной методологии взаимодействия в рамках “аналитик-специалист”. Другими словами, новый метод должен был обеспечить групповую работу над созданием модели, с непосредственным участием всех аналитиков и специалистов, занятых в рамках проекта.

В 1993 г. группа пользователей IDEF (IDEF Users Group, в настоящее время Society of Enterprise Engineering — SEE), совместно с Национальным институтом стандартов и технологии (National Institute of Standards and Technology — NIST) предприняли попытку создания документированного стандарта для IDEF0, который мог бы использоваться как военными, так и гражданскими департаментами правительства США. Этот стандарт был опубликован как федеральный стандарт обработки информации (Federal Information Processing Standard — FIPS) [2], а в 2000 году он принят в качестве стандарта в Российской Федерации.

Графический язык IDEF0 относительно прост и гармоничен. В основе методологии лежат четыре основных понятия:

Первым из них является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника (рис. 1) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, “производить услуги”, а не “производство услуг”).

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

Вторым “китом” методологии IDEF0 является понятие интерфейсной дуги (Arrow). Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком.

рис.1. Функциональный блок.

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.

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

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

Необходимо отметить, что любой функциональный блок по

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

При построении IDEF0 – диаграмм важно правильно отделять входящие интерфейсные дуги от управляющих, что часто бывает непросто. К примеру, на рис. 2 изображен функциональный блок “Обработать заготовку”.

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

Другое дело, когда ОК с КЭ «обрабатываются» службой Главного технолога (бюро технической подготовки – БТП цеха) и в них вносятся изменения (рис. 3).

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

                                     

 

   рис. 2. Пример входящих интерфейсных дуг.                          рис. 3. Пример распределения входящих интерфейсных дуг.

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (WorkFlow Diagram).

Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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

Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором «А - 0».

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

Определение и формализация цели разработки IDEF0 – модели является крайне важным моментом. Фактически цель определяет соответствующие области в исследуемой системе, на которых необходимо фокусироваться в первую очередь. Например, если моделируется деятельность предприятия с целью построения на базе этой модели информационной системы, то эта модель будет существенно отличаться от той, которая бы разрабатывалась для того же самого предприятия, но с целью оптимизации логистических цепочек.

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

В процессе декомпозиции, функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы и называется дочерней (Child diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок - предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. Важно отметить, что в каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0 – модели. Наглядно принцип декомпозиции представлен на рис. 4. Следует обратить внимание на взаимосвязь нумерации функциональных блоков и диаграмм - каждый блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу прямоугольника), а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что декомпозиции для данного блока не существует.

Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0: диаграмм, функциональных блоков, интерфейсных дуг существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Например, для управляющей интерфейсной дуги “распоряжение об оплате” глоссарий может содержать перечень полей соответствующего дуге документа, необходимый набор виз и т.д. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией [4].

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

рис.4. Декомпозиция функциональных блоков.

Разумеется, строго следовать этим ограничениям вовсе необязательно, однако, как показывает опыт, они являются весьма практичными в групповой работе над разработкой IDEF0-модели

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

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

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

В результате, за достаточно короткое время и при привлечении минимума человеческих ресурсов строится функциональная модель существующей организации работы "как есть" (AS-IS). На основе этой модели достигается консенсус между различными единицами бизнеса по вопросам, кто что сделал и что каждая единица бизнеса добавляет в процесс. Эта модель позволяет выяснить, что можно сделать сегодня, перед тем как решить, что следует сделать завтра. Внедрение информационной системы неизбежно приведет к перестройке существующих бизнес-процессов предприятия. Анализ функциональной модели позволяет понять, где находятся самые “узкие места”, в чем будет состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая организация бизнеса. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Признаками несовершенной деятельности могут быть бесполезные, неуправляемые и дублирующиеся работы, неэффективный документооборот (нужного документа не оказывается в нужном месте в нужное время), отсутствие обратных связей по управлению (проведение работы не зависит от результата) и по входу (объекты и информация используется нерационально). [3]

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

Реструктуризация бизнес процессов и создание КИСП требуют больших капитальных вложений. Определение объемов, очередности и сроков выполнения работ по созданию КИСП является достаточно сложной проблемой, требующей принятия продуманного ответственного и взвешенного решения. Для принятия его необходимо располагать достоверной информацией об эффективности работы действующего предприятия. Прежде, чем приступать к коренной модернизации производства и реструктуризации бизнес процессов, необходимо оценить эффективность работы действующего предприятия. С 1977 года специалисты в области автоматизированного управления производством используют контрольный список ABCD Оливера Уайта для улучшения деятельности своих предприятий. Контрольный список ABCD является эффективным инструментом анализа уровня внедрения CALS-технологий на предприятии.

Контрольный список ABCD Оливера Уайта [5] предназначен, прежде всего, для специалистов в области логистики, управления производством, менеджмента качества, сертификации производства и обеспечивает эффективный подход к определению контрольных показателей деятельности предприятия и его достижений в области применения информационных технологий по сравнению с лучшими зарубежными фирмами. Наиболее острые вопросы списка охватывают все основные сферы деятельности предприятия:

·         Стратегическое планирование.

·         Люди/Команда.

·         Общее управление качеством/Фундаментальные улучшения.

·         Разработка новых видов продукции.

·         Планирование и контроль.

Новое доработанное издание этого списка отражает значительные изменения как в практике MRP II, так и в развитии инструментов ERP. Пятое издание контрольного списка ABCD Оливера Уайта для оценки качества деятельности предприятия целесообразно сделать неотъемлемой частью любой программы, которая ставит целью достижение предприятием мирового уровня в области применения информационных технологий и ведения бизнеса в целом.

Класс предприятия находится в зависимости от величины его потенциала QP, определяемого по формуле:

              5           m           n                                                                          

QP ={Σ  [Σ  (Σ QKi)/n]/m}/5   (      )

             k = 1     j = 1       i = 1                                                                        
 

j = 1,  m

i = 1,  n
 


                          (1)

                                                                 

Здесь:

 

QKi – потенциал конкретного бизнес процесса, принимающего значения 0, 1, 2, 3, 4 в соответствии с табл. 1;

n – число конкретных бизнес процессов, входящих в рассматриваемую группу бизнес

процессов, потенциал QOj которой определяется по формуле:

                              n

                  QOj = (Σ QKi)/n  (i = 1,n)                                (2);

                             i = 1     

m - число групп бизнес процессов, входящих в рассматриваемый блок бизнес процессов, потенциал QBk которого определяется по формуле: 

                                             m

                  QBk = [Σ QOj]/m (j = 1, m)                             (3);

                                            j = 1

k = 5 - число блоков бизнес процессов, определяющих деятельность любого рассматриваемого предприятия.

Если величина потенциала QP > 3.5, то предприятие находится на уровне класса А. При 3,49 > QP ≥ 2,5 предприятие находится на уровне класса В, при 2,49 > QP ≥ 1,5 - на уровне класса С, при 1,49 > QP - на уровне класса D

                                                                                     

Таблица 1.

Отлично

QKi  = 4

Наивысший ожидаемый уровень результатов от выполнения этого вида деятельности.

Очень хорошо

QKi  = 3

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

Удовлетворительно

QKi  = 2

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

Плохо

QKi  = 1

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

Не используется

QKi  = 0

Данный вид деятельности требуется, но в настоящее время не выполняется.

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

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

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

Каждая глава начинается с кратких качественных характеристик различных уровней деятельности – классов А, B, C, D – по интересующему блоку бизнес процессов. Затем перечислены обзорные вопросы по группе бизнес процессов. За кратким описанием группы бизнес процессов следуют детальные вопросы по конкретным бизнес процессам, входящим в анализируемую группу. Эти детальные вопросы предоставляют дополнительную информацию руководству, а так же средства для оценки конкретной деятельности предприятия, и составляют основную часть контрольного списка. Они составлены таким образом, чтобы обеспечить руководителей инструментарием для оценки основных характеристик каждого процесса, проверяя все важные для каждого процесса параметры и подробно анализируя, насколько эффективно используются при этом информационные технологии.

Данный метод оценки:

·      показывает работу, которая была проделана, даже если предприятие еще не достигло класса А;

·      показывает где и сколько работы требуется, чтобы достичь результата класса А;

·      обеспечивает средствами для дальнейшего улучшения, так как даже на уровне класса А еще есть места для улучшений.

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

·      участники должны быть специалистами, то есть им известны термины и методики, на которые идет ссылка в контрольном списке ABCD, а также они хорошо понимают, почему важно управлять процессами на очень высоком уровне;

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

Для отнесения рассматриваемого блока бизнес процессов к одному из указанных классов определяется средний балл по обзорным вопросам (группам бизнес процессов).

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

Учитывая изложенные выше положения, был проведен анализ работы предприятия. Результаты анализа выглядят следующим образом:

·      Стратегическое планирование - класс B (QB1 = 2.58) [6];

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

·      Люди / Команда  - класс С (QB2 = 1.92) [7];        

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

·      Общее управление качеством - класс С (QB3 = 2.25) [8];

Данные процессы осуществлялись в некоторых сферах деятельности предприятия с привлечением нескольких его поставщиков. Были достигнуты определенные улучшения.

·      Разработка новых видов продукции - класс B (QB4 =2.58) [9];

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

·      Планирование и контроль - класс B (QB5 = 2.94) [10].

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

Литература

1.  Верников Г. Обзор стандарта IDEF0. Интернет ресурс: IDEFinfo.RU.

2.  Черемных С.В. Структурный анализ систем IDEF-технологии.  М: 2001 «Финансы и статистика».

3.  Верников Г. Использование IDEF0 для описания и классификации процессов в рамках системы качества ISO 9000. Интернет ресурс: IDEFinfo.RU.

4.  Костюков В.Д., Островерх А.И., Воронцов А.В., Хоменко В.В., Цырков А.В. Предпроектное обследование предприятий при внедрении ИПИ–технологий. Ежемесячный научно-технический, производственный и справочный журнал: Приборы +Автоматизация. № 1 (91) 2008 г. Стр. 42 – 51.

5.  Костюков В.Д., Годин Э.М., Соколов В.П., Сокольский М.Л., Баранов А.П. CALS – технологии в технологической подготовке производства авиакосмической техники.; Под ред. Э.М. Година. – М.: Изд-во МАИ, 2005. – 552 с.: ил.

6.  ISBN 5-7035-1621-8

7.  Островерх А.И., Сычев В.Н., Костюков В.Д., Селиверстов А.И. Результаты анализа деятельности РКЗ ГКНПЦ им. М.В.Хруничева по внедрению информационных технологий //Научно-технический журнал: «Информационные технологии в проектировании и производстве», № 4 2005 г. С. 7-22.

8.  Костюков В.Д., Островерх А.И., Сычев В.Н., Лобова С.А. Результаты анализа блока бизнес-процессов "люди/команда" //Научно-технический журнал: «Информационные технологии в проектировании и производстве», № 3 2006 г. С. 8-19.

9.  Костюков В.Д., Островерх А.И., Сычев В.Н., Даутов Р.Х., Лобова С.А. Результаты анализа блока бизнес-процессов "общее управление качеством/продолжительные улучшения" //Научно-технический журнал: «Информационные технологии в проектировании и производстве», № 4 2006 г. С. 44-62.

10.   Костюков В.Д., Островерх А.И., Сычев В.Н., Воронцов А.В. Результаты анализа блока бизнес-процессов "Создание новых видов продукции" //Научно-технический журнал: «Информационные технологии в проектировании и производстве», № 1 2007 г. С. 24-43.

11.   Костюков В.Д., Островерх А.И., Сычев В.Н., Воронцов А.В. Результаты анализа групп бизнес-процессов "вовлеченность", "планирование продаж и операций"" блока "планирование и контроль" //Научно-технический журнал: «Информационные технологии в проектировании и производстве», № 4 2006 г. С. 25-35.