Архитектура и портфельное управление ИТ-проектами

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

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

Алекс Каллен — директор Центра по архитектуре и разработкам компании John Hancock Financial Services. Ему можно написать по адресу: acullen@ jhancock.com

Главная статья журнала CIO от 1 октября 2001 года (Do the Math) рассматривала важность такого подхода, как управление портфелем ИТ-проектов для оценки и расстановки их приоритетов. В течение некоторого времени мы, в компании John Hancock, применяли множество из обсуждаемых в статье методов. Более того, мы улучшили весь этот процесс посредством включения в него нашего представления архитектуры приложений. Преимущества оказались весьма значительными, и я хотел бы поделиться информацией о том, как это работает.

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

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

Три года назад компания John Hancock создала «Офис программ предприятия» (ОПП), чтобы попытаться упорядочить процесс свободного творчества в подразделениях. Руководители программы ОПП и бизнес-аналитики должны были работать с бизнес-подразделениями и группами ИТ-разработок, чтобы собрать, оценить и расставить приоритеты предложений по бизнес-проектам так, чтобы высшее бизнес- и ИТ-руководство могло принять решения о финансировании. Стандартные шаблоны для предложений описывали цели предложений, ожидаемые преимущества, затраты и ROI (return on investment, коэффициент возврата на сделанные инвестиции). Это дало руководителям больше возможностей для проведения «наглядных» сравнений.

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

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

Займитесь архитектурой

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

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

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

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

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

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

Планы лучшего качества

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

Ежегодный процесс планирования остается весьма тяжелым, возможно, он таковым и будет оставаться всегда. Однако результаты стали лучше. Более 80% всех ИТ-проектов реализуются в установленные сроки и в рамках выделенного бюджета, а также отвечают потребностям бизнеса нашей компании. Более того, мы все уверены в том, что инициативы, которые мы предпринимаем, принесут необходимые результаты для бизнеса.