Парадоксы развития информационных систем: количественный подход

Ссылки сюда (2) →

Автор

Елена Сомина, начальник управления банковских технологий ООО «Заказные ИнформСистемы».

• «Парадоксы развития информационных систем: количественный подход»

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

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

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

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

Метаданные, в совокупности образующие так называемое «ядро» системы, состоят из типов документов, их атрибутов (характеристик), действий и схем переходов для изменения состояний документов, из операций и шаблонов для генерации проводок. В процессе жизненного цикла документы переходят из одного состояния в другое. Переход в новое состояние порождает набор операций, которые находят отражение в финансовом учете: по шаблонам учета генерируются проводки в соответствующих планах счетов. Правила совершения переходов и правила их отмены (отката) и описываются также в виде метаданных.

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

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

Из большого статистического материала об изменениях всех компонент АБС (интерфейсных форм, программного кода, метаданных), накопленного в процессе ее развития, мы решили использовать сведения о метаданных, приняв в качестве количественной характеристики динамики изменения банковских систем число изменений записей о метаданных. Ее анализ привел нас к выводам, довольно интересным и неожиданным с точки зрения обычной практики выбора и приобретения АБС.

Подробный анализ изменения метаданных мы провели на примере нашей банковской системы CustIS Bank, которая 5 лет функционирует в небольшом стабильно работающем банке, который нельзя отнести к быстро развивающимся. На основании информации о создании, изменении, удалении метаданных за все годы эксплуатации АБС были построены графики зависимости количества модифицированных метаданных от времени. На рис.1 мы можем наблюдать заметную динамику их эволюции.

Рисунок 1.

Точка А₀ — старт «операционного дня» в новой АБС. Первые 8 месяцев длилось развертывание системы, внедрение и адаптация — график демонстрирует увеличение количества метаданных почти в 4 раза. После этого (частки B и С) началось экстенсивное развитие АБС. За 4 года штатной эксплуатации и сопровождения количество созданных метаданных по отношению к точке А₁ составило 85%, а с учетом правок уже существующих метаданных изменения достигли 164%.

В итоге — примерно 40%-е среднегодовое изменение наполнения системы метаданных, отражающее динамику развития бизнес-процессов в банке за период «стационарной» эксплуатации (данные в точке А₂ по отношению к точке А₁). Причем вне этого графика остались изменения программного кода (которые уменьшаются по мере развития системы, поскольку в нашей технологии кодирование формирует «стабильный» фундамент системы), а также изменения интерфейсных форм и внешней отчетности для ЦБ РФ.

Для иллюстрации содержания изменений в АБС рассмотрим участок С — это «бурный» 2004 год. На рис.2 в увеличенном масштабе видны скачки в объемах метаданных, связанные с изменениями требований ЦБ РФ и федеральных законов (валютное законодательство, финансовый контроль). На этот же период пришлась перестройка работы внутри банка, реорганизация, повлекшая изменение бизнес-процессов и документооборота.

Рисунок 2.

Мировой опыт показывает, что динамика изменений требований заказчика при развитии программной системы достигает 2-10% в месяц в период интенсивной разработки и уменьшается на этапе стационарного развития. В приведенном нами примере на эксплуатационном этапе функционирования АБС средняя скорость изменения составила примерно 3.5% в месяц. Поскольку параметры нашего проекта вполне уложились в мировую статистику, мы можем надеяться, что не ошиблись с выбором единицы измерения сложности системы.

Стоимость покупки и стоимость развития АБС

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

Рассмотрим состав функционального наполнения АБС с точки зрения его дальнейшего использования и развития. Он складывается из трех составляющих .

Первая часть V₁ — «джентльменский» набор, т.е. базовый функционал, необходимый каждому банку. Это довольно стандартный уже «операционный день», который должен удовлетворять требованиям регулирующих органов и постоянно поддерживаться в соответствии с требованиями внешней среды. Этот функционал банк старается быстро внедрить, по возможности минимизировав усилия по внедрению. Сейчас, как правило, независимо от фирмы-разработчика решения, подобное внедрение занимает 3-4 месяца (включая и перенос данных из старой системы в новую).

