Особенности управления затратами в компаниях, работающих в сфере информационных технологий

1Самарский государственный экономический университет, Самара, Россия, naumovaoa@gmail.com0,

2Самарский государственный медицинский университет, Самара, Россия,

naumovaoa@gmail.com0,

2Samara State Medical University, Samara, Russia,

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

Целью ее является исследование особенностей калькулирования себестоимости программного продукта, а также разработка рекомендаций по управлению затратами ИТ-компании.

Вопросами формирования себестоимости цифрового продукта занимались такие авторы, как Р. Фатрелл, М.А. Зельковиц, Е.В. Бахтерева и т.д. (Бехтерева, 2019; Futrell et al., 2002; Zelkowitz et al., 1979).

Основные результаты . Затраты как предмет управления отличаются динамизмом, так как находятся в постоянном движении, изменяются. На них оказывает влияние обновление продукции, пересмотр норм сырья и материалов, затрат труда и прочих факторов, что непосредственно сказывается на итоговой стоимости продукта. По этой причине рассматривать затраты в статике – это условное занятие, которое не отражает текущий их уровень (Naumova, Tyugin, 2021; Erochin et al., 2021; Grishunin et al., 2020).

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

Затраты в ИТ-компаниях разнятся в зависимости от вида деятельности организации внутри отрасли. Условно можно разделить все существующие ИТ-компании на российском рынке на три категории:

• 1.    Компании-создатели – занимаются разработкой продукта для дальнейшего его выведения на рынок, часто разрабатывают мобильные приложения, игры, антивирусы и ориентированы на рынок и потребителя; у них редко бывают заказчики.

• 2.    Аутсорсинговые компании – создают продукты, исходя из технического задания, поставленного перед ними, то есть каждый заказ – это новый продукт для b2b-клиента.

• 3.    Консалтинговые компании – занимаются консультированием заказчиков по работе с уже существующим продуктом, устанавливают уже имеющееся программное обеспечение.

Исходя из сфер деятельности, можно выделить и различия в ведении управленческого учёта затрат в каждой группе ИТ-компаний:

• 1.    В практике компаний-создателей в стоимость продукта включаются все совокупные затраты на новый продукт: трудовые, материальные и иные ресурсы.

• 2.    Если речь идет об аутсорсинговых компаниях, то как правило, используется позаказный метод учета затрат. Это связано прежде всего с уникальностью требований каждого клиента и характеристик будущего заказа. Доходы, расходы и финансовые результаты определяются также в рамках договора с клиентом.

• 3.    Как и для аутсорсинговых, для консалтинговых компаний наиболее оптимальным является позаказный метод. Это также связано с уникальностью клиентов. Например, различное географическое положение их определяет рост командировочных расходов исполнителей. Показатели эффективности также собираются по каждому отдельному заказу.

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

Формирование себестоимости проводится в зависимости от контракта – до или после его заключения.

Существенной особенностью разработки программных продуктов является то, что основной долей затрат становится оплата работы специалистов ¹ , поэтому важно особое внимание уделить оценке трудоёмкости создания программного проекта (Кавардина, Аксинина, 2021). Методы ее осуществления представлены на рис. 1.

Представленный на рис. 1 метод аналогий применяется только в том случае, если подобные проекты уже были реализованы компанией. Это редко подходит для консалтинговых и аутсорсинговых компаний.

	Метод экспертных оценок
х

	Метод аналогий	X
X

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

Методы алгоритмического моделирования основаны на анализе статистических данных о проектах, выполненных ранее

	Математическая модель жизненного цикла программного обеспечения (SLIM)	X
X________

/	Нейронные сети применяются для поиска закономерностей, прогнозирования
	и анализа трудозатрат на программный продукт

с	Имитационное моделирование применяется, когда система показателей преобразовывается
X___	в модель, описывающую реальную систему

Байесовские сети используются для описания закономерностей данных в виде сетевой модели

/	Динамические методы строятся на основе предположения о том, какие факторы могут повлиять
X__	на стоимость и продолжительность выполнения проекта

