Статья «ИТ-бюджет — инвестиции или затраты?» (Intelligent Enterprise No 15’2003) вызвала интерес у читателей, и мы решили в этом номере продолжить тему ИТ-бюджета. Поскольку при подготовке предыдущего материала в качестве консультанта активно привлекался Александр Буйдов, директор департамента информационных технологий компании КРОК, редакция публикует его авторский материал по данной проблеме.
Портрет TCO в интерьере
С самого начала следует подчеркнуть тот факт, что методы TCO не существуют сами по себе и имеют смысл только тогда, когда для оценки бизнеса уже применяются различные методики и отдельные показатели (метрики), стыкующиеся между собой. Поэтому мы будем рассматривать TCO в рамках некоей классификации наряду с другими методиками.
В ряде случаев (см., например, http://www.cio.com/archive/071502/value.html) методы бизнес-оценки делят на традиционные финансовые, качественные и вероятностные. ТСО попадает в категорию финансовых оценок. К этой же категории относится и достаточно известная методика экономической добавленной стоимости (Economic Value Added, EVA).
Среди используемых в России методов качественной оценки можно назвать Portfolio Management (об этом подходе достаточно подробно рассказано в предыдущей статье, см. Intelligent Enterprise No 15’2003), Balanced ScoreCard (BSC) и IT-Scorecard. Другие методы, такие, как Real Option Valuation (ROV) или Applied Information Economics (AIE), в нашей стране практически не известны.
Классические принципы TCO были и остаются востребованными и в России, и на Западе. Хотя при сравнении ТСО с аналогичными методологиями становится понятно, что с задачами бизнеса она связана в наименьшей степени. Если, к примеру, метод EVA (напрямую конкурирующий с TCO), оперирует понятием превышения прибыли от деятельности подразделения или прибыли в конкретном проекте (в нашем случае в области ИТ) над стоимостью выделенного ему операционного капитала, то TCO имеет дело только с затратной частью. Иными словами, с помощью TCO можно ответить на вопрос, поставленный бизнесом, но аргументировать какую-либо ИТ-инициативу в терминах повышения прибыльности вряд ли получится.
Gartner Group, разработчик и идеолог данной методики, признает, что ТСО — инструмент не на все случаи жизни: он не годится для оценки рисков и для определения способов соответствия ИТ и стратегических целей компании. И тем не менее применение TCO в стыковке с BSC или иными методами оценки качественных факторов может стать хорошей основой для определения и контроля расходов на информационные технологии.
TCO вчера и сегодня
В настоящее время концепция TCO активно развивается. Существует своего рода ядро данной методологии, представляющее собой совокупность наиболее универсальных статей ИТ-затрат, и методы, которые условно можно отнести к расширению модели TCO. Итак, наиболее универсальные статьи затрат по модели TCO таковы:
- приобретение и модернизация аппаратного, сетевого и программного обеспечения;
- вспомогательные и служебные системы (жизнеобеспечения, безопасности, управления);
- техническое обслуживание;
- обучение;
- эксплуатация системы пользователями (самообучение, нерациональное использование рабочего времени);
- разработка ПО;
- коммуникационные услуги (выделенные каналы связи, выход в Интернет).
Прямые затраты (на создание и поддержку систем) рассчитать достаточно просто; сложности чаще всего вызывает подсчет непрямых затрат, таких, как обучение и поддержка пользователей, а также потерь, связанных с простоем оборудования. Для правильного их подсчета необходима система сбора временной статистики (время простоя ИТ-системы, время, потраченное на самообучение и взаимопомощь пользователей и т. п). Часть такой статистики можно собрать, проанализировав заявки службы HelpDesk, другую часть можно получить из анализа загрузки сотрудников.
В некоторых случаях нужно учитывать конкретные статьи затрат, подобные ежемесячному расходу бумаги при расчете TCO эксплуатации принтера. В табл. 1 приведен достаточно типичный пример расчета совокупной стоимости владения персональным компьютером, в котором соблюдены принятые на практике пропорции между отдельными видами затрат.
Таблица 1. Расчет совокупной стоимости владения ПК
| Статья затрат | Тип затрат | Сумма, долл. |
| Аппаратное и программное обеспечение | Прямые | 2000 |
| Информационная поддержка и администрирование | Прямые | 2500 |
| Разработка приложений | Прямые | 500 |
| Поддержка и обучение пользователя | Непрямые | 3500 |
| Потери от простоев | Непрямые | 1000 |
| Итого | 9500 |
Такая схема сейчас служит отправной точкой для развития концепции TCO. Перед руководителями ИТ-направлений встают более сложные, чем прежде, задачи, диктуемые, в свою очередь, разнообразием имеющихся технических и организационных решений. Ведь, покупая персональный компьютер или сервер, необходимо сразу думать о его будущей модернизации. А при создании информационных систем нужно уметь разграничивать проблемы масштабируемости и миграции со временем на новую платформу. Последний вопрос связан с адекватным учетом рисков и т. д. Построение системы поддержки пользователей может потребовать рассмотрения множества стандартных организационных схем, в частности, построения службы HelpDesk. И подобные примеры можно продолжать.
Кроме этого, современные подходы к расчету TCO все теснее переплетаются с бизнес-проблематикой. Существуют попытки разделить понятие совокупной стоимости владения на две части: TCO, связанное с технологиями, и бизнес-TCO (см., например, http://www.sybase.com/content/1018088/iq_wp_TCO.pdf), соответственно выделив несколько направлений затрат:
- на аппаратное обеспечение;
- на программное обеспечение;
- на персонал;
- на обеспечение доступности сервисов;
- на обеспечение необходимого уровня производительности системы;
- на обеспечение быстрого восстановления после сбоев.
Как ни странно может показаться на первый взгляд, именно последние три направления относятся к категории бизнес-TCO. Но дело в том, что именно они, в отличие от оценок затрат, связанных с оборудованием, ПО и персоналом, в наибольшей степени должны учитывать бизнес-процессы в организации. Оценка выгод или потерь, связанных с производительностью и доступностью сервиса, имеет смысл только тогда, когда точно определен бизнес-контекст доступа к нему тех или иных сотрудников. Постоянная задержка в 10 с при доступе к данным инженера-проектировщика может существенно снизить производительность его работы, в то время как продавец магазина, запустив процесс авторизации кредитной карточки, все равно будет в течение этого времени занят оформлением документов на товар или его упаковкой. В итоге при адекватном учете бизнес-составляющих TCO, количественно учитывающих возможные потери в результате отклонения от некоего идеального уровня доступности и производительности или от нулевой вероятности простоя, можно сравнить по единому показателю все предлагаемые решения, суммируя отдельные факторы.
Понимание бизнес-процессов позволяет оценивать TCO по различным сценариям в соответствии с принципом «что… если». Ведь различные компоненты TCO связаны между собой диктуемой особенностями бизнеса нелинейной зависимостью. Как было сказано ранее, не факт, что более дорогостоящая платформа и соответственно высокая абстрактная производительность и доступность дадут пропорциональную экономию от данных факторов в реальной бизнес-среде.
Таким образом, TCO необходимо рассчитывать с учетом уникальности технологического развития и традиций ведения бизнеса каждого предприятия. По этим причинам дополнительный акцент следует делать на таких моментах, как модульность архитектуры TCO; учет влияния сложности современных информационных систем; структура персонала, работающего с ИС; контроль факторов риска и применение лучшей практики организаций.
Учет различных факторов, влияющих на ТСО, позволяет выделить большое количество типичных ситуаций, имеющих место в бизнесе. Так, в соответствии с классификацией Gartner Group ИТ-решения могут иметь определенный уровень сложности с точки зрения управляемости (например, централизованная, децентрализованная, распределенная структура) или архитектуры аппаратного и программного обеспечения (степень насыщенности клиент-серверными технологиями и т. п.). Персонал, работающий с ИТ, в свою очередь, по мнению Gartner, делится на несколько категорий, включая, например, специалистов, работающих с корпоративными знаниями (knowledge workers), мобильных сотрудников или работников, занимающихся только вводом информации в систему. Каждой из этих категорий присуща определенная квалификация, потенциальный уровень отдачи от использования ИТ и требования к ИТ-инфраструктуре. Модульность архитектуры ПО позволяет подбирать уникальную конфигурацию наиболее значимых TCO-факторов, в максимальной степени адаптируя методику расчета TCO под конкретное предприятие, и просчитывать различные сценарии по принципу «что… если».
Уже можно сказать, что широко популярные ранее некие средние по отрасли готовые показатели TCO в настоящее время имеют все меньшее значение и на первый план выходят методики, обобщающие накопленный опыт.
Таким образом, в оценке совокупной стоимости владения не слишком полезно полагаться на внутрифирменные методологии расчета TCO базовых корпоративных продуктов (будь то сервер баз данных или сетевой маршрутизатор). Хотя цена оборудования, стоимость поддержки, расходы на обучение персонала и прочие статьи затрат в большинстве случаев декларируются поставщиком вполне корректно, в реальной бизнес-среде стоимость построенных на их основе конечных решений и приносимый ими доход могут отличаться в разы.
Принципы деловой игры
Подводя итог сказанному выше, можно найти место методологиям TCO, применяемым для расчета стоимости владения ИТ-продуктами, в бизнесе компании в целом. Для этого представим бизнес-менеджмент и ИТ-персонал как сражающихся на площадке игроков, причем правила игры напоминают теннис.
Глобальная инициатива всегда принадлежит бизнесу. Он подает первым, предлагая ИТ-отделу способствовать решению бизнес-задачи. У последнего есть несколько вариантов действий. Применяя классические методы расчета TCO, ИТ-подразделение отводит себе роль обороняющегося на задней линии: как уже было сказано, даже очень грамотно считая затраты, можно только отвечать на вопросы бизнеса, отбивая удары и проявляя при этом минимум инициативы. Чтобы этого избежать, надо время от времени «выходить к сетке», встречая тем самым постановку бизнес-задач не в «информационном тылу», а ближе к территории самого бизнеса. Здесь на помощь приходят расширенные методики расчета TCO, учитывающие специфику бизнеса и сочетающиеся при необходимости с другими инструментами.
Игроки бизнес-половины поля также способны играть и на задней линии, и у сетки. К примеру, Balanced ScoreCard, методики финансового или управленческого анализа, используются обычно исключительно для решения задач развития бизнеса и даже при развитом применении вовсе не касаются вопросов ИТ. Для решения задач, напрямую требующих оценки эффективности ИТ, могут использоваться специальные метрики. Подобных параметров много (см., например, http://www.baselinemag.com/article2/0,3959,99364,00.asp). Для оценки общей отдачи от ИТ можно использовать, например, следующий показатель, вычисленный, допустим, для пяти последних лет работы компании:
Количество завершенных ИТ-проектов с известной финансовой отдачей/общее число завершенных ИТ-проектов
Для оценки эффективности влияния ИТ на бизнес (например, в промышленности) вполне применим следующий параметр:
Увеличение количества продукции, выпущенной на производственной линии N3/суммарные ИТ-затраты, направленные на автоматизацию работы линии
С этими показателями бизнес со своей стороны подходит ближе к половине поля, занимаемой ИТ. Полезными для обеих сторон при игре в центре поля оказываются и другие методические инструменты, подробно рассмотренные в предыдущей статье.
В итоге получается, что в большинстве реальных ситуаций для обеих сторон наиболее эффективна манера «игры у сетки», когда мяч подолгу не задерживается ни на одной половине. Иными словами, та или иная проблема ИТ-поддержки бизнеса поочередно оценивается с обеих сторон таким образом, чтобы специфика ИТ и вопросы эффективности бизнеса рассматривались едиными методическими средствами без отрыва друг от друга. И, благодаря общности языка, взаимопонимание достигается быстрее. Современный взгляд на проблему TCO как раз и представляет собой отработку приемов игры в центре поля.
И, наконец, можно отметить, что снижение TCO — это не только общепринятые формулы. Это еще и качество совместной работы бизнес-подразделений компании и ИТ-департамента. Некоторые связанные со стоимостью владения составляющие затрат (например, затраты, связанные с процессом массового освоения новой версии корпоративной системы) плохо поддаются количественной оценке и непосредственному регулированию. Соответственно с ними пытаются бороться более креативными методами, для которых нет общих методик. Примером может служить предварительное создание специального раздела на корпоративном портале, посвященного новой версии ПО, или подготовка специальных обучающих демороликов для каждой категории сотрудников компании. Тут существенную роль играет взаимопонимание между бизнесом и ИТ (уже на уровне организационных подходов).
Дорого ли владеть инфраструктурой?
Итак, кратко рассмотрим ряд примеров расчета совокупной стоимости владения, демонстрирующих тот факт, что в контексте учета бизнес-проблем они выглядят намного более цельно и убедительно. Начнем с проблемы ИТ-инфраструктуры, обосновать развитие которой с помощью инструмента «чистого TCO», как мы уже отметили, довольно затруднительно.
Скажем, крупная промышленная организация планирует внедрить систему класса PDM (Product Data Management) с целью автоматизировать процесс технической подготовки и последующей модернизации новых изделий. Предполагается, что в результате сокращения срока подготовки производства в первый год эксплуатации PDM-системы будет получено 2 млн долл. дополнительного дохода. Совершенствование бизнес-процессов за счет внедрения новой системы позволит экономить еще около 5 тыс. долл. в неделю. Чтобы внедрить выбранный продукт (на это, по оценке поставщика, уйдет около 4 месяцев), потребуется работа шестерых внешних консультантов, оплачиваемых по ставке 25 долл. в час и работающих по 40 ч в неделю, а также 12 специалистов предприятия, получающих 200 долл. в неделю. Уже известно, что через год встанет задача растиражировать опыт внедрения PDM-системы в трех удаленных центрах проектирования продукции. И для ее решения потребуется привлечь соответственно троих внешних консультантов и шестерых специалистов заказчика.
Анализ схемы внедрения показывает, что только за счет использования на предприятии сетевой платформы хранения данных можно сократить срок внедрения PDM-системы с 4 до 3 месяцев, а развертывание ее в филиалах — соответственно с 6 до 5 недель. Более того, использование данной платформы способно поднять уровень доступности данных с 97 до 99,99% с соответствующим сокращением планируемого простоя оборудования с 5 ч до 30 мин в неделю, а незапланированного простоя — с 1 ч в месяц до 1 ч в год. При этом известно, что 1 ч планируемого простоя функционирования PDM-системы обходится компании в 1 тыс. долл., незапланированного — в 6 тыс. долл.
Данный пример показывает, что технические характеристики внедряемого комплекса (в нашем случае обеспечиваемый системой хранения уровень доступности данных) очень тесно «вплетены» в коммерческие характеристики проекта. При расчете ТСО для системы хранения в данной ситуации представляется целесообразным все же выделить данную характеристику в явном виде, одновременно не отрывая ее от бизнес-контекста проекта. Результаты этой попытки сведены в табл. 2.
Таблица 2. Расчет совокупной стоимости владения для PDM-системы
| Эффективность в терминах бизнес-процессов | Бизнес-эффект | Эффект от снижения TCO | Суммарный эффект, тыс. долл. |
| Первоначальное внедрение PDM-системы. Экономия времени - 1 месяц (4 недели) | 2000/12 = 167 тыс. долл. дополнительного дохода от ускоренного
внедрения 5*4 = 20 тыс. долл. за счет совершенствования бизнес-процессов |
25*40*4*6 = 24 тыс. долл. экономии на оплате внешним консультантам |
167+20+24+9,6 = 220 тыс. долл. |
| Развертывание PDM-системы в филиалах. Экономия времени - 1 неделя | 5*1 = 5 тыс. долл. за счет совершенствования бизнес-процессов |
25*40*1*3 = 3 тыс. долл. экономии на оплате внешних консультантов |
5+3+1,2 = 9,2 тыс. долл. |
| Снижение времени запланированного и незапланированного простоя |
1000*(5-0,5)*12 = 234 тыс. долл. в год экономии за счет запланированных
простоев |
300 тыс. долл. в год | |
| Итого суммарной экономии в год | 192 тыс. долл. | 337,8 тыс. долл. | 529,8 тыс. долл. |
Пример позволяет продемонстрировать, что отдельные компоненты TCO, рассчитываемые в контексте бизнес-задач, могут иметь отрицательное значение: наряду с затратами на приобретение и эксплуатацию продукта, имеющими по определению отрицательную величину, в итоговую сумму входят положительные слагаемые, определяющие экономию на реорганизации бизнес-процессов, на скорости их исполнения и т. д. Этим часто пользуются при расчетах TCO в привязке к бизнес-процессам. Формула для расчета TCO соответственно приобретает вид:
TCO = Традиционные статьи затрат — Величина достигнутой экономии
В нашем примере приведена лишь величина экономии, заранее поделенная на общий бизнес-результат и эффект, получаемый непосредственно в результате задействования функционала системы хранения. По определению, имея также традиционную разбивку расходных статей TCO на первоначальные и периодические затраты (подобную приведенной в табл. 1), мы получаем все данные для вычисления показателя ROI (см. также предыдущую статью), который, как мы выяснили выше, уже выступает как инструмент для совместной работы бизнеса и ИТ. Он рассчитывается по следующей формуле:
ROI = (Величина достигнутой экономии — Ежегодные вложения)/Первоначальные вложения
В случае окупаемости проекта менее чем за год (и соответственно отсутствия влияния ставки дисконтирования) данная величина должна точно совпасть с величиной ROI, полученной в результате применения методики, описанной в предыдущей статье. А благодаря разбивке величины экономии мы можем выделять и отдельные составляющие ROI.
Вообще же разработка методик, в которых особенности бизнеса, традиции применения ИТ, технические характеристики решения и, наконец, экономический эффект связаны единой и тщательно продуманной системой метрик, существенно выходит за пределы рассмотрения вопросов ТСО. И такие методики, в силу чрезвычайной важности проблемы, действительно активно развиваются, о чем мы постараемся рассказать в ближайших публикациях.
| Александр Буйдов — директор департамента информационных технологий компании КРОК. С ним можно связаться по e-mail: ABuydov@croc.ru. |
