Управленческий учет для небольшой IT-команды

1. Вводная

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

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

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

2. Бизнес-цели, имеющиеся проблемы и ограничения

Основные цели:

1. Обеспечить полную прозрачность взаиморасчетов с клиентами


2. Обеспечить полную прозрачность взаиморасчетов внутри команды


3. Понимать в каждый конкретный момент времени кто, какие задачи и для кого выполняет


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


5. Сократить «непродуктивные» трудозатраты на подготовку отчетной документации для клиентов (счета, акты, таймшиты и т.п.)


6. Иметь возможность анализировать финансовые результаты выполняемых работ

Ограничения:

1. Временные – готовность к использованию за 1-2 недели


2. Финансовые – чем дешевле, тем лучше


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

3. Идеи от IT

Исходя из стоящих целей и имеющихся ограничений, рассматривались следующие альтернативные варианты:

1. Использовать какое-то готовое решение из области «общего» учета (например, на базе 1С)


2. Использовать какое-то готовое решение из области автоматизации процессов разработки (например, Redmine)


3. Сделать что-то свое

После рассмотрения «за» и «против» каждого из этих трех вариантов было принято решение остановиться на варианте «3».

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

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

Как в случае «1», так и в случае «2» смущала также необходимость оплаты стоимости лицензий и наличие «в нагрузку» дополнительного функционала, который в обозримом будущем не требовался или уже был внедрен на базе других систем (например, работа с планами-графиками проектов из функционала Redmine уже реализована при помощи MS Project, а работа с проектными документами и внутренний портал взаимодействия при помощи Alfresco ECM).

В варианте «3» подкупала возможность сделать ровно то, что нужно сейчас и постепенно это развивать по мере расширения и изменения требований.

Что касается платформы для создания учетной системы «с нуля», то сначала я планировал сделать все в рамках внутреннего портала взаимодействия на базе Alfresco ECM, однако потом решил использовать MS Access. Access позволял сделать все несколько быстрее и, что самое главное, вносить изменения в функционал по мере необходимости практически одновременно с его использованием. Это позволяет с низкими накладными издержками отработать информационную модель и пользовательской интерфейс в реальной жизни. Потом при необходимости можно перенести уже отработанные технологические решения на более производительную платформу. С другой стороны, с учетом небольшого размера команды и, соответственно, небольших объемов обрабатываемых данных Access вполне подходит для этих целей.

4. Концепция решения

Итак, наше IT-решение для управленческого учета в небольшой IT-команде представляет собой файл Microsoft Access 2013, включающий в себя базу данных, а также набор форм, запросов и отчетов для работы с ней.

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

Несколько упрощенная информационная модель предлагаемого мною варианта приведена на схеме ниже.

Центральным элементом данной модели является «Проект». Проекты различаются по типам с точки зрения направленности (внутренние, внешние и пресэйлы), а также с точки зрения способа взаиморасчетов по ним (фиксированная оплата за согласованный объем работ – fixed price, оплата потраченных часов – time&material, без оплаты – некоммерческие).

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

Модель позволяет производить начисления (биллинг) для Клиентов по Проектам двумя способами в зависимости от типа договора Проекта:

• На основании фактически потраченных часов (для T&M проектов) – экземпляров сущности Трудозатраты


• На основании выставленных счетов, отражающих этапы и условия расчетов из договора (для FP проектов) – экземпляров сущности Начисление

Для детализации групп работ в рамках Проекта служит сущность Задача. Задача соотносится с элементарной или суммарной работой в иерархической структуре работ (WBS) данного проекта. Таким образом обеспечивается стыковка с календарно-сетевым и ресурсным планированием, производимым в Microsoft Project. Также Задача хранит в себе различные плановые оценки трудозатрат (первоначальную, согласованную с Клиентом и т.п.) и консолидирует фактические трудозатраты из связанных с ней экземпляров сущностей Трудозатраты.

