Рассмотрим типовой случай выбора системы в какой-то ИТ-ландшафт. Есть поставщик с одной стороны, и потребитель с другой. Например, АБС(и ее поставщик) в средний банк Российской Федерации (потребитель).

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

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

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

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

Постановка задачи оценки решений выглядит так :

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

**Рис.1. Архитектура критериальной модель оценки**

Рассмотрение ключевых участников начнем с поставщика.

У поставщика есть продукт, который он хочет продать, в как можно большее количество организаций. Что он будет точно делать в этом случае? Разумеется, трансформировать все особенности(изюминки, "фичи" и т.д.) своего решения в условные конкурентные преимущества. Например, "У меня гибкая настройка системы". Может получится, что достаточно ловкий «продажник» от поставщика «продаст» не очень опытному в технике представителю потребителя «кулек» красивых "фич", но при этом часть технических задач на стороне потребителя так и останется нерешенной. "НеТехнарь", а обычно окончательное решение принимает именно он, может этого и понять, там же такая классная штука. «Почему не сыграл мой козырной туз? А мы в шашки играем». Т.е. очень важно понять список задач, которые нужно решить на стороне потребителя (его требования) и рассматривать каждое решение именно в этой системе координат.

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

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

Критериями в нашей модели должны быть задачи, важные для потребителя (надежность, реализация бухучета, ИТ-суверенитет)
В каждом продукте, представленном как «кандидат» в Gруппу, нужно оценить решение или реализацию этих задач, важных для поставщика

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

На самом деле мы имеем на лицо две реализации одной задачи, и оценивать нужно именно то, насколько каждая реализация задачи подходит потребителю. Еще пример из обычной жизни: для автомобиля имеем задачу «Движение», для которой нужен движитель. У одного поставщика дизель, у другого бензиновый двигатель, а у третьего вообще электроМобиль. Имеем три решения(дизель, бензин, батарейка) одной задачи(движение), каждая со своими плюсами и минусами. Вот на эти плюсы и минусы и нужно смотреть. Электромобиль в деревеньке, так себе решение – где-то надо заряжаться, да и имеют место быть перебои с электричеством, а в городе-герое Москве вполне нормально.

Таким образом, ключевая «формула» оценки системы по критериальной модели: реализация требований/задач потребителя в конкретной системе.

При такой ситуации (прямо скажем типовой) нужен арбитр, который

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

**Рис.2. Операционная модель изменений в критериальной модели.**

Если у нас неизбежный двусторонний диалог, формирование критериальной модели идет со стороны и поставщика,и потребителя, надо и договориться и "ребенка" не выплеснуть. Рассмотрим два сценария в этом процессе с двух сторон: инициация изменений в критерии оценки со стороны поставщика и со стороны потребителя.

Поставщик

Интересы поставщика вполне очевидны: продать продукт, отбить инвестиции в «изюминки» своего продукта и на всем этом в конце концов заработать.

Отсюда следует что, все предложения со стороны поставщика должны пройти проверку на «Фичу». Т.е. поставщик хочет включить свою "фичу" в модель оценки, что бы она была включена в модель как обязательная и он в итоге получает конкурентное преимущество. Вряд ли в Gруппе это нужно. Проверка выглядит достаточно просто:

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

Потребитель

Теперь требования со стороны потребителя – кажется все понятно, но часто я сталкивался со следующей проблемой: требование заказчика является не задачей, а опять таки решением какой-то другой задачи, которая у него в голове. Т.е. получается мы фиксируем таблетку, но не поняли, что за болезнь и нужна ли вообще таблетка? Например, пациент говорит врачу – болит нога, врач говорит – вот эта мазь. Ни анализов, ни анализа, сразу лечение. Как-то неопрятно. Нужно же разобраться: это нога болит или сердце так «отдает» в ногу? Пример из техники : мне нужна интеграция в Active Directory. Хорошо. А зачем ? Нужна аутентификация. Так что включим в критерий оценки: Active Directory или аутентификацию? Очевидно задачу (аутентификация), а не один из способов ее решения (Active Directory).

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

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

В комплект поставки "Федерации" добавляем архитектуру критериальной модели рис.1 и операционную модель, по работе с этой моделью рис.2. Саму модель рассмотрим в следующих частях.

Система «Федерация». Часть 5/8 Критериальная модель – принципы построения