Анализ программных продуктов для автоматизации процесса ТОиР на предприятии ООО «ВторМет»

Для рассмотрения наиболее подходящего программного продукта, анализ будет проведен на рассмотрении шести программных продуктов, а именно:

• · iMaint — система управления ТО и ремонтами оборудования (http://www.imaint.ru/about);
• · IFS Applications, решение IFS — техническое обслуживание и ремонты (http://www.ifsrussia.ru/ifseam.htm);
• · Модуль «М-3: Управление Ремонтами» (http://www.kst-m3.ru/products_and_technologies/m-3_management_of_repair_work₁.html);
• · Система Ремонт-Эксперт (на базе 1C: Предприятие), (http://remontexpert.ru/content/view/8/4/);
• · * T-FACTORY 6 — управление основными фондами, техническим обслуживанием и ремонтами (http://www.adastra.ru/products/overview/EAM/);
• · Global-EAM — управление ремонтами и техническим обслуживанием оборудования (http://global-eam.ru/);

Данный перечень систем был предложен экспертной группой, которая принимала участие в исследовании на предприятии ООО «ВторМет». Прежде чем оценивать, какая систем будет наиболее подходящей для предприятия, необходимо обосновать важность той или иной системы в целом. ООО «ВторМет» по своему размеру является довольно крупным предприятием, имеющим региональные дочерние и зависимые предприятия. Всего более 40 предприятий. Имея 140 единиц оборудования, предприятию металлургической отрасли, где оборудование играет ключевую роль, важна четкая и своевременная информационная поддержка. Если рассматривать модуль ТОиР, входящий в какой-либо класс определенной системы, то, очевидно, функции по управления ТОиР будут значительно сокращены [9] Например, многие поставщики ERP систем заявляют о наличии в их продукте модулей планирование ТОиР. Но анализ опыта внедрения ERP-систем для управления техническим обслуживанием и ремонтами на российских предприятиях показывает не совсем радостную картину. Процессом функционирования системой довольны экономисты, бухгалтера и все остальные сотрудники, но только не те, кто непосредственно занят в ТОиР. Возможно, к примеру, получившаяся система описывает наличие необходимых материалов, обеспечивает персонал еще какой-либо информацией по управлению ремонтами. Однако, она мало что даст ремонтному персоналу, который не сможет с помощью системы планировать работы, оформлять документы, либо учесть тонкости всего бизнес-процесса. Не имея ремонтный модуль основным в системе ERP, вопросы управления ТОиР вытесняются на задний план, ввиду сложности. Именно этот факт позволяет обосновать необходимость внедрения на предприятии специализированной EAM системы, которая будет включать все необходимые функции для проведения всех работ по ТОиР и анализу эффективности.

1. Система iMaint.

Физические требования.

Что касается аппаратной платформы, то в данной системе размер по оперативной памяти от 1гб для сервера и 256 мб для рабочей станции. По программной платформе система работает на базе Windows. В качестве требования это Windows 2000 Server. Для Сервера базы данных, при условии ОС Windows 2000, требования по СУБД включают такие разновидности, как MS SQL Server 2000 SP3 или выше, либо Oracle 8.1.7. Для поддержания web-сервера необходим IIS — интернет сервер.

Функциональные требования.

Настоящая система управления ремонтами оборудования обеспечивает модулем активов, в котором можно содержать стандартную информацию по вопросу производственных фондов; позволяет контролировать запчасти и управление запасами на предприятии. Модуль планирование ремонтов позволяет составлять планы ремонтов и графики ТОиР. Далее в системе содержится модуль заказа-наряда; закупок и снабжений. Возможность получения отчетов и графиков в системе позволяет собирать и анализировать данные о ремонтных мероприятиях и затратах на них. Учет оборудования и запчастей также имеется. Как видно, в системе отсутствуют какие-либо модули по анализу выполненных работ, качества работ, контролю выполнения работ и контроль технического состояния объектов. Также отсутствует какая-либо информация по поводу согласования документов в системе.

Требования к удобству использования.

На сайте в описании системы нет конкретной информации по удобству интерфейса.

Требования к поддержке.

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

Требования к поставщику. Требования к разработке.

Нет точной информации по наличию партнеров, но деятельность самой консалтинговой компании по внедрению охватывает территорию России, страны СНГ и Балтии. Пользователями системы являются многие отрасли промышленных предприятий — от Энергетики до Жилищно-коммунального хозяйства не только России, но и зарубежных стран. Здесь такие известные компании, как Volvo, KRAFT, Coca-cola, Однако детальная история успеха внедрения системы в отечественной компании является только одна — внедрение системы в компании ОАО «Хлебный дом». Длительность и сложность внедрения зависит от масштабности предприятия. Описание методологии внедрения не дает конкретных чисел, в какой срок можно реализовать внедрение. Также отсутствуют конкретные примеры. Обучение персонала, разумеется, также предусмотрено. Но конкретной цифры длительности обучения не приводится. В самом внедрения производится экспресс-обследования предприятия и система настраивается под нужды бизнес-процесс. Значительных изменений в нем не происходит.

Требования к связи с внешними источниками.

Примерами систем, подлежащих интеграции, могут быть — бухгалтерские программы и учетные системы, системы класса ERP, системы управления персоналом, логистические системы. Наверное, система предусматривает механизм интеграции с офисными программами, но об этом ничего не сказано в описании.

2. IFS Applications.

Физические требования.

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

Функциональные требования.

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

Требования к удобству использования.

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

Требования к поддержке.

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

Требования к поставщику. Требования к разработке.

Компания имеет множество эффективных внедрений, всю информацию можно посмотреть на сайте. Но в основном опыт получен от сотрудничества с зарубежными компаниями, такими как Tomra Systems, Three Gorges, APTransco и прочих. Нет точных сведений о сети партнеров, но тот факт, что они осуществляют глобальную поддержку, говорит о их наличии. Как уже было сказано, компонентная архитектура системы позволяют очень гибкую настройку только тех компонентов системы, которые необходимы заказчику. При внедрении системы происходит параллельное обучение пользователей за счет учебных материалов по системе. Система подстраивается под бизнес-процесс предприятия, критических изменений не происходит.

Требования к связи с внешними источниками.

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

3. Модуль «М-3».

Функциональные требования.

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

Требования к удобству использования.

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

Требования к поддержке.

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

Требования к поставщику. Требования к разработке.

Компания имеет не одно успешное внедрение на территории России. Это такие предприятия как ОАО НПО «Искра», ООО «Тольяттикаучук», ОАО «Уралбурмаш». Обучение персонала производится после внедрения системы. Что касается изменения бизнес-процесса предприятия как такового, то компания предлагает несколько моделей внедрения: модель внедрения в рамках поставки стандартного пакета модулей, реализованных в системе М-3, что подразумевает значительную настройку системы под бизнес-процесс, либо модель внедрения с правом проектирования и модификации бизнес-процессов.

Требования к связи с внешними источниками.

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

4. 1С: ТОиР.

Физические требования.

Из описания системы, которое предложено на сайте, понятно, что система не имеет технических ограничений по числу хранимой информации и возможному числу пользователей. Работает с промышленной СУБД MS SQL Server.

Функциональные требования.

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

Требования к удобству использования.

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

Требования к поддержке.

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

Требования к поставщику. Требования к разработке.

Компания имеет успешные внедрения в части ТОиР. Это внедрения на таких предприятиях, как ООО «Балашихинский водоканал», ООО «Лиотех», Торгово-выставочный комплекс «ЭКСПОСТРОЙ», ЗАО «АБИ-Продакт», ЗАО «Свинокомплекс Короча». И это далеко не полный перечень предприятий, на котором данная система внедрена. Как уже было сказано, поддержка системы осуществляется довольно легко, потому что адаптировать систему «на месте» смогут почти все программисты 1С.

Требования к связи с внешними источниками.

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

5. T-FACTORY 6.

Физические требования.

Исполнительные модели T-Factory 6 условно делятся на серверы и клиенты (консоли). И клиентское и серверное программное обеспечение разрабатывается в единой интегрированной среде разработки и имеет единую базу распределенных переменных. Подобная архитектура дает удивительную гибкость в разработке распределенных система управления, так как позволяет создавать АСУ в различных архитектурах (по выбору):

• · локальная;
• · распределенная клиент-сервер;
• · распределенная DCS;
• · телемеханическая;

Система хранения информации спроектирована специально для работы в режиме реального времени непрерывно. Она обладает собственной высокоскоростной промышленной СУБД SAID/SQL 6.

Функциональные требования.

Функции EAM в T-Factory:

• · Ведение паспортов оборудования;
• · организация документооборота;
• · накопление EAM-статистики эксплуатации, простоев, отказов и технического обслуживания оборудования;
• · учет стоимости материалов и работ;
• · списание и учет МТР;

Система позволяет автоматизировать учет основных фондов, снизить простои, повысить производительность оборудования, снизить эксплуатационные расходы.

Требования к удобству использования.

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

Требования к поддержке.

Компания — дистрибьютор AdAstrA Research Group заботится о том, чтобы пользователи систем T-Factory получали максимальную пользу от приобретенного ПО. Техническая поддержка предоставляется на русском, английском и китайском языках каждому зарегистрированному пользователю, вне зависимости от места приобретения ПО. Пользователь могут получить дифференцированную техническую поддержку — стандартную техническую поддержку (бесплатно), индивидуальную и корпоративную. Стоимость стандартной технической поддержки уже включена в цену программ и не требует никакой дополнительной оплаты.

Требования к поставщику. Требования к разработке.

На базе всей системы TRACE MODE компании AdAstrA Research Group внедрено множество АСУ ТП, в том числе для таких лидеров металлургических отраслей как:

• · ОАО Северсталь (Россия);
• · Оскольский металлургический комбинат (Россия);
• · Белорецкий металлургический комбинат (Россия);

и прочих.

Поддержку пользователей осуществляет как собственная Служба технической поддержки компании AdAstrA Research Group, так и ее авторизованные партнеры. Для технической поддержки пользователей TRACE MODE используются все доступные средства коммуникации: телефон, факс, электронная почта, а также Форум технической поддержки в Internet. Также с 1993 года компания предлагает Авторизованные учебные центры TRACE MODE. Они расположены в разных городах России. Учащиеся обеспечиваются методической документацией и программным обеспечением.

Требования к связи с внешними источниками.

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

6. Global-EAM.

Физические требования.

Система Global-EAM ориентирована на крупные и средние предприятия с количеством оборудования более 4'000 единиц и охватывает все процессы производственного предприятия, связанные с техническим обслуживанием и ремонтами оборудования. Система Global-EAM работает под управлением СУБД ORACLE 10g, создана по технологии «тонкий клиент» на базе среды визуальной разработки приложений Global-Frame Work. Рекомендуемая конфигурация сервера см. Рисунок 12:

Рисунок 12 Рекомендуемая конфигурация сервера Для рассмотрения минимальных требований к клиентскому месту см. Рисунок 13:

Рисунок 13 Минимальные требования к клиентскому месту Функциональные требования.

Функциональные модули Системы Global-EAM для автоматизации работ по ТОиР:

• · Учет активов оборудования/паспортизация;
• · Планирование работ по ремонту и ТО, расчет графиков ППР;
• · Управление работами;
• · Мониторинг технического состояния;
• · МТО ТОиР;
• · Анализ данных, ключевые показатели эффективности;
• · Электронный архив документов;

Требования к поддержке.

Система предназначения для средних и крупных предприятий с количеством оборудования более 4000, система является легко масштабируемой. Кроме того, это может быть как отдельный модуль Global EAM ТОиР, так и может быть частью мощной системы ERP-системы Global.

Требования к поставщику. Требования к разработке.

Клиентами системы являются многие отечественные предприятия, такие как АгроСиб-Раздолье ООО, Амурагроцентр ООО, Апи-Сан ООО, ИМС — Группа компаний. Компания Бизнес Технологии уделяет особое внимание оказанию качественной технической и консультационной поддержки, потому что это гарантия стабильного функционирования и успешного развития информационной системы. Именно профессиональная поддержка обеспечивает снижение рисков заказчиков, экономит их время и средства. Система подстраивается под бизнес-процесс предприятия, так как в процессе внедрения происходит настройка системы в соответствии с бизнес-процессом ТОиР на предприятии. Партнерами компании являются: ООО Бизнес Технологии в г. Санкт-Петербурге, а также Группа компаний АйтиКонсалт в г. Самара. Курсы обучения могут быть проведены как в учебном классе компании Бизнес Технологии в Санкт-Петербурге, так и непосредственно на объекте Заказчика. Обучение работе с Global-EAM проводят преподаватели Бизнес Технологии с использованием оригинальных методических материалов.

Требования к связи с внешними источниками.

Немаловажным преимуществом информационной Системы Global-EAM является готовность ее к интеграции практически с любыми сторонними программами и оборудованием на основе общепризнанных открытых стандартов и протоколов передачи данных. Осуществляется доступ ко всем объектам Системы Global-EAM, и к внешним системам из Global посредством обращения на уровне СУБД, APIи COM-вызовов. Также имеется встроенная интеграция с продуктами MS Office, почтовыми клиентами, средствами коммуникации.

Для начала определим наличие необходимых функциональных требований в рассматриваемых программных продуктах, так как они играют ключевую роль для предприятия:

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

Таблица 10.

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

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

• · Global-EAM;
• · 1С: ТОиР;
• · T-FACTORY 6;
• 3.3 Обоснование выбора программного обеспечения для автоматизация процесса управления ремонтами оборудования на предприятии ООО «ВторМет» методом анализа иерархий и методом получения интегральной оценки
• 1. Метод получения интегральной оценки.

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

• 0 — функция отсутствует в имеющейся конфигурации;
• 2 — функция реализована частично, для ее реализации необходима серьезная доработка;
• 4 — функция реализована частично, для ее реализации необходима незначительная доработка;
• 6 — функция реализована удовлетворительно, требуется адаптация под нужды Предприятия в процессе настройки/внедрения средствами ИСУ;
• 8 — функция реализована хорошо, однако в перспективе могут понадобиться ее доработки;
• 10 — функция реализована полностью, удовлетворяет требованиям (в том числе — на перспективу).

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

Таблица 11.

Получение интегральной оценки программных продуктов.

№.	Наименование критерия.	Global-EAM.	1С: ТОиР.	T-FACTORY 6.
1.	Функциональность.	Оценка соответствия системы по 10-бальной шкале.
1.1.	Планирование проведения ремонтных работ на объекте.	10*3.	7*3.	5*3.
1.2.	Контроль выполнения ремонтных работ, учет объемов выполненных работ, учет затрат, приемка результатов.	10*3.	5*3.	8*3.
1.3.	Анализ качества выполнения ремонтных работ.	8*3.	5*3.	7*3.
1.4.	Контроль технического состояния объектов КП.	10*3.	7*3.	5*3.
1.5.	Планирование затрат.	7*3.	5*3.	5*3.
1.6.	Согласование документов.	10*3.	8*3.	8*3.
1.7.	Оперативных учет и списание МТР.	8*3.	6*3.	6*3.
3.	Требования к поддержке.
3.1.	Масштабирование в пределах дочерних предприятиях/филиалах.	10*3.	3*3.	5*3.
3.2.	Максимальное количество пользователей.	10*3.	10*3.	10*3.
3.3.	• Функция сопровождения системы после внедрения.	10*2.	10*2.	5*2.
4.	Стоимость владения программным продуктом.	6*2.	6*2.	8*2.
5.	Требования к поставщику.
5.1.	• Успешные внедрения в • аналогичной отрасли	10*2.	6*2.	10*2.
5.2.	Наличие сети партнеров.	4*2.	3*2.	5*2.
6.	Требования к разработке.
6.1.	Длительность и сложность внедрения.	8*3.	3*3.	5*3.
6.2.	Длительность и стоимость обучения персонала.	8*3.	6*3.	5*3.
6.3.	Необходимость изменения бизнес-процесса.	8*3.	4*3.	4*3.
6.4.	Функция сопровождения системы после внедрения.	10*3.	8*3.	5*3.
7.	Требования к связи в внешними источниками.
7.1.	Возможность связи с привычным для сотрудников MS Office.	10*3.	10*3.	5*3.
7.2.	Необходимость интеграции с имеющимися системами.	10*3.	10*3.	5*3.
8.	Физические требования.
8.1.	• Наличие вэб-сервера.	10*3.	3*3.	5*3.
8.2.	СУБД.	8*3.	10*3.	7*3.
8.3.	Совместимость с существующей аппаратной платформой.	6*3.	7*3.	7*3.
8.4.	Совместимость с существующей программной платформой.	7*3.	8*3.	7*3.
Интегральная оценка с учетом коэффициентов.

Интегральная оценка программных продуктов позволила сделать решающий выбор в отношении программного обеспечения для автоматизации бизнес-процесса «Управление ремонтами оборудования» на предприятии ООО «ВторМет». На сегодняшний момент наиболее подходящей системой, с точки зрения полноты функциональности и соответствия остальным критериям сравнения, является система Global-EAM.

2. Метод анализа иерархий.

Описание программных продуктов по критериям сравнения будет использоваться экспертами в методе МАИ.

Идея МАИ была предложена американским математиком Т. Саати около 35 лет назад [10]. Данный метод эффективный и доступный, он не требует особых математических знаний. Его основное назначение — решение слабоструктурированных задач принятия решений. Данный метод заложен в основу программной системы «MPriority 1.0», которую можно применить, решая следующий класс задач:

• 1) имеется некоторое начальное множество альтернатив (объектов, стратегий) X, среди которых необходимо произвести выбор наилучшей альтернативы или провести ранжирование альтернатив по предпочтению лица, принимающего решение (ЛПР);
• 2) задана главная цель, исходя из которой производится выбор или ранжирование;

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

3) задано некоторое множество критериев, которые учитываются при выборе или ранжировании альтернатив множества Х.

Таким образом, учитывая главную цель и критерия необходимо произвести выбор наилучшей альтернативы из множества Х. Либо проранжировать их по значимости. В программной системе, основанной на методе МАИ, структура поставленной задачи состоит из иерархий. Они необходимы для выявления отношений между уровнями, чтобы в итоге можно было сделать цельный вывод, исходя из выявленных связей. Поэтому основное назначение иерархии в МАИ — оценка высших уровней иерархии, исходя из взаимодействия её низших уровней. В случае рассматриваемой темы основной целью будет выбор программного продукта для автоматизации бизнес-процесса ТОиР на рассматриваемом предприятии. Подцелями или критериями для достижения цели будут выступать критерия сравнения программного продукта. Так, если реализовать поставленную цель в программе MPriority 1.0, иерархий по количеству будет три (См. Рисунок 14): 1) основная цель — выбор ПО; 2) критерии — критерии сравнения ПО и 3) самый низкий уровень — альтернативы программных продуктов:

Рисунок 14 Иерархия МАИ для выбора ПО автоматизации ТОиР Следующий этап в достижении цели является осуществление попарного сравнения отдельных компонент иерархии. Эксперт сравнивает все пары объекты второго уровня иерархии по некоторому критерию, указывая каждый раз более предпочитаемый объект. На рисунке ниже представлены попарные сравнения второго уровня иерархии.

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

После сравнения всех объектов, эксперт получает вектор приоритетов. Согласно вектору можно определить наиболее важный критерий. А также просто посмотреть, как они ранжированы.

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

Как видно, вектор приоритетов самого нижнего уровня — в данном случае уровень альтернатив, где сравниваются между собой программные продукты — позволяет получить значимость того или иного программного продукта. Сравнив попрано каждый программный продукт относительно каждого критерия, получаем результаты в отношении того, какой продукт наиболее предпочтен относительно определенного критерия. Данные результаты, полученные на основе экспертного анализа в программе MPriority, помогут сделать выбор относительно программного продукта.