Далее в рамках определенной Задачи создаются Назначения конкретным Ресурсам. Ресурс – это человек, член нашей команды. В будущем планируется также реализовать поддержку не только трудовых, но и материальных ресурсов. Каждый Ресурс имеет определенную стоимость (почасовая ставка).

Назначение представляет собой договоренность с определенным Ресурсом выполнить определенный объем работ (согласованная с Ресурсом оценка трудозатрат) во исполнение определенной Задачи. Например, по Задаче «Создание прототипа» могут быть созданы три Назначения:

• Подготовка функциональной спецификации – для аналитика Иванова


• Разработка прототипа – для программиста Петрова


• Тестирование – для тестировщика Сидорова

В процессе выполнения Назначения исполнитель или руководитель проекта ежедневно фиксирует количество потраченных в этот день часов соответствующего Ресурса посредством создания экземпляра сущности Трудозатраты.

По факту выполнения Назначения руководитель проекта оценивает их качество и фиксирует в виде оценки выполнения. Эта оценка впоследствии используется при анализе эффективности Ресурсов.

Завершающими элементами бизнес-процессов и предложенной информационной модели являются платежи от Клиентов и для Ресурсов. Как и в реальной жизни, выделяются два вида платежей:

• Входящий платеж – любое поступление денежных средств в общий бюджет команды (расчетные счета, наличные), в частности, поступление по договору от Клиента


• Исходящий платеж – любой расход денежных средств из общего бюджета команды, в частности, оплата работ Ресурса

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

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

5. Задачи по реализации

Для реализации концепции, описанной выше, были выполнены следующие работы.

Наименование задачи	Трудозатраты, ч-ч
Создание информационной модели, проектирование структуры базы данных и форм UI	8
Создание таблиц в MS Access, наполнение справочников и ввод первоначальных данных	4
Создание макросов данных в MS Access (реализация бизнес-логики на уровне базы данных)	4
Создание форм в MS Access (реализация интерфейсной логики)	8
Создание запросов и отчетов в MS Access (реализация аналитики)	8
Тестирование, опытная эксплуатация и доработки	8

Итого: 40 человеко-часов.

В результате получилось следующее:

6. Оценка затрат

Затраты на создание решения в разрезе статей расходов приведены в таблице ниже.

Статья	Наименование затраты	Количество	Сумма
Оборудование	-	-	0 руб.
Лицензии	Дополнительных лицензий помимо имеющихся MS Office не требуется	-	0 руб.
Работы	Собственные трудозатраты по созданию решения по ставке 1.200 руб. за час	40 ч-ч	48.000 руб.

Итого: 48.000 рублей.

7. Оценка выгод

7.1. Прямой экономический эффект

Наименование	Алгоритм расчета экономического эффекта	Сумма
Сокращение трудозатрат на ведение управленческого учета	До внедрения решения ведение управленческого учета занимало у меня в среднем около 1 часа в день, т.е. около 20 часов в месяц. Данное решение позволило сократить трудозатраты на ведения управленческого учета в 2 раза, т.е. до 10 часов в месяц. Экономический эффект в натуральных показателях равен 10 человеко-часам в месяц. По ставке 1.200 руб. в час – это 12.000 руб. в месяц.	12.000 руб. в месяц.

Итого: 12.000 руб. в месяц.

7.2. Косвенные выгоды

1. Повышение прозрачности взаиморасчетов


2. Уменьшение количества ошибок в расчетах


3. Повышение качества принимаемых решений за счет появления дополнительных аналитических инструментов


4. Улучшение взаимоотношений с клиентами за счет четкой и централизованной фиксации договоренностей о плановых сроках и трудозатратах на выполнение задач


5. Улучшение взаимоотношений внутри команды за счет четкой и централизованной фиксации договоренностей о плановых сроках и трудозатратах на выполнение назначений

8. Анализ эффективности

Приведенные выше расчеты свидетельствуют о сроке окупаемости данного решения менее 4-х месяцев даже при рассмотрении только лишь прямого экономического эффекта.

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

Т.е. можно с уверенностью утверждать о высокой экономической эффективности данного решения.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.