Оценка стоимости программного продукта, ИТ-услуги.

Лекция 4 и 5. Оценка стоимости программного продукта, ИТ-услуги. Стоимость программного продукта Цель этого раздела – представить на рассмотрение различные методы оценки стоимости и затрат, необходимых для создания программного продукта. Прочитав ее, вы должны: - знать, как оценивается себестоимость и назначается цена программного продукта, и понимать сложные взаимосвязи между этими двумя процессами; - знать три системы оценивания производства программного продукта; - понимать, что для правильной оценки стоимости ПО и для создания графика работ необходимо применять широкий спектр различных методов оценки стоимости программного продукта; - знать принципы работы модели СОСОМО - 2 для алгоритмической оценки стоимости. Существует общая проблема оценки затрат и времени, необходимых для выполнения определенных этапов проекта. Менеджеры проекта должны научиться давать правильные ответы на следующие вопросы. 1. Какие затраты необходимы для выполнения этапа? 2. Сколько это займет времени? 3. Какова стоимость выполнения данного этапа? Оценка стоимости проекта и планирование графика работ проводятся параллельно. Однако некоторые предварительные расчеты должны быть выполнены на ранней стадии, еще до начала разработки точного плана проекта. Такие расчеты необходимы для утверждения бюджета проекта или для выставления цены заказчику. Как только проект начинает действовать, все расчеты должны регулярно обновляться. Это помогает планировать работу и содействует эффективному использованию средств. Если фактические расходы значительно превышают планируемые, менеджеру необходимо предпринять какие-либо действия. Это может быть перечисление дополнительных средств на проект либо изменение будущих этапов работ в соответствии с фактическим бюджетом. Обычно для оценки проекта по разработке программного обеспечения используются три параметра. • Стоимость аппаратных средств и программного обеспечения, включая их обслуживание. • Расходы на командировки и обучение. • Расходы на персонал, в основном на привлечение со стороны специалистов по программному обеспечению. В большинстве проектов доминируют расходы на персонал. Компьютеры, имеющие достаточно мощности для разработки программного продукта, в наше время относительно дешевые. Значительными могут быть затраты на командировки, если проект разрабатывается в разных местах, однако для большинства проектов они все же не очень существенны. Более того, расходы на командировки можно сократить, используя вместо них электронную почту, факс или телеконференции. Расходы на персонал - это не только оплата труда работников. В них могут включаться накладные расходы, т.е. все расходы, которые касаются работы организации, деленные на количество работающего персонала. Таким образом, общая сумма расходов на персонал состоит из нескольких статей расходов. 1. Расходы на содержание, отопление и освещение офисов. 2. Расходы на содержание вспомогательного персонала – бухгалтеров, секретарей, уборщиц и технического персонала. 3. Расходы на содержание компьютерной сети и средств связи. 4. Расходы на централизованные услуги – библиотеки, места отдыха коммунальные услуги и т.д. 5. Расходы на социальное обеспечение и выплаты служащим (например, пенсии и медицинская страховка). Обычно накладные расходы приравниваются к удвоенной зарплате программиста, в зависимости от размера компании и расходов на ее содержание. Например, если специалист по программному обеспечению получает 18 000 долларов в год, расходы организации на этот год составляют сумму 145 000 долларов, или 12 000 долларов в месяц. Оценка стоимости должна быть объективной, чтобы дать компанииразработчику достаточно точный прогноз себестоимости проекта. Если себестоимость рассчитывается для включения в коммерческое предложение заказчику, следует принять решение о том, какую цену назначить за проект. Традиционно в цену продукта включают издержки производства плюс предлагаемая прибыль. Однако определить соотношение себестоимости проекта и цены, выставляемой заказчику, не всегда просто. На определение цены программного продукта могут повлиять организационные, экономические, политические и коммерческие соображения. Эти факторы показаны в табл.1. Таким образом, взаимоотношения цены и себестоимости совсем не так просты, как может показаться. Кроме того, необходимо учитывать глобальные цели организации, поэтому назначением цены за программный продукт вместе с менеджерами проектов занимается и старший руководящий состав компании. Таблица 1. Факторы, влияющие на стоимость программного продукта Фактор Описание Организация-разработчик может выставить низкие цены на программный продукт из-за намерения переместиться в другой сегмент рынка ПО. Даже если Возможности рынка организация примет более низкую прибыль в первом ПО проекте, это все равно может привести к более высоким доходам в будущем, поскольку полученный опыт позволит заниматься разработкой подобных программных продуктов и в дальнейшем Невозможно учесть Если организация примет фиксированную величину все факторы, стоимости, издержки производства могут возрасти из-за влияющие на непредвиденных расходов стоимость Заказчик может позволить разработчику сохранить за собой право владения программным кодом с последующим его использованием в других проектах. Условия контракта При этом назначенная цена может быть ниже, чем в том случае, если право на программный код передано заказчику При изменении требований к ПО организация может Изменение снизить цену с тем, чтобы выиграть контракт. Если требований контракт уже заключен, за изменение требований можно назначить дополнительную цену Фирмы, испытывающие финансовые затруднения, для получения заказа могут снизить цены на свои Финансовая разработки. Как правило, лучше сегодня получить стабильность более низкую прибыль или даже работать на уровне самоокупаемости, чем обанкротиться в будущем Производительность Производительность в промышленности обычно измеряется путем деления количества единиц выпущенной продукции на количество человеко-часов, необходимых для их производства. Однако в области разработки ПО любая задача имеет несколько вариантов решения, каждый со своими особенностями. Одно проектное решение отличается эффективным способом выполнения, другое имеет программный код, который легко читается либо удобен в эксплуатации. Поэтому не имеет смысла сравнивать уровни производительности при разработке решений с разными качественными характеристиками. Несмотря на это, менеджеры могут оценить производительность самих специалистов по разработке программного обеспечения. Это понадобится при оценивании проекта и определении эффективности усовершенствования процесса и технологии разработки ПО. Оценка производительности в этом случае будет основана на измерении количественных показателей программных продуктов и последующем делении их на количество усилий, затраченных на разработку этих продуктов. При этом можно использовать два типа показателей. 1. Показатель размера. Зависит от размера выходного результата очередного этапа работ. Наиболее часто применяемым критерием такого типа является количество строк разработанного программного кода. За аналогичный показатель также можно взять количество инструкций объектной программы или количество страниц системной документации. 2. Функциональный показатель. Зависит от функциональных возможностей программного продукта в целом. Производительность в этом случае выражается количеством полезных выполняемых функций, разработанных в определенный отрезок времени. К наиболее распространенным показателям этого типа относится количество функциональных и объектных точек. Количество строк программного кода за человеко-месяц – наиболее популярный критерий оценки производительности. Он определяется путем деления общего количества строк кода на количество времени в человекомесяцах, которое потребуется для завершения проекта. Это время, потраченное на анализ, проектирование, кодирование, тестирование и разработку документации программного продукта. Данный подход впервые появился еще во время массового использования таких языков программирования, как FORTRAN, язык ассемблера и COBOL. Затем программы переводились на перфокарты, каждая из которых содержала по одному оператору. Таким образом, было легко подсчитывать количество строк кода. Оно соответствовало количеству перфокарт в колоде. Однако программы, написанные на языках типа Java или C++, состоят из описаний, выполняемых операторов и комментариев. Они также могут включать макрокоманды, которые состоят из нескольких строк кода. С другой стороны, в одной строке может находиться не один, а несколько операторов. Таким образом, соотношения между операторами и строками в листинге могут быть достаточно сложными. Одни методы подсчета строк основываются только на выполняемых операторах; другие подсчитывают выполняемые операторы и объявления данных; третьи ведут подсчет всех строк программы, независимо от их содержимого. Рядом авторов были предложены определенные стандарты подсчета строк в различных языках программирования , однако они не приобрели широкой популярности. Поэтому практически невозможно сравнивать производительность различных компаний-разработчиков, если только все они не используют один и тот же метод подсчета строк кода. Также может ввести в заблуждение и сравнение производительности программистов, пишущих на разных языках программирования. Чем выразительнее язык, тем ниже производительность. Это "странное" утверждение объясняется тем, что при оценивании производительности создания ПО берется во внимание вся деятельность по разработке программного продукта, тогда как данная система измерения основывается лишь на оценивании процесса программирования. Для примера возьмем систему, которая должна быть написана с помощью кода ассемблера (5000 строк) или с помощью языка высокого уровня (1500 строк). Время выполнения различных этапов создания ПО показано в табл. 2. Специалист, программирующий на языке ассемблера, будет иметь производительность 714 строк в месяц, а у программиста, работающего с языком высокого уровня, производительность будет в два раза ниже – 300 строк в месяц. И это несмотря на то, что программирование на языке высокого уровня стоит дешевле и занимает меньше времени. Таблица 2. Время выполнения этапов разработки программной системы Анали з Проектирова Кодирование (недел ние (недели) (недели) и) Язык ассембле ра Язык высоког о уровня Разме р Затраченное Производительн (строк время ость (строк в и (недели) месяц) кода) Язык ассембле ра Тестирова Документиров ние ание (недели) (недели) Язык высоког о уровня Альтернативой показателю размера при оценивании производительности может служить функциональный показатель. В этом случае можно избежать тех "аномалий" в оценке производительности, которые встречаются при использовании показателя размера, так как функциональность не зависит от языка программирования. Одним из наиболее распространенных методов этого типа является метод функциональных точек. Функциональные точки не зависят от применяемого языка программирования, благодаря чему появилась возможность сравнения производительности разработки программных систем, написанных на различных языках программирования. Критерием оценки производительности выступает количество функциональных точек, созданных за человеко-месяц. Функциональная точка – это не какая-то отдельная характеристика программного продукта, а целая комбинация его свойств. Подсчет общего количества функциональных точек в программе проводится путем измерения или оценивания следующих свойств программы. • Интенсивность использования ввода и вывода внешних данных. • Взаимодействие системы с пользователем. • Внешние интерфейсы. • Файлы, используемые системой. Сложность каждого из указанных критериев оценивается отдельно, в результате каждому критерию присваивается определенная весовая величина, которая может колебаться от 3 (для простого ввода данных) до 15 баллов за использование сложных внутренних файлов. Можно использовать весовые величины или величины, основанные наличном опыте. Нескорректированный подсчет функциональных точек (unadjusted function-point count – UFC) выполняется путем вычисления суммы произведений оценки каждого фактора (количество элементов, составляющих данный фактор) на выбранную весовую величину этого фактора: UFC = ∑ (количество элементов данного типа) х (весовая величина). Первоначальный метод подсчета функциональных точек был в дальнейшем усовершенствован путем добавления тех факторов, значение которых зависит от общей сложности проекта. Здесь принимается во внимание степень распределенности обработки данных, многократность использования программных элементов, качество функционирования и т.п. Значение, полученное при нескоректированном подсчете функциональных точек, нужно умножить на факторы, определяющие сложность проекта, в результате будет получено итоговое значение. Вместе с тем в отмечено, что оценка сложности несет в себе также и субъективный фактор, так как подсчет функциональных точек зависит от лица, проводящего оценивание. Люди имеют разные понятия о сложности. Так как подсчет функциональных точек зависит от мнения оценивающего, существует множество вариаций подсчета функциональных точек. Это приводит к разным взглядам на значимость функциональных точек . Однако многие практики заявляют, что, несмотря на все недостатки, на практике этот метод себя оправдывает . Альтернативой функциональным точкам являются объектные точки, особенно если при разработке ПО используется язык программирования четвертого поколения. Метод объектных точек применяется в модели оценивания СОСОМО 2, которая рассматривается далее в главе. (Объектные точки – это отнюдь не классы объектов, которые производятся в результате применения объектно-ориентированного подхода в работе над программой, что можно было бы предположить, исходя из названия.) Количество объектных точек в программе можно получить путем предварительного подсчета ряда элементов. 1. Количество изображений на дисплее. Простые изображения принимаются за 1 объектную точку, изображения умеренной сложности принимаются за 2 точки, а очень сложные изображения принято считать за 3 точки. 2. Количество представленных отчетов. Для простых отчетов назначаются 2 объектные точки, умеренно сложным отчетам назначаются 5 точек. Написание сложных отчетов оценивается в 8 точек. 3. Количество модулей, которые написаны на языках третьего поколения и разработаны в дополнение к коду, написанному на языке программирования четвертого поколения. Каждый модуль на языке третьего поколения считается за 10 объектных точек. Преимущество данного метода состоит в том, что объектные точки легко оценить исходя из высокоуровневой спецификации программного продукта, поскольку они связаны с конкретными объектами – изображениями, отчетами и модулями на языках программирования третьего поколения. Количество функциональных и объектных точек можно оценить уже на ранней стадии выполнения проекта. Оценку этих параметров можно начинать сразу после разработки внешних взаимосвязей системы. Именно на этой стадии очень сложно провести точную оценку размера программы, беря за основу только строки кода. Более того, язык программирования на этом этапе может быть еще не выбран. Вместе с тем оценка на ранней стадии особенно необходима, если используются модели алгоритмического оценивания себестоимости, которые рассматриваются далее. Подсчет функциональных точек можно проводить параллельно с методом подсчета количества строк кода. Количество функциональных точек при этом используется для оценивания окончательной величины кода. На основе анализа выполнения предыдущих программных проектов для определенных языков программирования можно оценить среднее количество строк кода (average number of lines of code – AVC), необходимых для реализации одной функциональной точки. В этом случае получим оценку размер кода нового проекта, рассчитанную следующим образом: размер кода = AVC х количество функциональных точек. Значение AVC варьируется от 200 до 300 строк кода на одну функциональную точку в языке ассемблера и от 2 до 40 строк кода для языков программирования четвертого поколения. Производительность отдельных программистов, работающих в организации-разработчике, зависит от множества факторов, влияющих на их работу. Некоторые из наиболее значимых факторов представлены в табл. 3. Однако различия в индивидуальных способностях программистов намного важнее всех этих факторов. В исследовании ранних этапов программирования отмечено, что производительность некоторых программистов в 10 раз выше, чем у других. Это наблюдение подтверждается и моим личным опытом. Большие команды, члены которых имеют необходимый набор личностных качеств и способностей, будут иметь "среднюю" производительность. Вместе с тем в командах небольшого размера общая производительность во многом зависит от индивидуальных умений и навыков каждого члена команды. Таблица 3. Факторы, влияющие на производительность программиста Фактор Описание Для эффективной разработки программного продукта Опыт разработки необходимо знание той предметной области, где будет ПО для данной эксплуатироваться разрабатываемое ПО. Инженеры, предметной имеющие понятие об этой предметной области, выявят области наивысшую производительность Процесс управления качеством Размер проекта Поддержка технологии разработки ПО Рабочая обстановка Применяемый метод программирования может оказать существенное влияние на производительность написания кода. Этот фактор рассматривается в главе 25 Чем больше проект, тем больше времени уходит на согласование различных вопросов внутри группы разработчиков. Тем самым уменьшается время, расходуемое непосредственно на разработку ПО, и снижается производительность Хорошая поддержка технологии разработки ПО, например CASE-средства или системы управления конфигурацией, может значительно повысить производительность труда программиста Как уже упоминалось в главе 22, спокойное рабочее окружение с индивидуальными рабочими местами способствует повышению производительности Должен отметить, что не существует какой-либо величины, определяющей "среднюю" производительность программиста, которую можно было бы применять в разных организациях и при создании разных программных продуктов. Например, при разработке больших систем производительность может быть очень низкой и доходить до 30 строк за человеко-месяц. На простых программных системах производительность может подняться до 900 строк в месяц. В некоторых источниках высказано предположение, что производительность программиста может колебаться от 4 до 50 объектных точек в месяц, в зависимости от наличия средств поддержки и от способностей программиста. Недостатком оценок, которые основываются на подсчете объема выполненной работы или определении количества затраченного времени, является то, что они не принимают во внимание такие важные нефункциональные свойства разрабатываемой системы, как надежность, удобство эксплуатации и т.п. Обычно здесь работает простое правило: больше – значит, лучше. Бек (Beck,) приводит удачное замечание, что если вы работаете над постоянным усовершенствованием и упрощением системы, то подсчет строк ничего не даст)*. Описанные методы также не учитывают многократность использования программного продукта. В действительности необходимо оценить стоимость повторного использования определенной системы с данным набором функциональных и качественных характеристик, имеющей собственные показатели удобства сопровождения и т.д. Все эти параметры только косвенно соотносятся с такими количественными показателями, как, например, размер системы. Трудности также могут возникнуть в случае, если менеджеры используют показатели производительности для оценивания способностей персонала. В этом случае качество выполненной программистом работы может отойти на второй план по отношению к производительности. Может случиться, что "менее продуктивный" программист создаст код, который будет надежнее, понятнее и дешевле в использовании. Поэтому нельзя пользоваться показателями производительности как единственным источником оценивания труда программиста. Методы оценивания Не существует простого метода определения будущих затрат, необходимых для разработки программного продукта. Начальное оценивание можно провести, основываясь на определенных пользовательских требованиях высокого уровня. Но заранее не известно, какие технологии будут применяться при разработке ПО и какие компьютеры будет использоваться. Также невозможно предугадать, какие люди будут работать над проектом и какие у них будут навыки и опыт. Это показывает, что чрезвычайно трудно провести точную оценку стоимости проекта на самом раннем этапе. Более того, основная проблема в оценке себестоимости проектов заключается в низкой точности применяемых методов оценивания. Часто в расчет себестоимости проекта закладывается его окупаемость. Таким образом, первоначальная оценка себестоимости определяет бюджет проекта, за рамки которого нельзя выходить при реализации проекта. Вместе с тем я не знаю ни одного реализованного проекта, где бы стоимость не корректировалась по ходу его выполнения. Но всегда в ходе реализации проекта фактические расходы сравниваются с предварительной оценкой затрат. Несмотря ни на что, организации-разработчики обязательно должны оценивать затраты на разработку и себестоимость программного продукта. Для этого можно применять методы, описанные в табл. 4. Таблица 4. Методы оценки себестоимости Метод Алгоритмическое моделирование себестоимости Оценка эксперта Описание Метод основан на анализе статистических данных о ранее выполненных проектах, при этом определяется зависимость себестоимости проекта от какого-нибудь количественного показателя програ.ммного продукта (обычно это размер программного кода). Проводится оценка этого показателя для данного проекта, после чего с помощью модели прогнозируются будущие затраты Проводится опрос нескольких экспертов по технологии разработки ПО, знающих область применения создаваемого программного продукта. Каждый из них дает свою оценку себестоимости проекта. Потом все оценки сравниваются и обсуждаются. Этот процесс повторяется до тех пор, пока не будет достигнуто согласие по окончательному варианту предварительной сметы проекта Этот метод используется в том случае, если в данной области применения создаваемого ПО уже Оценка по аналогии реализованы аналогичные проекты. В таком случае при оценке затрат для сравнения берутся предыдущие проекты. Согласно этому закону усилия, затраченные на работу, распределяются равномерно по выделенному на проект времени. Здесь критерием для оценки затрат по проекту являются человеческие ресурсы, а Закон Паркинсона не целевая оценка самого программного продукта. Если проект, над которым работает пять человек, должен быть закончен в течение 12 месяцев, то затраты на его выполнение исчисляются в 60 человеко-месяцев Затраты на проект определяются наличием тех Назначение цены с средств, которые имеются у заказчика. Поэтому целью выиграть себестоимость проекта зависит от бюджета заказчика, контракт а не от функциональных характеристик создаваемого продукта Авторы Hihn и Habib-agahi H описали в одной из своих научных работ эксперимент, в котором менеджеров попросили провести предварительную оценку размера будущей программной системы и необходимых для ее разработки затрат. Менеджеры при этом использовали мнения экспертов и оценку по аналогии. Результаты эксперимента показали, что менеджеры провели достаточно точную оценку затрат, однако определение размера будущей системы при этом было менее точным. Это означает, что оценка затрат, основанная только на данных о размере программы, будет неточной. Методы предварительной оценки себестоимости могут выполняться с применением нисходящего или восходящего подходов. При нисходящем подходе оценка себестоимости начинается на уровне системы: рассматриваются функциональные возможности программы в целом и то, как эти возможности реализуются посредством функций более низкого уровня. Здесь учитывается себестоимость таких этапов разработки, как сборка системы, управление конфигурацией и создание технической документации. В отличие от нисходящего подхода, восходящий начинается на уровне системных компонентов. Система разбивается на компоненты и определяются затраты на разработку каждого из них. Затем эти затраты суммируются для определения полной стоимости проекта. Недостатки восходящего подхода являются достоинствами нисходящего и наоборот. Восходящий подход может недооценить затраты, необходимые для решения сложных проблем, возникающих при разработке таких специфических компонентов системы, как интерфейсы для нестандартных аппаратных средств. Детального обоснования для составления сметы затрат в этом случае не существует. Нисходящий подход, напротив, дает такое обоснование, а также возможность рассмотреть каждый компонент в отдельности. Вместе с тем данный подход больше акцентирует внимание на таких этапах реализации проекта, как, например, сборка системы. Кроме того, нисходящий подход является более дорогостоящим. Для его применения нужно иметь хотя бы предварительный результат проектирования системы с тем, чтобы оценить каждый ее компонент. Каждый метод оценивания, безусловно, имеет слабые и сильные стороны. Для работы с большими проектами необходимо применить несколько методов оценивания себестоимости для их последующего сравнения. Если при этом получаются совершенно разные результаты, значит, информации для получения более точной оценки недостаточно. В этом случае необходимо воспользоваться дополнительной информацией, после чего повторить оценивание, и так до тех пор, пока результаты разных методов не станут достаточно близкими. Описанные методы оценивания применимы, если документированы требования для будущей системы. В таком случае существует возможность определить функциональные характеристики разрабатываемой системы. Обычно все большие проекты разработки ПО имеют документ, в котором определены требования к системе. Однако во многих проектах оценка затрат проводится только на основании проекта требований к системе. В этом случае лица, участвующие в оценке стоимости проекта, будут иметь минимум информации для работы. Процедуры анализа требований и создания спецификации весьма дорогостоящи. Поэтому менеджерам компании следует составить смету на их выполнение еще до утверждения бюджета для всего проекта. Во многих случаях популярной становится стратегия ценообразования с целью "выиграть контракт". Можно согласиться, что данная фраза звучит несколько некорректно и не по-деловому, однако этa стратегия на самом деле себя оправдывает. Стоимость работы согласовывается на основании предварительного проекта предложения. Далее проводятся переговоры между компанией-исполнителем и заказчиком с тем, чтобы обсудить детальное техническое задание, которое, однако, ограничивается согласованной суммой. Продавец и заказчик также должны обсудить приемлемые функциональные возможности системы. Здесь основополагающим фактором для многих проектов становятся возможности бюджета, а не требования к системе. Требования всегда можно изменить так, чтобы не выходить за рамки принятого бюджета. При оценке себестоимости проекта менеджеры должны всегда помнить о том, что между прошлыми проектами и будущими разработками может быть существенная разница. Только за последние 10 лет на свет появился целый ряд новейших разработок и технологий. Многие менеджеры очень мало ознакомлены, а иногда просто не имеют понятия об этих технологиях и о том, какое влияние они могут оказать на проект. Вот несколько примеров технических и технологических новшеств, которые могут повлиять на оценку стоимости проекта, основанную на предыдущем опыте. • Появление объектно-ориентированного программирования вместо процедурного. • Применение систем типа клиент/сервер вместо систем, основанных на мэйнфреймах. • Применение готовых коммерческих пакетов программного обеспечения вместо собственной разработки компонентов системы. • Повторное использование компонентов системы вместо новых разработок. • Использование CASE-средств и генераторов программ вместо разработки ПО без применения средств поддержки. Все эти факторы отнюдь не облегчают задачу менеджера в оценке стоимости программной продукции. И в этом случае предыдущий опыт не всегда оказывается полезным для проведения такой оценки. Что такое ИТ-услуга. Идея, стоящая за развитием библиотеки передового опыта информационных технологий (IT Infrastructure Library, ITIL), основывается на понимании того, что организации все больше зависят от информационных технологий (ИТ) для достижения своих бизнес-целей. Эта зависимость ужесточает требования к уровню и росту спроса на качество в предоставлении ИТ-услуг. Предметом рассмотрения концепции ИТ cервис-менеджмента (IT Service Management, ITSM) является предоставление и поддержка ИТ-услуг, соответствующих бизнес-потребностям организации. Поставщики ИТ-услуг постоянно борются за улучшение качества, стараясь одновременно снижать цену или, по крайней мере, оставлять ее неизменной. Согласно ITIL, под ИТуслугой подразумевается совокупность ИТ-систем, используемых для обеспечения бизнес-деятельности предприятия. Иными словами, ИТподразделение компании уже не просто меняет картриджи у принтеров или администрирует сервер, где расположена база данных бухгалтерской программы, а предоставляет услуги по печати и поддержке работоспособности финансово-учетной системы. В настоящее время зависимость большинства компаний от ИТ сильно возросла по сравнению с серединой прошлого века, и тенденция развития этой области такова, что вклад ИТ в производственные процессы будет только увеличиваться. В результате ИТ из вспомогательного производства, отвечавшего в первую очередь за информационную поддержку бизнеспроцессов предприятия, переходит в разряд основного производства, то есть участвует в цепочке формирования прибавочной стоимости продукции совместно с основными производственными подразделениями. Кроме того, в денежном исчислении затраты на ИТ составляют значительную часть бюджета любой организации и их доля постоянно увеличивается. Приобретение новых серверов, обновление парка вычислительной техники, внедрение новых, более прогрессивных информационных технологий необходимо для повышения конкурентоспособности предприятия на рынке, для более эффективного и оперативного реагирования на изменение внешних условий и для получения максимальной прибыли. Таким образом, учитывая все возрастающую долю затрат на ИТ в общей структуре затрат предприятия, необходимо внедрять более эффективные методы управления для снижения себестоимости и повышения качества выпускаемой продукции (товаров и услуг). Построение управленческого учета на предприятии с выделением центра финансовой ответственности (ЦФО) совместно с внедрением сервисноориентированного учета затрат на ИТ позволит ИТ-подразделению стать полноправным партнером для бизнеса, не зависеть от него, а зарабатывать деньги самостоятельно. Для этого необходимо определить, насколько затраты на обеспечение бизнес-функций компании со стороны ИТ включаются в себестоимость того или иного вида продукции (товаров и услуг). Практика «выставления счетов», то есть демонстрация бизнесподразделениям реальных затрат на ИТ-сервисы, подготовит бизнес к тому, что за все надо платить. Это сделает ИТ-подразделение равноправным партнером для бизнеса и позволит рассматривать ИТ-подразделение не как центр затрат, а как центр прибыли. Внедрение процессов управления ИТ-инфраструктурой в соответствии с рекомендациями библиотеки ITIL позволит ИТ-подразделению заключать с партнерами (как с другими подразделениями внутри компании, так и с внешними потребителями) соглашения об уровне сервиса (Service Level Agreement, SLA), в свою очередь, бизнес сможет получать услуги в том объеме и с таким уровнем качества, который оговорен в данном соглашении. Внедрение SLA позволит формализовать отношения бизнеса и ИТ, вывести их на новый уровень, где все взаимные обязательства формализованы в соглашении, что безусловно повысит эффективность управления как ИТ, так и компанией в целом. Принципы построения сервисно-ориентированного учета затрат Если раньше все затраты на ИТ считались косвенными и относились на себестоимость продукции в соответствии с методикой распределения косвенных затрат, то теперь необходимо строить процесс учета затрат и калькуляции себестоимости ИТ-услуг по-иному — относить эти затраты к затратам основного производства и использовать для их учета методики, применимые к затратам данного типа. Такой подход позволяет управлять деятельностью ИТ-подразделений, выбрав в качестве объекта управления процессы предоставления набора ИТуслуг, обеспечивающих бизнес-потребности компании. Такие ИТ-услуги в ITIL получили название бизнес-услуг. Комплекс бизнес-услуг сводится в Каталог бизнес-услуг, на основании которого ИТ-подразделение и строит свою работу. В книге библиотеки ITIL «Предоставление сервисов (Service Delivery)» для учета ИТ-затрат рекомендован «метод прямых затрат». Он основан на разделении затрат на прямые (direct) и косвенные (indirect) с дальнейшим разделением косвенных затрат на соотнесенные, распределяемые в соответствии с выбранным драйвером (базой) распределения, и несоотнесенные, которые включаются в себестоимость в виде добавочного процента. Важно, что в качестве объекта затрат ITIL указывает ИТ-услугу. Таким образом, ИТ-услуга при построении системы учета затрат выступает в качестве шифра производственных затрат (ШПЗ). Определить, какие затраты ИТ-подразделения будут считаться прямыми, а какие — косвенными, довольно просто. Представим ИТ-отдел в виде «черного ящика», входом в который является служба технической поддержки пользователей Service Desk, а выходом (результатом деятельности) — услуги, предоставляемые бизнес-потребителям в соответствии с Каталогом бизнес-услуг. Затраты ИТ-подразделения, которые можно сразу отнести на предоставление бизнес-услуг, являются прямыми, а те, что связаны с управлением и операционной деятельностью по обслуживанию ИТинфраструктуры, — косвенными. Например, затраты на обслуживание сервера ERP-системы, на содержание персонала, отвечающего за поддержку и сопровождение ERP, можно прямо отнести на себестоимость сервиса «Поддержка работоспособности системы управления ресурсами предприятия». Те затраты, для которых в явном виде нельзя указать объект затрат, считаются косвенными. Например, если один и тот же сервер является контроллером домена и сервером электронной почты, то затраты на его обслуживание разделяются для отнесения на себестоимость сервисов «Электронная почта» и «Единое информационное пространство». Какую базу для распределения (драйвер распределения — пропорцию для разнесения общей суммы на себестоимость этих сервисов) выбрать? Насколько выбранный драйвер будет релевантным, то есть будет отражать реальное распределение затрат между сервисами? Получение ответов на эти вопросы и разработка драйверов распределения, принципов отнесения косвенных затрат на себестоимость бизнес-услуг — одна из ключевых задач построения управленческого учета в рамках ИТ-подразделения. Также косвенными следует считать затраты на содержание административно-управленческого персонала (АУП), на размещение, оплату электроэнергии, телефонной связи и т.п. Построение сервисно-ориентированной модели учета затрат, направленной на предоставление ИТ-подразделением услуг бизнесподразделениям компании, и реализация рекомендованных в ITIL методик являются важными задачами совершенствования управленческого учета в масштабе предприятия. Поэтому проводить его невозможно без понимания высшим руководством компании необходимости улучшения управления ИТ, в том числе и финансовой составляющей данного процесса. В то же время в построении системы учета затрат в ИТ должны принимать активное участие подразделения, отвечающие за ведение управленческого учета в рамках всей компании. Поскольку объекты затрат на ИТ должны формироваться в рамках единой учетной политики предприятия, себестоимость ИТ-услуг должна «встраиваться» в себестоимость объектов затрат компании. Внедрение метода учета затрат, в котором объектами учета являются бизнес-услуги, может потребовать перестройки и улучшения учета в ИТподразделении. Например, учет рабочего времени с аналитикой по видам деятельности, измерение ИТ-ресурсов (загрузка, мониторинг и т.п.), учет затрат на размещение, контрактов с поставщиками и т.п. Другие элементы, которые используются при построении учета в ИТ и определяют модель затрат на ИТ, включают:    бюджетные рекомендации; политики ценообразования и взаиморасчетов с потребителями; инвестиционные программы. Построение учета в ИТ — комплексная задача, во время внедрения которой необходимо ограничить уровень детализации аналитических признаков, поскольку в этом случае затраты на организацию учета могут превысить преимущества для бизнеса от построения сервисноориентированной модели затрат. Исходя из этого, можно сформулировать требования к учетной системе ИТ-подразделения:       отслеживание выполнения бюджетных лимитов. Контроль «планфакт», сопоставление реальных расходов с заложенными в бюджете показателями; участие в разработке портфеля инвестиций в ИТ для достижения планируемых стратегических и тактических бизнес-целей, повышения эффективности и качества предоставляемых бизнесу компании ИТуслуг; выделение центров затрат, связанных с предоставлением ИТ-услуг; приоритезация использования ИТ-ресурсов в соответствии с бизнеспотребностями; предоставление информации для принятия оперативных решений в управлении ИТ с пониманием структуры и взаимосвязи затрат и их элементов и, как следствие, минимизации рисков; поддержка, при необходимости, системы взаиморасчетов за оказываемые ИТ-услуги. Построение учетной системы (accounting) в ИТ и политики взаиморасчетов с потребителями ИТ-услуг (charging) является комплексной задачей, которая должна согласовываться с принятой в компании учетной политикой. Основной задачей взаиморасчетов с бизнес-потребителями является возмещение затрат на предоставление ИТ-услуг. Учетная система отвечает за предоставление информации о первичных внутренних транзакциях ИТ-подразделения, связанных с предоставлением ИТ-услуг с необходимыми аналитическими признаками. Иначе говоря, политика взаиморасчетов определяет, сколько и в какой форме (вид оплаты, порядок платежей, валюта расчета и т.п.) должен заплатить потребитель за предоставляемые сервисы, а учетная система описывает правила регистрации хозяйственных операций, связанных с деятельностью ИТ-отдела, в учетном журнале (аналогично журналу проводок в бухгалтерии) с указанием требуемых аналитических признаков (например, услуга, подразделение, исполнитель и пр.), а также правила использования этих данных при отнесении их на себестоимость в соответствии с выбранными центрами затрат. Данная задача решается в рамках процессов, описанных в книге ITIL «Поддержка услуг (Service Support)». Менеджмент ИТ-подразделения должен выбрать, в каком виде будет внедряться учетная система для управления ИТ. Это может быть либо только учет затрат без взаиморасчетов с потребителями, либо комплексная система, включающая выставление счетов и предоставление бизнесу данных о реальной себестоимости ИТ-услуг. В зависимости от выбранной схемы можно выделить три различных типа ЦФО, которые могут быть сопоставлены ИТ-подразделению:  центр затрат — основной задачей является собственно учет затрат и калькуляция себестоимости ИТ-услуг. В качестве объектов учета выбираются как бизнес- (внешние), так и операционные (связанные с   внутренней деятельностью) сервисы. Эти данные могут быть использованы для планирования бюджета ИТ-отдела на будущие периоды. Преимуществом данного типа ЦФО является то, что ИТруководство имеет представление о реальных затратах на предоставление ИТ-услуг, что позволяет принимать обоснованные управленческие решения и более точно оценивать инвестиции в ИТ. Руководитель ИТ-подразделения на основании этих данных может видеть, насколько рентабельно предоставление конкретного сервиса, имеет ли смысл инвестировать средства в улучшение качества услуги по соотношению «цена/качество»; центр возмещения — в отличие от центра затрат, объектом учета являются только внешние по отношению к ИТ, то есть бизнес-услуги. Здесь учету подлежат не только прямые и косвенные затраты, которым можно в явном виде сопоставить денежный эквивалент, но и скрытые затраты, связанные с потерями бизнеса из-за нарушений и сбоев в предоставлении ИТ-услуг. Преимуществом данного типа ЦФО является то, что управление затратами ориентировано в первую очередь на интересы бизнеса, предоставление бизнесу услуг максимального качества при минимально возможных затратах; центр прибыли — суть данного типа ЦФО заключается в том, что ИТподразделение становится полноправным бизнес-партнером в рамках компании. Соответственно главной целью центра прибыли является финансовый результат. Иначе говоря, в этом случае ИТ-подразделение является самоокупаемой структурой в рамках компании. В этом случае можно выделить две основные характеристики: - услуги четко идентифицированы и предоставляются (продаются) по рыночным ценам, - цены на предоставляемые товары или услуги реагируют на изменение рыночной ситуации и меняются в соответствии с требованиями рынка. При выборе модели ЦФО при построении учетной системы необходимо учитывать ряд факторов, связанных или не связанных напрямую с экономическими факторами:   уровень корпоративной культуры в компании — насколько менеджмент и персонал компании морально готов к тому, что за все надо платить? Насколько высшее руководство понимает роль ИТ в основном бизнесе компанией и влияние качества оказываемых ИТуслуг на качество производимой компанией продукции и эффективность бизнес-деятельности? существующую в компании учетную систему — система учета в ИТотделе должна «вписываться» в общую систему управленческого учета компании. Данные по себестоимости ИТ-услуг должны быть востребованы экономистами компании, отвечающими за калькуляцию себестоимости готовой продукции (товаров и услуг). Поэтому  построение учетной системы для ИТ должно вестись в тесном контакте с подразделениями компании, отвечающими за постановку управленческого учета в рамках всего предприятия; уровень зрелости процессов управления ИТ-подразделением — для более точного определения прямых затрат, для создания драйверов распределения косвенных затрат необходимо, чтобы все действия сотрудников ИТ-подразделения были зафиксированы в единой регистрационной системе. Внедрение процессов ITIL, описанных в книге «Поддержка сервисов», дает возможность построить такую регистрационную систему и определить правила занесения туда записей о первичных учетных транзакциях ИТ-отдела. Таким образом, перед внедрением управления ИТ-финансами рекомендуется внедрение таких процессов ITIL, как «Управление инцидентами», «Управление проблемами», «Управление изменениями». Построение модели затрат. При построении модели затрат необходимо сначала выделить факторы затрат, разделить затраты по категориям. Такое разделение позволит получить более понятную структуру затрат на ИТ. ITIL рекомендует выделять следующие категории (типы) затрат:       затраты на аппаратное обеспечение; затраты на программное обеспечение; затраты на персонал; затраты на размещение (аренда, обслуживание производственных помещений и т.п.); затраты на внешние сервисы; трансфертные затраты. Затраты на внешние сервисы включают расходы ИТ, связанные с услугами технической поддержки или иными сервисами, получаемыми ИТподразделением от внешних сервис-провайдеров. Это может быть техническая поддержка, обслуживание и сопровождение ERP-системы, предоставление интернет-каналов и каналов связи, аутсорсинг объектов ИТинфраструктуры и т.п. Трансфертные затраты являются расходами по внутренним взаиморасчетам между подразделениями компании. Этот тип затрат выделяется в случае принятия при построении учетной системы модели ЦФО Центр прибыли. Если ИТ-подразделение продает свои услуги бизнесу, то и бизнес тоже предоставляет услуги для ИТ-подразделения на коммерческой основе. Например, это могут быть:  затраты на приобретение ПК от имени бизнес-пользователя;    расчеты с департаментом финансов за построение модели учета затрат в ИТ; услуги департамента по персоналу в части подбора кадров; услуги бухгалтерии — в части расчета, начисления и выдачи заработной платы в ИТ, юридического отдела в части проверки договоров и т.п. Все эти затраты выделяются в отдельную категорию для того, чтобы была возможность видеть, насколько они влияют на себестоимость и качество предоставляемых для бизнеса ИТ-услуг. Как было сказано ранее, затраты могут делиться на прямые и непрямые (косвенные). На рисунке показана модель учета затрат, описанная в ITIL в разделе Financial Management for IT Services. Прямые затраты относятся на бизнессервисы и включаются в их себестоимость в явном виде. Косвенные (непрямые) делятся на соотнесенные, которые можно распределить между сервисами в соответствии с драйверами распределения, и несоотнесенные — для которых не представляется возможным выбрать такой драйвер. Определение себестоимости ИТ-услуги методом прямых затрат Рассмотрим упомянутый выше пример построения драйверов распределения: 1. В компании имеется сервер, который является контроллером домена и одновременно почтовым сервером. В этом случае в качестве драйвера распределения можно выбрать процентное соотношение занимаемой памяти процессами, обслуживающими сервисы «Электронная почта» и «Единое информационное пространство». 2. Выделение прямых затрат возможно на основании журнала инцидентов, в котором регистрируются все работы, связанные с технической поддержкой пользователей и устранением сбоев в предоставлении услуг, а также построение релевантных драйверов распределения косвенных соотнесенных затрат на основании затрат рабочего времени на устранение инцидента. Действительно, регистрируя инцидент, оператор службы Service Desk указывает в качестве параметров сервис, с которым данный инцидент связан, а также рабочую группу (или исполнителя), которая эти работы будет выполнять. Зная стоимость часа каждого работника для компании, можно отнести затраты, связанные с его деятельностью по решению инцидентов, на конкретный сервис. Такие затраты будут прямыми. Однако ИТ-специалисты, помимо технической поддержки пользователей, выполняют еще работы, связанные с обеспечением работоспособности ИТ-инфраструктуры в рамках своей операционной деятельности. Затраты, связанные с такими работами, а также расходы на содержание административно-управленческого персонала ИТ, службы Service Desk, являются косвенными затратами, которые можно распределить на бизнес-услуги в соответствии с процентом прямых расходов по технической поддержке пользователей. Иначе говоря, на основании данных журнала инцидентов можно выделить временные затраты, связанные с решением инцидентов по каждой из ИТ-услуг, и на основании этих данных составить пропорцию для отнесения на себестоимость ИТ-услуг расходов на персонал, не связанных напрямую с внешними сервисами. Приведенные примеры показывают, что для построения драйверов распределения требуется внедрение учетной системы, регистрирующей деятельность персонала ИТ с необходимыми аналитическими признаками. В идеале вся деятельность сотрудников ИТ должна быть зафиксирована и отнесена либо к бизнес-, либо к операционным сервисам. Решение такой задачи возможно, например, при помощи внедрения аналитического табеля учета рабочего времени ИТ-специалистов. Несоотнесенные непрямые затраты также должны включаться в себестоимость сервисов, чтобы общая сумма затрат на ИТ из управленческого учета компании совпадала с суммарной себестоимостью ИТ-услуг. Они включаются в себестоимость ИТ-услуг как некоторый добавочный процент (например, распределяются в соответствии с прямыми и косвенными соотнесенными затратами). Рассмотренные выше примеры являются частными случаями практической реализации учетной системы в ИТ. Следует понимать, что ITIL, являясь библиотекой лучшего мирового опыта, не дает детальных рекомендаций. Иначе говоря, ITIL указывает, ЧТО надо делать, но не говорит КАК. Выбор конкретной системы учета, разработка политик, методов расчета себестоимости, отнесения непрямых затрат является задачей процесса построения учетной системы в ИТ, которая должна решаться в рамках учетной политики, принятой в компании. Пример калькуляции себестоимости ИТ-услуги Построение модели учета затрат, ориентированной на предоставление ИТ-услуг, следует проводить в несколько этапов. В табл. 1 представлен пример бюджета ИТ-подразделения. Общая сумма затрат на ИТ в год в данном примере составляет 500 тыс. долл. Таблица 1. Структура затрат на ИТ Статья затрат Аппаратное обеспечение UNIX-сервер Сервер Windows NT Контроллер домена PC (рабочие станции) — 50 шт. Роутер — 5 шт. LAN — кабельная система Программное обеспечение Oracle Database Server ERP SAP R3 Microsoft Exchange server Клиент Microsoft Exchange (50 пользователей) Microsoft Windows (50 пользователей) Клиент Office (20 пользователей) Затраты на Ежегодные Затраты в приобретение, эксплуатационные годовом долл. расходы, долл. исчислении, долл. 163 200 20 600 75 000 60 000 12 000 8000 1000 28 000 5000 6000 1000 3000 60 000 6500 26 500 4200 600 2000 21 000 3500 10 500 50 000 50 000 12 000 12 000 25 000 3000 25 000 3000 2000 2000 2000 2000 3000 3000 Novell 3000 NetWare Персонал 300 000 Внешние 25 000 сервисы Интернет15 000 провайдер Сопровождени 10 000 е ERP-системы Производстве 20 000 нные помещения Серверная 10 000 Компьютерная 4000 Офис (Service 6000 Desk) Прочие 30 000 затраты Всего 445 600 ИТ оказывает бизнесу следующие услуги:    3000 300 000 25 000 15 000 10 000 20 000 10 000 4000 6000 30 000 500 000 Интернет и электронная почта — дает пользователю возможность работать с корпоративным почтовым ящиком и предоставляет доступ в Интернет по протоколу HTTP. Для организации почтового сервиса используется продукция компании Microsoft (сервер Microsoft Exchange). Услуга включает техническую поддержку пользователей, в том числе установку клиентских приложений, консультации по их применению; ERP — обеспечение функционирования, техническая поддержка и консультации по работе с ERP-системой. Модули «Бюджетирование», «Главная книга», «Касса и банк», «Дебиторы», «Кредиторы», «CRM», «Управление закупками и продажами (склад)», «Управление персоналом и расчет заработной платы». Для серверной части используется отдельный сервер, на котором установлены сервер приложений и СУБД Oracle. Клиентские места выполняются под управлением операционной системы Windows XP. Сервис включает техническую поддержку клиентской и серверной частей (в том числе установку и настройку конфигурации), консультации пользователей; техническая поддержка пользователей — обеспечение функционирования АРМ пользователя, единого информационного пространства, включая контроллер домена, сеть, сетевую печать, техническую поддержку и консультации по работе с компьютером и использованию стандартного ПО. Стандартное ПО состоит из: Microsoft Office, Adobe Acrobat Reader 7.0, WinRAR 3.50. На первом этапе следует разделить услуги на прямые и косвенные. В табл. 2 представлено распределение прямых затрат. К ним относятся затраты на оборудование и программное обеспечение, которое можно прямо соотнести с конкретной ИТ-услугой, внешние сервисы, связанные с поддержкой ERP и предоставлением интернет-каналов. Затраты на персонал делятся на прямые затраты — те подразделения, которые непосредственно можно соотнести с предоставляемыми услугами, и накладные расходы. В данном случае это расходы на содержание директора по ИТ и службы Service Desk, которые нельзя в явном виде поставить в соответствие какому-либо одному ИТ-сервису. Таблица 2. Разделение затрат на ИТ на прямые и косвенные Статья затрат Hardware UNIX-сервер Сервер Windows NT Контроллер домена PC (рабочие станции) — 50 шт. Роутер — 5 шт. LAN — кабельная система Software Oracle Database Server ERP SAP R3 Microsoft Exchange Server Клиент Microsoft Exchange (50 пользователей) Microsoft Windows (50 пользователей) Microsoft Office (20 пользователей) Тип затрат Затрат EER Техническа ыв mail, P, долл. я поддержка, годовом Internet, долл. исчислении долл. долл. 75 000 28 000 12 500 Прямые 28 000 28 000 Косвенные 5000 3000 Косвенные Косвенные 26 500 Прямые Прямые 2000 10 500 Прямые 50 000 5000 12 000 37 000 12 000 Прямые Прямые 25 000 3000 3000 25 000 Прямые 2000 Прямые 2000 2000 Прямые 3000 3000 2000 10 500 8000 2000 Novell NetWare Персонал Прямые затраты Накаладные расходы Внешние сервисы Интернетпровайдер Сопровождение ERP-системы Производственны е помещения Серверная Прямые 3000 300 000 54 000 105 600 Прямые 213 600 54 000 105 600 Косвенные 86 400 Прямые 25 000 15 000 10 000 15 000 15 000 Прямые 10 000 20 000 3000 54 000 54 000 10 000 10 000 Косвенные Компьютерная 4000 Косвенные Офис Трансферт Всего 6000 Косвенные Косвенные 30 000 500 000 74 000 180 600 74 500 Структура расходов на ИТ-персонал представлена в табл. 3. Таблица 3. Структура затрат на ИТ-персонал Подразделение Всего Затраты на сервисы ИТ за год, E-mail, ERP, Техниче долл. Интернет, долл. ская долл. поддержка, долл. Отдел 68 400 68 400 администрирования Отдел 72 000 30 000 12 000 30 000 технической поддержки Отдел 73 200 24 000 25 200 24 000 сопровождения ERP Service Desk 56 400 - АУП 30 000 Итого прямых 213 600 54 000 105 600 54 000 затрат Итого 86 400 косвенных затрат Всего 300 000 Драйвер для 1,00 0,25280 0,49438 0,25280 распределения (К) 9 202 8989 В соответствии с данной таблицей можно выделить прямые затраты на предоставление бизнес-услуг (отделы администрирования, технической поддержки и сопровождения ERP) и косвенные (Service Desk и АУП). Косвенные затраты записываем в строку «Накладные расходы» раздела «Персонал». Вторым этапом определения себестоимости услуги является вычисление драйвера распределения. В качестве драйвера выберем затраты сотрудников ИТ на поддержку пользователей и устранение инцидентов. На основании данных службы Service Desk (журнала инцидентов) мы получили следующее распределение затрат отделов ИТ по обслуживанию ИТ-сервисов (см. табл. 3). На основании этих данных рассчитаем драйвер распределения косвенных соотнесенных затрат по формуле: где Др = Зc/ПЗп, Зс – сумма затрат персонала на сервис; ПЗп – общая сумма прямых затрат на персонал. В результате получаем распределенные косвенные соотнесенные затраты. Следующим этапом является выявление среди косвенных затрат соотнесенных и несоотнесенных. Основным критерием для выделения соотнесенных косвенных затрат является понимание, насколько драйвер распределения является релевантным для данного типа затрат, то есть насколько в данном случае распределенные косвенные затраты на основании выбранной нами пропорции будут соответствовать реальной себестоимости сервиса. Также необходимо учитывать принятую в компании учетную политику. Метод расчета затрат должен соответствовать методике, используемой в компании, поэтому построение учетной системы в ИТ следует вести совместно с экономистами, отвечающими за расчет себестоимости продукции основного бизнеса предприятия. В данном примере в качестве несоотнесенных косвенных затрат можно выбрать затраты на трансферт. Сложив прямые затраты и косвенные соотнесенные, получаем базу для расчета добавочного процента косвенных несоотнесенных затрат. Добавочный процент рассчитывается по формуле: Д(%) = РЗ/Зо, где РЗ –сумма распределенных затрат для ИТ-услуги; Зо – общая сумма распределенных затрат. Под распределенными затратами подразумевается сумма прямых и косвенных соотнесенных затрат. В результате получается полная себестоимость каждой ИТ-услуги, при этом сумма затрат на предоставление всех бизнес-услуг должна быть равна общей сумме затрат на ИТ-подразделение (в нашем примере — 500 тыс. долл.). Таблица 4. Окончательный расчет себестоимости ИТ-услуги. Статья затрат Тип затрат Затраты E-mail, E Техническа в годовом Интернет RP, я исчислении , долл. долл. поддержка, , долл. долл. Hardware 75 000 8722 45 21 222 056 UNIX-сервер Прямые 28 000 28 000 Сервер Соотнесенные 5000 1264 24 1264 Windows NT 72 Контроллер Соотнесенные 3000 758 14 758 домена 83 PC (рабочие Соотнесенные 26 500 6699 13 6699 станции) — 50 шт. 101 Роутер — 5 шт. Прямые 2000 2000 LAN — Прямые 10 500 10 500 кабельная система Software 50 000 5000 37 8000 000 Oracle Прямые 12 000 12 Database Server 000 ERP SAP R3 Прямые 25 000 25 000 Microsoft Прямые 3000 3000 Exchange Server Клиент Прямые 2000 2000 Microsoft Exchange (50 пользователей) Microsoft Прямые 2000 2000 Windows (50 пользователей) Microsoft Office (20 пользователей) Novell NetWare Персонал Прямые 3000 3000 Прямые 3000 3000 Прямые Прямые затраты Накаладные Соотнесенные расходы Внешние сервисы ИнтернетПрямые провайдер Сопровожден Прямые ие ERP-системы Производстве нные помещения Серверная Соотнесенные 300 000 75 843 213 600 54 000 86 400 21 843 25 000 15 000 15 000 15 000 10 000 20 000 148 315 105 600 42 715 10 000 75 843 54 000 21 843 10 000 5056 98 5056 49 2528 19 1011 29 1517 88 10 000 2528 44 Компьютерна Соотнесенные 4000 1011 я 78 Офис Соотнесенные Сумма прямых и косвенных соотнесенных затрат Добавочный процент Распределени Несоотнесенны е косвенных е несоотнесенных затрат Всего себестоимость ИТ-услуг 6000 470 000 100 30 000 1517 66 109 621 250 258 23,324 6997 110 121 23,430 53,24 6 15 974 500 000 116 618 266 232 7029 117 150 Преимущества для бизнеса, которые дает такой подход по сравнению с существующими методами:    для любого ИТ-директора составление ИТ-бюджета является сложной задачей. Если капитальные расходы (затраты на приобретение оборудования и ПО) еще можно запланировать, то как учесть изменение операционных расходов, связанных с увеличением числа пользователей, внедрением новых и расширением уже существующих сервисов? Необходимую базу ИТ-руководителю даст сервисноориентированный учет затрат, который использует статистику для расчета планируемых сумм увеличения затрат на основании данных предыдущих периодов; ИТ-менеджер может периодически предоставлять для управленческого учета компании данные о реальных затратах на каждую бизнес-услугу. Это позволит менеджменту компании видеть, куда уходят деньги, предоставляемые на ИТ, и принимать на основании этих данных обоснованные управленческие решения. В этом случае решается проблема «черной дыры», то есть исключается ситуация, когда в ИТ вкладываются серьезные средства, но никто не может сказать, насколько эффективно эти средства потрачены, соответствуют ли вложения в ИТ полученной отдаче для основного бизнеса компании; бизнес-услуга направлена в первую очередь на осуществление деятельности компании, поэтому себестоимость предоставления такой услуги легче отнести на объекты затрат в рамках управленческого учета всего предприятия. Например, что скажут экономисту данные о том, что затраты на содержание и обслуживание UNIX-сервера и установленной на нем базы данных ERP-системы за прошедший отчетный период составили 25 тыс. руб.? Как эти затраты отнести на себестоимость готовой продукции? Насколько релевантными будут драйверы распределения косвенных затрат, основанные на методике учета производственных затрат (например, пропорционально заработной плате работников основного производства)? А вот если финансовый менеджер ИТ предоставит экономистам компании данные в разрезе предоставления бизнесу услуги «Автоматизированная система управления ресурсами предприятия» с разделением затрат на поддержку и сопровождение по функциональным модулям ERP (управление производством, управление закупками, финансовый учет, управление продажами и т.п.), то такие данные могут быть использованы для калькуляции себестоимости в масштабах всего предприятия. При этом вклад затрат на ИТ в общую себестоимость продукции компании можно рассчитать более точно, поскольку затраты на ИТ-услуги можно сопоставить с бизнес-подразделениями, потребителями этих услуг и, следовательно, с объектами затрат, связанными с данными подразделениями;  на основании сервисно-ориентированного учета затрат на ИТ возможно построение модели совокупной стоимости владения — ССВ (Total Cost of Ownership, TCO), которая включает не только явные затраты на предоставление ИТ-сервиса (себестоимость), но и скрытые затраты, связанные с потерями от простоев, самоподдержкой пользователей и прочими затратами, которые в неявном виде входят в затраты компании. При реализации модели ССВ становится более прозрачной оценка инвестиций в ИТ (сумма притоков от внедрения инвестиционного проекта считается как разница от планируемого изменения ССВ по сравнению с текущей), а также решение извечной проблемы make or buy — прибрести или разработать программное обеспечение, осуществлять обслуживание ИТ-инфраструктуры собственными силами или отдать на аутсорсинг и т.п.