Я хотел создать интригу, добавляя в название статьи незнакомые слова. Думал, если напишу «эвристический метод», то это будет интригующе. По мере моего повествования вы поймете, что уже сталкивались с этим и даже использовали, просто не называли это эвристическими методами.
Поговорим об экспертных методах оценки, отдельный класс которых основан на эвристиках.
Эвристики – это оценки и суждения экспертов, основанные на интуиции. Интуиция, в свою очередь, основана на знаниях, опыте, вдохновении и чем-то еще. Речь пойдет о том, как использовать эти методы для решения сложных технических и творческих задач, в частности – для выбора прикладной архитектуры при проектировании целевой автоматизированной системы.
Статья состоит из трех частей:
-
В первой части я расскажу, что такое прикладная архитектура как объект исследования, почему возникает несколько вариантов и зачем их сравнивать,
-
Во второй – о двух наиболее популярных метода экспертной оценки, которые обычно применяются,
-
В третьей – о методах выбора и сравнения вариантов прикладной архитектуры.
Понятие прикладной архитектуры и ее роль в IT-проектах
Начнем с того, что такое прикладная архитектура. В этом случае следует обратиться к международному стандарту TOGAF. Этот стандарт посвящен вопросам управления информационными системами предприятий.
Согласно этому стандарту, IT-архитектура предприятия представляет собой сложную конструкцию, выстроенную как многослойный пирог, состоящий из множества доменов. На изображении показаны основные домены: бизнес-архитектура предприятия, информационная архитектура, прикладная архитектура и технологическая архитектура. Каждая из них, в свою очередь, описывается другими видами архитектур более низкого уровня.
Если рассматривать прикладную архитектуру, то при ее проектировании обычно описывают функциональную архитектуру, архитектуру приложений, интеграционную архитектуру и архитектуру развертывания. Когда выполняются IT-проекты, вносятся изменения в предприятие, в том числе и в его IT-архитектуру. В большей степени изменения касаются именно прикладной архитектуры, потому что предлагаются новые решения, заменяющие старые исторические системы, или выполняется апгрейд устаревших решений. То есть прикладная архитектура, как правило, меняется в ходе проекта.
Начинается это с разработки концепции целевой архитектуры автоматизированной системы, которую согласовывают с заказчиком.
Это могут быть схемы, описывающие функциональную архитектуру, прикладную архитектуру, взаимосвязи между решениями и другие аспекты.
Здесь возникает вопрос: мы предлагаем, например, ERP, но почему не Комплексную автоматизацию? Почему не ERP.УХ? Возникает несколько вариантов решения одних и тех же задач. Обычно от коллег можно услышать доводы вроде «поверьте моему экспертному опыту» или «наш системный архитектор видел и не такое». Такие аргументы кажутся малоубедительными. Поэтому нужно что-то более обоснованное, чтобы выбрать оптимальную архитектуру – в данном случае прикладную архитектуру целевой автоматизированной системы.
Важно понять, на каком этапе все это начинается – когда именно мы начинаем разрабатывать и предлагать целевую архитектуру.
Этапы проектирования по ГОСТ и ответственность за выбор архитектуры
Поскольку подходов в проектных технологиях много, я взял на себя смелость обратиться к ГОСТ 34-й серии, точнее к стандарту, который описывает стадии и этапы создания автоматизированной системы. На что здесь следует обратить внимание:
-
Первая стадия посвящена вопросам сбора и формирования требований пользователей,
-
Вторая стадия – разработке концепции автоматизированной системы.
ГОСТ четко описывает, что необходимо разработать варианты концепции автоматизированной системы и выбрать вариант, удовлетворяющий требованиям пользователей.
Коллеги, как правило, объединяют эти две стадии в одну и именуют это предпроектным обследованием. Скорее всего, вы делаете то же самое.
Когда мы говорим о стадии предпроектного исследования, мы уже говорим о проектировании хотя бы на верхнем, концептуальном уровне целевой прикладной архитектуры (и не только прикладной). В дальнейшем эта концепция уточняется: на стадии разработки технического задания она преобразуется в требования к системе, на стадии технического (эскизного) проекта – в проектные решения, далее разрабатывается рабочая документация и выполняется ввод в действие. Таким образом, архитектура от стадии к стадии уточняется и детализируется. Но самый ответственный момент как раз на стадии разработки концепции.
Простые экспертные методы: непосредственная оценка и парные сравнения
Что поможет в этой дилемме выбрать оптимальную архитектуру прикладных решений? Для этого можно использовать методы экспертных оценок. Их применяют в случаях, когда другие методы, в том числе экспертные, нецелесообразны, слишком длительны или невозможны: когда объекты сложные, плохо описаны количественными параметрами, в основном имеют качественные параметры, слабо формализованы и слабо структурированы.
Вы с ними наверняка сталкивались, когда учитель в школе ставил оценки. В моей бытности это была пятибалльная шкала: пять – отлично, четыре – хорошо и так далее. Это и есть эвристический метод экспертной оценки. Сейчас в школах используется десятибалльная шкала, но суть остается той же.
Первый метод называется методом непосредственной оценки. Учителя в школах используют именно его. Он называется «непосредственный», потому что не требует никаких преобразований или манипуляций с оценками. Как выставили баллы – так они и используются.
В таблице приведен пример оценки пяти программных продуктов пятью экспертами по десятибалльной шкале. Каждый продукт оценивается по одному критерию. Баллы по строкам суммируются, результаты ранжируются, и определяется победитель с максимальным количеством баллов. Все просто. Такой метод вы, скорее всего, применяли.
Следующий метод – метод парных сравнений. Он так называется, потому что объекты сравниваются друг с другом. В этом случае используется ранговая оценка – когда один объект сравнивается с другим на предмет предпочтения. Например, если взять объект А1, его последовательно сравнивают с А2, А3 и А4. Если в таблице стоит единица, это значит, что объект А1 предпочтительнее по сравнению с А2, А3 и А4. При обратном сравнении, в ячейках под диагональю, стоят нули – эти объекты менее предпочтительны, чем А1. Метод простой и часто используется.
Есть важный нюанс – вопрос достоверности экспертных оценок. Достоверность – это вероятность истинного ответа. На достоверность влияют три основных фактора:
-
Уровень квалификации экспертов. Нельзя ожидать достоверных результатов, если пригласить случайных людей с улицы и попросить их оценить функциональность программного решения. Эксперты должны быть компетентны в соответствующей предметной области.
-
Уровень знания о сравниваемых объектах или явлениях. Эксперты должны изучить объекты сравнения, чтобы вынести взвешенное суждение. Поскольку интуитивная оценка основана на знаниях и опыте, этот фактор особенно важен.
-
Количество экспертов. Чем больше участников, тем выше достоверность. Здесь работает статистический подход: в диапазоне экспертных оценок, а точнее в их математическом ожидании, находится наиболее вероятный истинный ответ.
Переход к многокритериальной оценке
В жизни все гораздо сложнее, потому что мы часто сталкиваемся с объектами, описываемыми множеством параметров.
Вспомните, как вы выбирали сотовый телефон. Сколько параметров имеет даже такая простая, казалось бы, конструкция – множество. Они различаются по размерности, виду, характеристикам. Что вы делали? Анализировали параметры, выделяли важные для вас, сравнивали и интуитивно делали выбор. Такой подход мы используем постоянно – выбирая стиральную машину, автомобиль и так далее.
Даже выбирая спутника жизни, человек пользуется своими «оценочными шкалами». Вспомните песню группы «Комбинация»: «Чтоб не пил, не курил и цветы всегда дарил» – это и есть набор параметров, по которым женщины оценивают мужчин.
В быту интуитивный выбор и возможные ошибки допустимы: выбрал не тот телефон – не страшно, ошибся с выбором партнера – тоже поправимо. Но в профессиональной деятельности этого недостаточно. Там требуется подход, основанный на доказательствах и обосновании.
Для этого применяются методики многокритериальной оценки, которые позволяют обоснованно сравнить и выбрать оптимальный вариант из нескольких объектов или явлений.
Что для этого требуется:
-
Перечень сравниваемых объектов
-
Перечень критериев
-
Шкала оценок по критериям
-
Суждения о важности критериев
-
Суждения о взаимосвязях критериев
Очень важно четко описать шкалы.Если используется бальная или ранговая оценка, экспертам нужно объяснить, что означает, например, «10» и что означает «1» по десятибалльной шкале, чтобы все понимали эти оценки одинаково.
Выбор критериев также имеет значение. Их много, и важно не только подобрать подходящие, описывающие объекты, но и учитывать их взаимосвязь. Если сравнивать объекты по двум сильно коррелирующим критериям, например срок внедрения и стоимость внедрения, то они усиливают влияние друг друга, повышая общий вес оценки и подавляя другие критерии.
Также важно определить суждения о важности критериев – не все они равнозначны: одни более важные, другие менее. Все это необходимо учитывать при применении методов многокритериальной экспертной оценки.
Сложности многокритериальной оценки и отличие методик от методов
Какие сложности возникают при применении методов многокритериальной оценки?
-
Критерии различаются по важности. Это уже упоминалось ранее.
-
Оценки различаются по виду. Мы можем использовать качественные оценки («плохо – хорошо», «низко – высоко»), бальные, ранговые или числовые – например, стоимость. Все они различаются по виду. Если взять пример сотового телефона, параметры вроде диагонали экрана и емкости аккумулятора выражаются в разных числовых величинах.
-
Числовые оценки различаются по размерности. Это могут быть доли, целые числа, тысячи, миллионы и так далее.
-
Сложность количественного измерения взаимосвязей между критериями.
Все эти факторы создают трудности при сравнении и требуют применения не просто методов, а методик.
Чем методика отличается от метода. Метод – это отдельный способ решения задачи. Методика – это процедура, объединяющая применение нескольких методов и инструментов. Хотя деление условное, поскольку некоторые методы описаны как методики и наоборот.
Применение методик направлено на то, чтобы повысить достоверность выводов и минимизировать негативные факторы, влияющие на результаты оценки.
Методика анализа иерархий (МАИ)
Первая методика, с которой я хотел бы вас познакомить, – методика анализа иерархий.
Почему она так называется? Это видно на схеме: используется иерархическая структура:
-
На верхнем уровне находится цель анализа, которую необходимо сформулировать,
-
На втором уровне выделяются критерии, по которым будут сравниваться объекты. Для примера приведены три критерия: стоимость, функциональность и удобство использования.
-
На третьем уровне располагаются объекты сравнения – в данном случае программные продукты. Сравнивать можно любые объекты: отдельные программы, пакеты, технические решения – ограничений нет.
Методика состоит из четырех шагов:
-
Выполняется структуризация задачи – построение иерархической схемы, показанной на рисунке.
-
Определяются оценки важности критериев – расчет весов в виде коэффициентов.
-
Оценка объектов по каждому критерию с помощью экспертных оценок.
-
Находятся глобальные приоритеты всех элементов задачи – произведение оценок объектов на весовые коэффициенты важности критериев.
На рисунке приведены таблицы, используемые при расчетах.
В верхней таблице методом парных сравнений оценивается важность критериев. Используется девятибалльная ранговая шкала. Три критерия (стоимость, функциональность, удобство использования) сравниваются попарно, после чего оценки переводятся в десятичные дроби, усредняются и рассчитываются локальные приоритеты, определяющие веса критериев. Наиболее важным критерием здесь является функциональность (К2) – у нее максимальный вес.
Средняя таблица – пример оценки объектов по одному из критериев. Также применяется метод парных сравнений по девятибалльной шкале. Например, при сравнении программных продуктов по фактору стоимости видно, что ПО №1 получает наибольшее предпочтение, так как оно самое дешевое.
В нижней таблице рассчитываются глобальные приоритеты – оценки объектов по каждому критерию умножаются на весовые коэффициенты.
В результате формируются суммарные значения, которые можно проранжировать и сделать вывод: наибольший глобальный приоритет (0,32) имеет программный продукт №1, значит, ему можно отдать предпочтение.
Таким образом, методика анализа иерархий позволяет сравнивать не только программные продукты, но и любые другие объекты – технические решения, проекты, даже людей.
Метод комплексной оценки
Следующий метод называется метод комплексной оценки. Он немного сложнее, но его преимущество в том, что позволяет работать с критериями разного вида и размерности. Метод интересный и заслуживает применения.
Метод комплексной оценки в целом похож на методику анализа иерархий:
-
Определяются оценки важности критериев
-
Критерии приводятся к безразмерному виду
-
Определяются веса критериев, отражающие разброс оценок
-
Находятся обобщенные веса критериев
-
Рассчитываются взвешенные оценки объектов
-
Находятся комплексные оценки объектов
В этом методе также определяется важность критериев и проводится оценка объектов по этим критериям. Однако в нем есть два дополнительных шага, позволяющих:
-
привести критерии к безразмерному виду,
-
максимизировать или минимизировать показатели, переводя их в сопоставимые количественные значения.
После этого выполняется сравнение объектов по полученным показателям и на заключительном этапе рассчитывается комплексная оценка каждого объекта, на основе которой делается вывод.
На изображении приведен пример из учебной работы одного из учащихся моего курса. В ней сравнивались три программных продукта:
-
ERP,
-
«Комплексная автоматизация» + «Бит.Финанс»,
-
модульное решение «Бухгалтерия» + «УТ» + «Бит.Финанс».
На заключительном этапе расчетов комплексной оценки оказалось, что модульное решение получило наибольшее значение и, следовательно, было рекомендовано к использованию.
При этом важно учитывать допущения. В учебных примерах эксперты – это слушатели курса, среди которых есть продавцы, руководители проектов и другие специалисты, не всегда знакомые с прикладными решениями. Поэтому в реальных условиях необходимо тщательно подбирать экспертов, включая представителей не только проектной команды исполнителя, но и команды заказчика. Также следует соблюдать все условия, повышающие достоверность оценки.
Практический кейс и работа с возражениями
Несколько лет назад при обследовании крупной федеральной торговой компании проводилось сравнение вариантов целевой архитектуры. По результатам работы специалисты рекомендовали один из вариантов, опираясь на собственную методику анализа. Результаты были представлены заказчику на презентации, где обсуждались выводы и обоснования предложенного решения.
Во время защиты проекта один из участников совещания заявил, что всю предложенную схему можно «нарисовать за пятнадцать минут». Его комментарий фактически обесценивал проделанную работу.
Ситуация заключалась в том, что мы плотно работали с Департаментом информационных систем (ДИТ), и они запускали дальше, чтобы собрать ожидания других заинтересованных сторон. Позже выяснилось, что этот человек был совладельцем компании. Он не знакомился с отчетами и, вероятно, видел только презентацию, поэтому выводы специалистов показались ему излишне сложными и нецелесообразными.
Подобные ситуации нередки в проектной практике и, как правило, связаны с вопросом ожиданий заказчиков. Но нас ограничили в работе с ожиданиями со всеми заинтересованными сторонами, то вышло так, как вышло.
Ответ на возражение был сформулирован спокойно и сдержанно: «Готовы ли вы взять личную ответственность за то, что нарисуете за 15 минут? Мы реализуем предложенную вами схему, если вы готовы отвечать за результат».
Как показывает практика, вопрос персональной ответственности часто снимает чрезмерно самоуверенные претензии. В данном случае проверить эту гипотезу не удалось – работа с заказчиком не была продолжена.
Поэтому при выборе архитектурных решений целесообразно использовать описанные методы экспертных оценок. Эти подходы достаточно просты в применении, экономичны и не требуют значительных затрат, но при этом позволяют обосновать выводы аргументированно и профессионально. Такой подход отражает не только качество аналитической работы, но и соблюдение принципов профессиональной этики при взаимодействии с заказчиком.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.