Система «Федерация». Часть 5/10 Критериальная модель – принципы построения
Рассмотрим типовой случай выбора системы в какой-то ИТ-ландшафт. Есть поставщик с одной стороны, и потребитель с другой. Например, АБС (и ее поставщик) в средний банк Российской Федерации (потребитель).
Главный интерес поставщика — заработать на своем продукте. При этом он может говорить все что угодно, и про миссию, про экологию и за мир во всем мире, но его главная цель именно заработать. Возможно, его даже не сильно расстроит использование его продукта не по назначению, лишь бы все было оплачено. Как говориться — неважно, что человек говорит важно, что он делает.
Потребитель же продукта хочет решить поставленные перед ним задачи автоматизации с минимальными для него затратами.
На лицо конфликт интересов. С каждой стороны конечно есть разные роли (продавцы, техКонсультанты, инженеры, менеджеры), но сейчас это не столь важно, главное ключевое противоречие между поставщиком и потребителем — один хочет продать подороже, другой хочет решить проблему автоматизации подешевле.
Описанный выше типовой случай встречается в группах компаний достаточно часто, поэтому можно еще расширить его до выбора системы для внедрения в нескольких компаниях, а не в одной. Это увеличивает объем задачи, но принципиально ее не меняет.
Постановка задачи оценки решений выглядит так:
необходимо определить набор критериев,
по которым потребитель системы получит достоверную и объективную оценку системы
для принятия решения о ее тираже на участников Gруппы
Рассмотрение ключевых участников начнем с поставщика.
У поставщика есть продукт, который он хочет продать, в как можно большее количество организаций. Что он будет точно делать в этом случае? Разумеется, трансформировать все особенности (изюминки, «фичи» и т.д.) своего решения в условные конкурентные преимущества. Например, «У меня гибкая настройка системы». Может получится, что достаточно ловкий «продажник» от поставщика «продаст» не очень опытному в технике представителю потребителя «кулек» красивых «фич», но при этом часть технических задач на стороне потребителя так и останется нерешенной. «НеТехнарь», а обычно окончательное решение принимает именно он, может этого и понять, там же такая классная штука. «Почему не сыграл мой козырной туз? А мы в шашки играем». Т.е. очень важно понять список задач, которые нужно решить на стороне потребителя (его требования) и рассматривать каждое решение именно в этой системе координат.
Продолжаем.У потребителя есть набор задач, в части как функциональных, так и нефункциональных требований, которые ему нужно закрыть какой-то системой.
Нам, как сотрудникам потребителя (Gруппы), близки задачи именно потребителя системы, вернее задачи всех потенциальных потребителей конкретного решения в Gруппе. Таким образом, весьма разумной, выглядит следующая схема :
Критериями в нашей модели должны быть задачи, важные для потребителя (надежность, реализация бухучета, ИТ-суверенитет)
В каждом продукте, представленном как «кандидат» в Gруппу, нужно оценить решение или реализацию этих задач, важных для поставщика
Например (как сказано выше), есть задача — обеспечение максимальной скорости внесения изменений в систему. Хорошо, в одной рассматриваемой системе для обеспечения «настраиваемости» используется модуль управления метаданными системы, а в другой задача решается за счет четко определенных внутренних интерфейсов, которые позволяют быстро подключит новую реализацию функциональности. На лицо две особенности разных систем, но не понятно как их сравнивать. Что лучше, первое или второе?
На самом деле мы имеем на лицо две реализации одной задачи, и оценивать нужно именно то, насколько каждая реализация задачи подходит потребителю. Еще пример из обычной жизни: для автомобиля имеем задачу «Движение», для которой нужен движитель. У одного поставщика дизель, у другого бензиновый двигатель, а у третьего вообще электроМобиль. Имеем три решения (дизель, бензин, батарейка) одной задачи (движение), каждая со своими плюсами и минусами. Вот на эти плюсы и минусы и нужно смотреть. Электромобиль в деревеньке, так себе решение — где-то надо заряжаться, да и имеют место быть перебои с электричеством, а в городе-герое Москве вполне нормально.
Таким образом, ключевая «формула» оценки системы по критериальной модели: реализация требований/задач потребителя в конкретной системе.
При такой ситуации (прямо скажем типовой) нужен арбитр, который
обеспечит «общеgгрупповые» интересы в рамках диалога поставщика и потребителя
определит набор необходимых критериев выбора
решит проблему подмены задач потребителя, «фичами» поставщика. Для этого «Федерация» комплектуется операционной моделью управления изменениями в критериальной модели.
Если у нас неизбежный двусторонний диалог, формирование критериальной модели идет со стороны и поставщика, и потребителя, надо и договориться и «ребенка» не выплеснуть. Рассмотрим два сценария в этом процессе с двух сторон: инициация изменений в критерии оценки со стороны поставщика и со стороны потребителя.
Поставщик
Интересы поставщика вполне очевидны: продать продукт, отбить инвестиции в «изюминки» своего продукта и на всем этом в конце концов заработать.
Отсюда следует что, все предложения со стороны поставщика должны пройти проверку на «Фичу». Т.е. поставщик хочет включить свою «фичу» в модель оценки, что бы она была включена в модель как обязательная и он в итоге получает конкурентное преимущество. Вряд ли в Gруппе это нужно. Проверка выглядит достаточно просто:
какая задача решается
насколько важна данная задача для потребителей
включаем критерий, если кому-то важно.
И все, такой простой, но не всегда очевидный прием, не «пустит» изюминку в критерии.
Потребитель
Теперь требования со стороны потребителя — кажется все понятно, но часто я сталкивался со следующей проблемой: требование заказчика является не задачей, а опять таки решением какой-то другой задачи, которая у него в голове. Т.е. получается мы фиксируем таблетку, но не поняли, что за болезнь и нужна ли вообще таблетка? Например, пациент говорит врачу — болит нога, врач говорит — вот эта мазь. Ни анализов, ни анализа, сразу лечение. Как-то неопрятно. Нужно же разобраться: это нога болит или сердце так «отдает» в ногу? Пример из техники : мне нужна интеграция в Active Directory. Хорошо. А зачем ? Нужна аутентификация. Так что включим в критерий оценки: Active Directory или аутентификацию? Очевидно задачу (аутентификация), а не один из способов ее решения (Active Directory).
Контролировать это должен модератор. В его задачу и входит следить за тем, чтобы в критерии оценки попадали именно задачи, а не один из конкретных способов ее решения.
В итоге и получим гарантию, что критериальная модель — это набор, важных для потребителей, задач, решение которых и оценивается в конкретной системе.
В комплект поставки «Федерации» добавляем архитектуру критериальной модели рис. 1 и операционную модель, по работе с этой моделью рис. 2. Саму модель рассмотрим в следующих частях.