/	Метод функциональных точек направлен на измерение размера программного продукта с точки	X
X___	зрения пользователей системы

Конструктивная модель стоимости (СОСОМО) – метод устанавливает зависимость между размером программного кода и трудоёмкостью создания программного продукта

Оценка для достижения целей победы на аукционах, торгах проводится для того, чтобы «подбить» стоимость продукта под бюджет заказчика и выиграть контракт

Рисунок 1 – Методы оценки трудоемкости программного продукта ¹

Figure 1 – Methods for Assessing the Labor Intensity of a Software Product

Методы алгоритмического моделирования используются для создания прогнозной модели трудозатрат на основании изменений количественного показателя.

Модель жизненного цикла (SLIM) используется в том случае, если есть возможность измерить время или трудозатраты проекта в качестве эмпирических данных.

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

Логично, что большую часть себестоимости ИТ-продукта составляет оплата труда проектной команды, поэтому установление ее планируемого объёма (фонда оплаты труда – ФОТ) – важный фактор, который должна учитывать компания-разработчик на начальных этапах работы с потенциальным заказчиком. Экономический субъект, соглашаясь на условия договора создания программного обеспечения (ПО), должен быть уверен, что данный проект принесёт ему выгоду.

К сожалению, единого метода для оценки трудоёмкости разработки нет, поэтому компании часто используют несколько способов в совокупности. Это позволяет получить наиболее точные данные о трудоёмкости проекта и определиться с его себестоимостью.

Расчёт объёма оплаты труда программного продукта основан на зарубежных исследованиях (Futrell et al., 2002; Nokes, 2000) последовательности реализации отдельных этапов жизненного цикла ПО (ЖЦПО) с учётом:

• •    длительности и трудоёмкости каждого этапа;

• •    абсолютного и относительного составов занятых сотрудников;

• •    средней месячной ставки ИТ-специалиста.

В табл. 1 приведены средние статистические показатели распределения трудозатрат и длительности работы каждого из циклов ЖЦПО на российском рынке ИТ ¹ (Zelkowitz et al., 2000).

деляется соотношением:

T×αi

Ni = D×βi

(1),

Таблица 1 – Распределение трудозатрат и длительности работы основных этапов разработки ПО

Table 1 – Distribution of Labor Costs and Duration of the Main Stages of Software Development

№	Этапы ЖЦПО	Трудозатраты a (%)	Длительность b (%)
1.	Анализ требований, предъявляемых к системе	10	10
2.	Определение спецификаций	10	10
3.	Проектирование	15	15
4.	Кодирование	20	20
5.	Тестирование (автономное и комплексное)	45	45

Средняя численность специалистов (Ni), занятых на каждом из циклов создания ПО, опре- где   i = 1,5;

• D – заданный срок разработки;

T – длительность разработки системы.

Относительное распределение штата сотрудников на каждом этапов ЖЦПО приведено в табл. 2.

Таблица 2 – Распределение специалистов по этапам ЖЦПО ²

Table 2 – Distribution of Specialists by Stages of Softwar e Lifecycle

№	Этапы ЖЦПО	Типы специалистов проектной команды ПО (pij)
		аналитик	программист	технический специалист
1.	Анализ требований, предъявляемых к системе	40	20	40
2.	Определение спецификаций	60	20	20
3.	Проектирование	35	35	30
4.	Кодирование	10	65	25
5.	Тестирование (автономное и комплексное)	15	60	25

Чтобы определить численность каждого типа специалистов на каждом из этапов ЖЦПО, используется формула:

nij =pij ×Ni                                                      (2), где   i = 1,5;

j = 1,3 ;

pij – доля (%) специалистов j-го типа, привлекаемых для реализации ПО на i-ом цикле.

Для реализации каждого i-го этапа ЖЦПО определяется фонд заработной платы:

Si = di ∑j3=1 nij ×∙ vj                                              (3), где   i = 1,5;