Вторая часть V₂ — уникальная составляющая функционала, в которой сконцентрированы специализация банка, его профиль, его характер, уникальные бизнес-процессы. Именно эти компоненты будут использовать в своей работе «добывающие» подразделения банка, именно тут будут автоматизироваться новые банковские продукты и услуги, новые технологические цепочки обслуживания клиентов и т.п. Можно с уверенностью утверждать, что динамичность развития банка характеризуется изменением именно этой части объема АБС.

В составе любой достаточно большой информационной системы, как правило, присутствуют и невостребованные на момент покупки компоненты — объем V₃. В зависимости от размера АБС и от профиля и нужд банка они могут составлять достаточно большую долю приобретаемой системы. Эти компоненты могут приобретаться в расчете на будущее использование, но могут оказаться и «мертвым грузом» для банка.

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

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

Стоимость = К*(Сложность)**(Процесс),

где

Стоимость

усилия выраженные в человеко-месяцах (или аналогичных единицах), затраченных на создание проекта,

К

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

Сложность

объем системы,

Процесс

показатель, зависящий от качества организации процесса проектирования. Колеблется в диапазоне от 1.25 до 2.

Опираясь на эту зависимость стоимости и сложности нам легче будет оценить оптимальный размер начального объема приобретаемой АБС. Ведь каждая из составляющих этого объема по разному влияет на индивидуальное развитие системы в банке.

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

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

Рисунок 3.

Продифференцировав эту кривую мы получим кривую на рис.4, которая явно отразит, как дорожает каждый следующий шаг развития системы по мере ее усложнения.

Рисунок 4.

Итак, оценим стоимость каждого шага доработок, например, усложнение системы на 100 функциональных точек, т.е. сколько стоит получение N точек от N-100 при разных значениях N. Для того, чтобы на первых этапах развития получить систему сложностью 400 функциональных точек из сложности 300, мы должны заплатить 45 000 условных единиц. А вот для того, чтобы из сложности в 800 точек продвинуться к 900 функциональным точкам, мы должны заплатить уже 70 000 условных единиц. Т.е. каждый по мере роста и усложнения системы каждый шаг ее развития требует все больших ресурсов.

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

Итак, какова цена того потенциала развития, который приобретает банк, покупая новую АБС?

• V₁ — стандартный функционал «операционного дня». Сэкономить на этой компоненте АБС едва ли удастся.

• V₃ — дополнительный функционал, приобретаемый заодно с основным, «впрок» или «на вырост». Стоит задуматься о его приобретении, поскольку эта часть АБС не просто остается невостребованной долгое время, но и значительно усложняет как адаптацию V2, так и дальнейшее развитие системы в целом.

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

Динамичный проект должен развиваться под девизом «Ничего лишнего!». Необходим очень жесткий и суровый контроль при внесении в систему лишних функциональных звеньев.

Таким образом одним из факторов, который может служить аргументом для банка в пользу выбора в качестве компоненты V₂ не готового функционального модуля, а «предзаготовки с последующим доведением ее до уровня системы по индивидуальному заказу» — это «эффективность» ее цены, т.е. величина отношения стоимости используемого функционала к стоимости системы.

Начиная создание своей системы с небольшого стартового функционала, вы получаете только то, что вам необходимо, и тем самым, снижаете нагрузку «присоединенной массы» развития на дальнейшее наращивание возможностей вашей АБС. Тем самым решается задача оптимизации цены владения АБС и, в общем-то, даже еще более значимая задача обеспечения такого характера ее функционирования и развития, который гарантировал бы ее выживаемость, устойчивость, гибкость и управляемость на достаточно большом промежутке времени.

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

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

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

Такой подход к проекту приобретения АБС порождает для поставщика ПО задачу трансляции знаний и развития технологий трансляции знаний. Для профессиональной компании-разработчика развитие этих платформ — специальная сфера деятельности, которая занимает очень важное место и является предметом постоянного внимания и инвестиций. В таком проекте внедрения, сопровождения и развития АБС центр тяжести смещается в область консалтинга и передачу технологий и знаний заказчику.

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

Ссылки

---

Репликация: База Знаний «Заказных Информ Систем» → «Парадоксы развития информационных систем: количественный подход»

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