Точка возврата

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

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

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

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

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

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

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

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

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

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

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

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

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