di – длительность i-го этапа ЖЦПО;

vj – месячный ФОТ j-го типа специалиста.

В основу определения месячного фонда оплаты труда может быть положена месячная базовая ставка специалиста, её размер определяется на основе:

• –    стандартной ставки специалиста-заказчика;

• –    стандартной ставки специалиста-разработчика;

• –    средней рыночной ставки специалиста по региону компании-разработчика.

Соотношение размеров месячных ставок программиста и бизнес-аналитика составляет 1:1,3; программиста и технического сотрудника – 1:0,7.

Трудозатраты временного периода реализации проекта (T) могут быть определены следующим образом:

T= _P ^R                                             (4),

• где  R – экспертная оценка значения трудозатрат проекта;

P – средняя производительность разработки специалиста.

Проведем пример расчета фонда заработной платы для реализации каждого из этапов ЖЦПО условного проекта АВС для Самарского региона.

Приведем данные о размере средней ставки заработной платы (ЗП) по Самарской области среди специалистов разработки ПО (табл. 3).

Таблица 3 – Данные для расчёта оплаты труда проекта АВС

Table 3 – Data for Calculation of ABC Project Remuneration

Тип специалиста разработки ПО	Средняя ЗП по региону (руб.)
Аналитик	65 000
Программист	95 000
Технический специалист	40 000

На основании приведенной информации о средней заработной плате каждого типа специалистов проектной команды можно провести расчёт фонда оплаты труда по формуле (3).

Распределение полученной величины по этапам жизненного цикла программной системы представлено в табл. 4.

Таблица 4 – Распределение фонда заработной платы специалистов по этапам ЖЦПО АВС (руб.)

Table 4 – Professional Payroll Allocation by phases of the ABC Software Lifecycle (RUB)

№	Этапы ЖЦПО	Типы специалистов проектной команды АВС (pij)
		аналитик	программист	технический специалист
1.	Анализ требований, предъявляемых к системе	2 340 000	1 710 000	1 440 000
2.	Определение спецификаций	3 510 000	1 710 000	720 000
3.	Проектирование	3 159 000	4 617 000	1 512 000
4.	Кодирование	1 404 000	10 944 000	1 728 000
5.	Тестирование (автономное и комплексное)	4 212 000	23 085 000	3 888 000
Итог ФЗП				6 579 000

На основании расчётов можно сделать вывод, что для реализации проекта АВС, разработка которого занимает 3 года, необходимо сформировать фонд заработной платы в объёме 6 597 900 руб.

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

Осуществлять корректировку всех статей плановых накладных затрат каждый месяц – достаточно трудоёмкая работа для организаций, поэтому мы предлагаем решение данного вопроса осуществлять с помощью инструмента «Матрица-статистика отклонений накладных расходов» (рис. 2).

Матрица-статистика отклонений накладных расходов, или матрица принятия управленческих решений – систематизация метода с созданием нормативного показателя (планового) для сравнения с фактическими данными и выявления отклонений в определённом временном отрезке (рекомендуемое время отслеживания: – 3–6 месяцев). Данный инструмент позволит своевременно и корректно контролировать уровень отклонений в той или иной затратной статье.

Матрица состоит из нескольких элементов, среди них:

• •    первый столбец - примерный перечень оцениваемых постоянных затрат;

• •    последующие столбцы - временная лента (период построения - с 01.01.2021 по 31.05.2021);

• •    показатели - процент отклонений от нормы фактических понесённых расходов;

• •    красная линия - риск-аппетит, который добавлен в матрицу для приоритетности пересчёта расходов. Так, значения, которые находятся выше линии, наиболее нуждаются в пересмотре и принятии управленческих решений, те, что отображаются ниже, - имеют меньший процент отклонения, с которым погрешность уровня затрат не является критичной. Рекомендуемая граница определения риска-аппетита - 25 %.

Рисунок 2 – Матрица-статистика отклонений накладных расходов

Figure 2 – Matrix Statistics on Overhead Deviations

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

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