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

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

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

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

Парадигма Захмана

В статье, опубликованной в 1987 году в журнале IBM Systems Journal (Vol.6, No. 3), Джон Захман (John Zachman) предложил ставшую ныне довольно популярной схему архитектуры ИТ-систем — Framework for Information Systems Architecture. Схема Захмана — очень полезный инструмент для моделирования данных. Со времени представления схемы ее адаптировали для применения во многих областях ИТ-приложений, в том числе для создания информационных хранилищ и BI-решений.

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

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

Эта схема также служит превосходным инструментом управления BI-проектом. Поскольку расходы и доходы — это побочные результаты намерений и действий, их можно смоделировать в координатах намерений и действий. Это основополагающий принцип концепции REM (Return Expense Modeling — моделирование возврата расходов). Комбинация систем Захмана и REM позволяет влиять на проектирование и разработку, используя финансовые оценки.

В подходе Захмана элементы разработки подставляются в столбцах, а уровни архитектуры — в строках (табл. 1). Каждый проект начинается с единственным замыслом — улучшить конкретный существующий процесс или создать новые возможности. По мере расширения идеи начальный замысел обрастает новыми подробностями — так образуется план действий и базовая инфраструктура, призванные реализовать идею или замысел. Таблица Захмана позволяет зафиксировать развитие и детализацию замысла. С другой стороны, концепция REM ориентирована на поддержание целостности описанного процесса развития. Уровни REM отражают этапы возврата инвестиций или расходования средств. Любой проект строится на ожидании результата; таким образом, три верхние строки таблицы Захмана соответствуют ожиданию результатов в концепции REM. В системе Захмана эти три уровня служат также для определения общей концепции еще до начала каких-либо реальных действий. Следующие три уровня модели описывают компоненты расходов и используются для определения действий, нужных для физической реализации решения (табл. 2).

Таблица 2. Структура REM

Столбцы REM -> Отображение Элементы Отображение Управление
  Данные (что) Функции (как) Сеть (где) Люди (кто) Время (когда) Мотивация (зачем)
Намерение (контекстный) Модель объема результатов
Модель предприятия (концептуальный) Модель анализа результатов
Системная модель (логический) Модель проектирования результатов
Технологическая модель (структурный) Модель спецификации расходов
Детализированное представление (физический) Модель расходования средств
Система (функциональный) Модель регистрации расходов

Столбцы в системе REM характеризуют инструментальные средства, при помощи которых можно управлять расходами и результатами. Столбцы делятся на три группы: элементы, управление и отображение.

  • Столбец «Элементы» содержит компоненты, которые активно участвуют в балансе расходов и результатов и непосредственно определяют его итог. Эффективность и результативность решения определяются функциями, которые выполняет это решение (как), сетью, в которой оно создается (где), и людьми, которые его используют (кто). Этим столбцам модели REM соответствуют столбцы «Функции», «Сеть» и «Люди» таблицы Захмана.
  • Столбец «Управление» содержит элементы, определяющие побудительные мотивы и модальности расходов и результатов. Здесь указывается, что нового вносит создаваемое решение. Этот столбец соответствует столбцу «Мотивация» (почему) таблицы Захмана.
  • Столбец «Отображение» содержит элементы, которые обеспечивают обратную связь с модальностью и побудительными мотивами. Такая обратная связь обычно состоит из определенных данных, соотнесенных с периодом времени. (Например, решение компании, выпускающей кредитные карточки, о снижении цен с целью увеличения продаж отразится на доходе через определенный ожидаемый промежуток времени.) Эти столбцы REM применяются для доказательства гипотезы, определенной в колонке «Время» или «Мотивация», и точного описания того, что и когда в действительности делается. Все это необходимо для выполнения заданных решением требований, а значит, и планов по расходам и доходам, определенных в решении. Столбцы «Данные» (что) и «Время» (когда) таблицы Захмана соответствуют столбцу «Отображение» модели REM.

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

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

Следующий, концептуальный уровень преобразует эмпирические требования в модель корпоративного решения, которая описывает связь между различными компонентами решения и требованиями. В модели REM этот уровень используется для анализа точек возврата (points of return), соответствующих факторам, представленным на предыдущем, контекстном уровне. Бизнес-план или цели показывают, почему именно это решение подходит в данном случае. Вы можете определять различные точки возврата и управлять ими с помощью бизнес-плана — другими словами, эти точки можно увязать с бизнес-планом или целями. Семантическая модель и график концептуальной модели отражают точки возврата. Любое новое решение влечет за собой изменение бизнес-процессов, перестройку сети логистики и увеличение числа интерфейсов с технологическим процессом. Эти факторы влияют на различные точки возврата; именно поэтому они являются «элементами» этого уровня.

Логическое решение

Вы охватили все задачи и смоделировали решение. Следующий шаг — спроектировать решение в соответствии с логической схемой, используя «логический» уровень для проектирования точек возврата в модели REM.

Бизнес-правила в ячейке «Мотивация» определяют механизмы, которые призваны обеспечить достижение оговоренных в бизнес-плане результатов; в этом смысле бизнес-правила служат контрольной точкой проекта возврата средств. Модель данных в ячейке «Данные» и график работы или системные события, описанные в ячейке «Время», детализируют, что (и когда) требуется сделать в рамках решения, — таким образом они отражают проектные точки результативности. Возможности и ограничения приложения, распределение и архитектуры пользовательского интерфейса способны влиять на проект — как положительно, так и отрицательно. Это же способно влиять на проектирование результатов.

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

На этой стадии создания архитектуры проекта в игру вступают вопросы расходов. Результаты определены и спроектированы на предыдущих этапах, при этом величина возврата выступает в качестве ограничения. В таких условиях расходы на создание решения также могут быть определены и лимитированы. Различные компоненты технологической модели вносят разный вклад в общую структуру расходов. Бизнес-правила и рабочие характеристики, определенные в ячейке «Мотивация», задают порядок разработки и реализации решения, поэтому их можно использовать для управления расходной частью проекта. Проект данных (столбец «Данные») и планирование заданий или структура управления (столбец «Время») отражают порядок работы решения и поэтому соответствуют структуре расходов. Системный проект и архитектура, а также способ представления влияют на структурные разработки. Перечисленными элементами можно манипулировать для управления определенными видами расходов.

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

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

Предостережения и советы

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

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

Описанная здесь методология REM ориентирована прежде всего на большие и сложные BI-проекты. Тем не менее ее можно приспособить и для реализации очень мелких и узкоспециализированных проектов. Универсальность подхода позволяет применять его для самых разных проектов создания корпоративных систем.

Судхи Синха (Sudhi Sinha) — консультант по системам предприятия в компании Tata Consultancy Services (http://www.tcs.com). Специализируется в области внедрения многоуровневых BI- и ERP-систем. С ним можно связаться по e-mail: sudhisinha@hotmail.com.