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

Статья переехала, новый адрес: «Парадоксы развития информационных систем: количественный подход» на lib.custis.ru

Автор

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

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

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

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

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

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

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

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

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

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

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

Рисунок 1.

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

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

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

Рисунок 2.

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

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

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

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

Первая часть 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₄ также должно быть предметом внедрения и сопровождения.

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

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

2 Ссылки

1. ↑ «Банки и технологии», №1-2005, стр 24-28.

Биллинговая система в большом городе

Статья переехала, новый адрес: «Биллинговая система в большом городе» на lib.custis.ru

Владимир Рахтеенко, генеральный директор ООО «Заказные ИнформСистемы».

«Биллинговая система в большом городе»^[1]

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

Содержание 1 Полный цикл коммунального биллинга 2 Характеристики промышленной системы 3 Условия успешного внедрения биллинговой системы 4 Профессиональный IT-партнер 5 Технологические критерии выбора поставщика 6 Организационно-экономические критерии выбора поставщика 7 Апробированная проектная технология 7.1 Кривая стоимости IT-проектов 8 Выбор между готовой программой или готовым решением 9 Технологии управления IT-проектом 10 Ссылки

1 Полный цикл коммунального биллинга

Основное требование к биллинговой системе по обслуживанию мегаполиса — это поддержка полного цикла биллинговых услуг (Рис. 1).

Рисунок 1. Полный цикл коммунального биллинга

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

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

2 Характеристики промышленной системы

Рассмотрим некоторые общие характеристики промышленной информационной системы.

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

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

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

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

• Четвертый существенный аспект в работе больших систем — это их географическая распределенность. Здесь, как и в отношении числа пользователей, имеет место множество исключений, обусловленных экономическими или технологическими ограничениями. К примеру, не все технологические платформы позволяют корректно реализовать распределенное решение.

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

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

3 Условия успешного внедрения биллинговой системы

4 Профессиональный IT-партнер

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

Что дает городу привлечение профессиональной IT-компании? Прежде всего — это выход на современный уровень автоматизации. Дело здесь не в том, чтобы следовать за веяниями моды. Программные продукты и даже платформы быстро устаревают. Специалисты, в отличие от кустарей, следят за изменениями в своей отрасли и вовремя переходят на новые инструменты и стандарты.

Если разработка ведется на морально устаревших платформах под предлогом экономии средств, то такая экономия быстро становится источником многочисленных проблем. Массовые сбои устаревших программ чреваты не только простоями в обслуживании населения. Известны случаи, когда в городах на почве расчетов за ЖКУ возникали социально-политические проблемы.

Современные технологии — далеко не единственное преимущество работы с профессиональным поставщиком. Независимый разработчик, его специалисты и технологии — это ресурсы, которыми можно пользоваться в критических ситуация. Таким образом, IT-партнер предоставляет клиенту определенный запас прочности. Это особенно актуально в тех случаях, когда клиент расширяет задачи проекта, хочет выйти на новый уровень обслуживания поставщиков ЖКУ и органов власти.

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

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

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

5 Технологические критерии выбора поставщика

Для компании-разработчика те требования, которые надо предъявлять к поставщику программного комплекса, очевидны. Состоявшиеся IT-компании сами довольно часто привлекают партнеров на субподряд. Поэтому им понятно, что нужно требовать и чего можно ожидать от партнера. Что должен продемонстрировать партнер, чтобы его пригласили выполнить общегородской биллинговый проект?

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

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

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

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

Вторая гарантия свободы заказчика — искусство договорной работы. Хорошо продуманный пакет договоров не позволит довести ситуацию до конфликта и разрыва отношений.

6 Организационно-экономические критерии выбора поставщика

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

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

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

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

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

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

7 Апробированная проектная технология

7.1 Кривая стоимости IT-проектов

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

Рисунок 2. Кривая стоимости проектов автоматизации

Во-первых, «коробочные» программы. Это программное обеспечение, которое не может быть должным образом изменено под конкретного заказчика. Идеология таких продуктов следующая: приспособить потребности клиента под возможности программы, а не наоборот — возможности программы под потребности клиента. Характерный пример — это типовые бухгалтерские программы, правовые программы, стандартные офисные пакеты, специальные приложения для инженерного проектирования или статистического анализа. Устраивает — берете, не устраивает — не берете.

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

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

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

На представленном графике хорошо видно, что одна из основных трудностей IT-индустрии состоит в том, что стоимость проекта является экспоненциальной функцией от его масштаба и сложности. Эксперты приводят разные оценки: от 1,5 в степени «трудность» до 2 в степени «трудность». И когда начинается проект, хоть в чем-то более сложный, чем установка «коробочного» ПО, значительные усилия участников проекта направлены на то, как удержать объем задания и его сложность, чтобы не выйти за пределы установленного бюджета и сроков.

8 Выбор между готовой программой или готовым решением

Готовые решения востребованы прежде всего там, где не удается найти на рынке программу, подходящую хотя бы на 80 %. Чтобы определить это, заказчик должен составить предварительную спецификацию или просто начальный список требований и затем, изучая доступные продукты один за другим методично ставить галочки: есть — нет, есть — нет. Если для каждой из существующих на рынке программ анкета будет заполнена менее чем на 80 %, и при этом известно, что это «коробки», а не готовые решения, но начинать внедрение не имеет смысла.

Программу нельзя будет внедрить не потому, что это технически невозможно. Как раз в технической области возможности информатизации сегодня сильно превышают даже самые смелые потребности. Но если отклонение прототипа и «коробки» от реальной ситуации заказчика больше, чем 20 %, то стоимость доработки недостающих блоков программы будет настолько превышать лицензионную стоимость, что ни один здравомыслящий человек с этими цифрами не согласится. Из этого следует такой вывод, что, вообще говоря, при серьезной постановке задачи выбираются технологии, а не прототипы. И, как ни парадоксально это звучит, при этом менее важно, насколько готовое решение подходит под начальные требования.

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

Еще один довод в пользу готовых решений приводят международные исследования, которые говорят, что практически в любом крупном проекте информатизации требования к функциональным возможностям создаваемого продукта растут от 2 до 10 % в месяц. Эти цифры заслуживают самого пристального внимания. Они означают, что если проект рассчитан, к примеру, на один год, то при отсутствии должного контроля за объемом требований ситуация изменится на 120 %. При этом не исключено, что фантастические, на первый взгляд, 20 % поверх 100 % означают возвращение к первоначальным планам на новом уровне понимания сложности. К сожалению, это не только теория. Такие случаи происходят довольно часто.

Откуда берутся эти 2-10 % в месяц? Дело в том, что по мере внедрения системы все начинают лучше понимать, что они делают. Кроме того, жизнь не стоит на месте и появляются новые рыночные вызовы. Новый уровень понимания и неожиданные рыночные вызовы делают динамику требований к системе изначально не предсказуемой. Вчера требования были одни, сегодня — другие, а завтра могут оказаться третьи (Рис. 3).

Рисунок 3. Типичная динамика роста требований в больших проектах

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

9 Технологии управления IT-проектом

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

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

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

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

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

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

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

10 Ссылки

1. ↑ Ежемесячный журнал руководителя и главного бухгалтера «ЖКХ» № 1, январь 2005, стр. 73-78.