Для оценки конкретной системы «вообще» нам нужна типовая архитектура такой системы, т.е. функции, которые могут или должны быть реализованы, в системе заданного класса. Текущая версия критериальной модели, уже включает в себя несколько типов систем, но для примера возьмем систему типа «Автоматизированная банковская система(АБС)». Вероятно, покажется, что пример будет труден для аудитории незнакомой с банковским делом, но он позволит показать все нюансы предлагаемого подхода, а я постараюсь объяснить понятно, тем более что все мы клиенты какого-то либо банка и общее представление о банковском бизнесе все же имеем. Итак, начнем.
Для начала нужно определиться - что такое АБС? Каждый поставщик может понимать под этим совершенно разное. У кого-то «фронт» входит в АБС, у кого-то только функционал без пользовательского интерфейса. Алгоритм формирования этой части критериальной модели основан на типовой функциональной архитектуре систем одного назначения. Детали в части 4 «Размечаем площадку» . Вкратце напомню систему координат:
Имеем:
клиентов(сегмент)
каналы
сервисы и продукты, предоставляемые в каналах соответствующим клиентам
функции, используемые в процессах через сервисы
и системы , эти функции реализующие
Как было сформулировано в постановке задачи (часть 2. Концепция), оценка будет проводится в два этапа : централизованная оценка (система в принципе) и локальная оценка (система в конкретном ИТ-ландшафте).
Для формирования оценки системы типа "АБС" необходимо определить ее функционал.
Мы проработали этот вопрос с множеством экспертов как со стороны поставщиков таких систем, так и со стороны потребителей. Функционал АБС (рис.2) включает в себя четыре базовых функции, которые должны быть в любой АБС, чтобы она могла называться АБС.
К базовым блокам относятся
Продуктовый учет: представление продукта как ценности для клиента, вне зависимости от юрисдикции и регуляторов и т.д. Функции, необходимые для работы депозитами ФЛ, и в РФ и РБ, и Бразилии, принципиально не отличаются. Нужно «уметь»
управлять продуктом – Открыть,Закрыть и т.д.
вести остаток
выполнять операции (транзакции клиента и фоновые процессы – начисление процентов, например)
Клиенту, в принципе, функционально по финансовому продукту больше ничего и не нужно. Остальное - это уже форма предоставление возможности использования этих функций (сервисы в каналах ДБО, точках продаж и т.д.)
Бухгалтерский учет: это в чистом виде – требования регулятора. Важно отметить - четкое разделения продуктового и бухУчета означает, что в системе предусмотрено использование различного типа бухУчета, т.е. для разных юрисдикций (стран по сути). Этот блок предполагает следующие функции(умения) :
Выделять номера счетов под конкретный продукт, по требованиям регулятора. Для депозита в РФ нужно 3 счета(проценты, предварительно начисленные проценты и т.д.), в Бразилии один, а где вообще 5.
Создавать(генерировать) проводки и документы, по операциям продуктового учета, в рамках требований конкретного регулятора. Например, прошла операция, которая привела к движению средств (предварительное начисление процентов) этот факт должен быть отражен в бухгалтерской книге.
Ну и, конечно все это нужно «записывать» в эту самую бухгалтерскую книгу
Расчеты: деньги требуют передвижения – нужна функция расчетов между участниками операции. Если они находятся в одном балансе (балансе филиала), то нет проблем : счет по дебету, счет по кредиту, а что если нет?
Внутренние расчеты: если нужно рассчитаться в пределах одной организации – межфилиальные расчеты, например.
Внешние расчеты в РФ : если нужно рассчитаться с организациями в пределах нашей Родины
Внешние за рубежом: если нужны расчеты с контрагентами за пределами Родины
Операционная поддержка – обязательный функционал, без которого вышеописанный не работает:
Поддержка закрытия операционного дня: процессы могут отличаться, но общие функции стабильны: переоценка, сальдирование и т.д.
Операционные расчеты: что-то пересчитать, перевести и др.
Электронный архив документов: сформировать операционные документы
Фоновые процессы: часть процессов происходит автоматическом режиме по событиям или расписанию
В каких-то системах, эти функции могут поставляться как один продукт, в каких-то как разные подсистемы или даже отдельно лицензируемые продукты. Это всё воля владельца продукта, если он так видит – значит были некоторые резоны. Может он планировал крупноГранулярную (монолитную) АБС или наоборот «мелкодисперсную». Одна машина проектировалась для лютого бездорожья, другая для езды по полю для гольфа. Вот эти нюансы и должен проанализировать оценивающий эксперт. Но об этом позже. Некоторые соображения для владельцев продукта по этому поводу приведены в части 3 «Шапка архитектора».
Вышеописанное – это общее ядро АБС, его базовые функции, и с этим согласились большинство экспертов, с которыми мы работали, но некоторые участники наших обсуждений подсветили особенности их понимания, что такое АБС в целом. Кто-то считает, что ведение договорных условий по продукту(детали контракта клиента и банка) – это тоже часть АБС, а кто-то считает, что это не часть АБС. Т.е. у нас получились различные версии функционала АБС на основе базовых функций: АБС HomeEdition, АБС Standard Edition, АБС Enterprise, АБС + Процессинг и т.д. Пытаться «выровнять» все эти точки зрения, на мой взгляд, бесперспективно, да и бесполезно, как если попытаться провести дискуссию "Какой должен быть автомобиль?" между производителем вездеходов и семейного универсала – двигатель, трансмиссии – договоримся, но передний мост и люк в крыше – это зависит от позиционирования продукта. Тут опять целесообразно напомнить часть 3-ю «Шапка архитектора». Путь конечный потребитель решает – что должно входить в его понятие АБС и так по всем другим типам систем.
В дополнительные функции мы добавили фронтальное обслуживание, договорные условия, архив хранения. Действительно для маленькой организации городить отдельный архив не очень целесообразно – давайте сразу в одной «главной» системе. Для большой организации такой подход может оказаться неприемлем – у нее много таких «главных» систем.
В итоге в функциональной части критериальной модели оценки каждый поставщик имеет возможность отразить его понимание данного типа системы, в данном случае АБС.
В таблице 1 показано как каждый производитель может «позиционировать» свой продукт, но с одним ограничением – функция, может попасть в критериальную модель только из типовой функциональной архитектуры см. часть 4 «Разметим площадку».
Эксперт при оценке конкретного решения может проанализировать плюсы и минусы конкретного объединения функции в продукте и дать соответствующее заключение. Например, аналитический и операционный CRM в одной системе - это нормально в определенных случаях (для малых организаций, например), а для других (большая организация) уже "так себе".
С функциями АБС разобрались, теперь к другой оси заявленной системы «координат» - продуктам.
В начале определимся, что такое продукт. "Банковский продукт – это
логически завершенная, допустимая законодательством последовательность проводимых банком операций,
осуществляемая в целях удовлетворения потребностей клиентов банка
и обеспечения условий реализации такой последовательности операций,
а также дающая банку процентный и/или комиссионный доход, либо создающая потенциальные условия для получения дохода».
Нам нужен каталог типов продуктов и сервисов, которые реализуются в типовой АБС. Именно типов, т.к.
с одной стороны системы проектируются, так чтобы владелец самого продукта мог воплотить в системе свои самые смелые фантазии
с другой стороны, чем принципиально отличаются депозиты в разных АБС? По сути мало чем – простой депозит, депозит с возможностью и/или пополнения/снятия и т.д.
Есть тип продукта, а есть его конкретные реализации .
В каждой организации продуктовая линейка базируется на одном и том же базисе, а сами продукты - разновидности базового класса, если вспомнить основы объектно-ориентированного анализа. Есть базовый класс, есть наследники. Эта гипотеза подтверждается тем фактом, разные банки имеют разные линейки, а АБС используют одинаковые.
Следовательно – на данном этапе двухфазной оценки (централизованная оценка) можно, как и с типовыми архитектурами, работать с типовыми продуктами или классами продуктов. В функциональную часть критериальной модели в части АБС (и не только) включен каталог типовых банковских продуктов – рис.3.
Такой каталог был собран после анализа продуктовых линеек нескольких крупных банков РФ.
Логика работы была следующей:
брали частную продуктовую линейку банка
для каждого продукта искали в каталоге базовый класс (принцип подстановки Лисков - ООП),
не находили – это становился базовым в нашем каталоге
находили – завершение анализа
Таким образом, функциональная часть критериальной модели в части АБС включает в себя набор типовых функций (рис.2, таблица 1) и продуктов (рис.3). На основе этого можно провести централизованную оценку (см. часть 2 «Концепция») конкретной АБС поставщика.
Разобрались с функциональными требованиями (что должна уметь система – подробнее в «Через тернии в Омни» эпизод 1 «Вместо предисловия"), но остались неохваченными нефункциональные требования (как должна работать система).
Да, система может уметь все выше описанное по функциям и продуктам, но как(?) она это делает(нефункциональные требования)? Сколько «килограммов» инфраструктуры необходимо для нормальной работы системы в крупной, средней и малой организациях? Есть два автомобиля одинакового класса, но один «кушает» на 100 км 6 литров топлива, а другой «жрет» на сотню все 15. Т.е. нужно как-то определять «топливную» эффективность или инфраструктурную экономичность решения, без этого оценка системы будет неполной. Остается определить, как это можно сделать. Есть мысль.
Часто мы видим результаты тестирования систем. Например, система обеспечила на стенде 100000 RPS, а другая 80000 RPS. Какой мы можем сделать из этого вывод? Конкретного – никакого. Какие условия тестирования, на каком оборудовании, такие показатели – это хорошо или плохо? Потребителю дают некоторые данные, с которыми он должен сам(!) разобраться и решить все ли нормально будет с системой в его условиях эксплуатации. Выглядит не очень "клиентоориентировано".
Обратимся к милой моему сердцу авиации. Как оценивается эффективность самолета? Комплексным показателем - стоимость пассажироКилометра, или что-то в этом роде. Мне представляется, что не нужно изобретать велосипед, а сделать подобным образом.
Мы ИТ-шники и стоимость будем считать в объеме потребляемой инфраструктуры.
Итак, мысль – оценивать эффективность систем исходя из стоимости обслуживания одного клиента – удельная стоимость обслуживания. А чтобы потребителю не становиться супер экспертом в тестировании предложим, простой и понятный для потребителя подход: смоделируй один день работы АБС в банке и подсчитай удельное потребление инфраструктуры.
Как? Все на основе нашей системы «координат» : продукты, сервисы и сегменты
Берем каталог продуктов (рис.3), добавляем в нее необходимые данные для моделирования (таблица 2). И получаем схему тестирования системы на эффективность.
Можно
задавать данные для организации разного масштаба,
можно смоделировать только ФЛ или все вместе,
а данные по операциям, транзакциям - зафиксировать мониторингом.
Тут уже тонкости моделирования и тестирования систем, не будем сейчас на них останавливаться, главное результат этого мероприятия - заполнение модели, фрагмент которой представлен в таблице 2.
По данным инфраструктурного мониторинга получаем показатели использования инфраструктуры – таблица 3.
И рассчитываем удельную стоимость обслуживания одного клиента ФЛ, ЮЛ или других комбинаций показателей.
На основе этих расчетов мы можем оценить, а вернее сравнить две подобные системы.
Предложенный вариант может показаться дорогостоящим, но при сравнении автомобилей есть стандарты крашТестов. Дорого-муторно, но только так можно оценить эффективность до ввода в промышленную эксплуатацию.
В качестве альтернативы можно предложить такой замер уже "в проме", в реальных условиях. Тоже вариант, но результат может разочаровать, а уже поздно пить Боржоми. Да и решиться на такой шаг, имеется в виду оценку эффективности, может только очень зрелый и уверенный в своем продукте поставщик.
Итак, мы описали все части критериальной модели – ее постоянную и переменную (на примере АБС) части. Осталось еще одно – как проводить оценку, как собирать информацию, как готовить заключения.
