Условия проекта и разработки
К нам обратился холдинг, компании в составе которого занимаются производством оборудования и строительством объектов инфраструктуры. Весь учёт вёлся относительно проектов, длительность которых могла составлять несколько десятков лет. Ответственными за экономическую отчётность и их содержимое были финансовые директоры. При этом отдел экономического планирования был скорее исключением и присутствовал в отдельных организациях.
Заказчик использовал конфигурацию «1С:Управление холдингом» версии 3.2.9.-3.2.10. В системе не использовались типовые настройки договоров, из-за чего невозможно было использовать их для соответствия между разными справочниками. Вся договорная работа велась вне системы, и в 1С:УХ попадали только конечные и минимальные данные.
АРМ должен был стать основным инструментом для руководителей проектов, которые образовывали отдельную группу пользователей, слабо подготовленных к работе в 1С в целом. Некоторые руководители проектов (далее — РП) отвечали за несколько проектов одновременно, как за техническую, так и за экономическую часть.
В части экономики процессов основной зоной ответственности РП являлись блоки выручки и прямых расходов в разрезе строго установленных разделов и статей доходов/расходов. При этом текущий и два будущих года должны заполняться помесячно, а последующие периоды заносились в разрезе года. АРМ должен был иметь возможность отображать данные в разрезе нескольких лет и произвольных периодов в рамках существования проекта.
В результате заказчик согласовал вариант использования в АРМ сводных таблиц к видам отчётов при одновременном создании экземпляров отчётов в разрезе отдельных годов.
Организационные риски при реализации проекта
Всё, что я описываю далее, не является типичным или однозначным примером происходящего, но совсем исключать их нельзя. Такие риски стоит отслеживать и ликвидировать до перехода их в терминальную стадию.
Мы подключились к команде заказчика для решения задач по автоматизации бюджетирования, но столкнулись с несколькими препятствиями организационного характера.
В процессе погружения мы выяснили, что прежде чем приступить к разработке бюджетной модели в целом и АРМ в частности, необходимо провести первичную унификацию бизнес-процессов управленческого учёта.
Бизнес-представители заказчика привыкли видеть конечную Excel-форму отчётности, не погружаясь во внутреннюю методологию расчётов конечных данных. Из-за того, что для заказчика была неочевидна разница между разработкой типового и нетипового дополнительного функционала, у него возникали дополнительные вопросы. Такие сложности чреваты увеличением сроков разработки со сложным обоснованием причин.
Кроме того, мы обнаружили конфликт потребностей бизнеса и экономической логики. Клиент хотел видеть автоматически обновляемые и пересчитываемые данные при любом изменении показателей. В Excel-формах распределение накладных расходов производилось после заполнения основных данных по всем проектам. В 1С же данные по каждому проекту заполнялись отдельно, что не позволяло корректно рассчитывать накладные расходы на каждый отдельный проект в моменте сейчас. Это очевидно для 1С-экспертов, но далеко не всегда понятно пользователям, вне зависимости от уровня их должности.
Сложности использования типовых механизмов при разработке АРМ.
- Критически медленная работа системы при формировании отчетов за долгий период.
При создании, открытии и записи отчётов, которые учитывают данные за 20+ лет, документ мог формироваться до 40 минут вместо нескольких секунд.
Чтобы это исправить, в механизмах АРМ мы реализовали алгоритм автоматического формирования нескольких экземпляров отчётов с годичными периодами. При этом типовой функционал сводных таблиц вполне позволял отображать данные за несколько лет в одном месте.
- Заказчику было важно реализовать формы и внешнее представление АРМ так, чтобы РП сразу видел экономический и финансовый результаты по своему проекту.
Результат рассчитывался на основании внесённых им выручки и прямых расходов, с дополнением прочих расходов на основании отдельно проработанных правил расчёта. То есть, для сценариев «План» и «Прогноз» разрабатывались разные правила расчёта косвенных расходов на разных первичных данных.
Казалось бы, любой экономист анализировал бы проекты по норме валовой прибыли, а саму валовую прибыль рассматривал бы по составляющим, но заказчик требовал ведения результата проекта до чистой прибыли сразу в АРМ.
Эта задача решалась в двух направлениях: формирование финансового результата и расчёт косвенных расходов с выведением прибылей всех видов.
РП вносил свои данные в виде бюджета доходов и расходов (БДР). Трансформация в бюджет движения денежных средств (БДДС) производилась автоматически на основании доработки справочника «Статьи доходов и расходов» и установления соответствия статьям справочника «Статьи движения денежных средств». Правила расчёта вида отчёта позволили автоматизировано формировать отчёт БДДС на основании данных БДР.
Для расчёта косвенных расходов мы проработали механизмы и источники данных, которым потребовалось разработать правила расчёта и распределения. Если со сценарием «План» всё очевидно и упирается в заполненность бюджетов расходов по вспомогательным подразделениям, то для сценария «Прогноз» возникала циклическая математическая дилемма.
Типичным решением по расчёту накладных расходов для прогнозных проектов является установление определённого коэффициента, рассчитанного на соотношении косвенных расходов организации к ФОТ прямого производственного персонала. Однако в данном случае ФОТ прямого производственного персонала формировался для каждого проекта отдельно. И таких проектов было несколько десятков у каждой компании в структуре холдинга. Таким образом, внесение данных по новому проекту неизбежно требовал пересчёт коэффициентов накладных расходов и пересчёта прибылей по всем ранее внесённым проектам.
Эту математическую дилемму удалось решить с помощью отдельного вида отчёта с коэффициентами накладных расходов по Организации, который дополнительно пересчитывал и перезаписывал данные при изменении бюджетов проектов в сценарии «Прогноз». Для прошлых проектов в самом АРМ ввели специальный индикатор, сигнализирующий о необходимости пересчитать накладные расходы.
- Требование бизнеса по расчёту ФОТ прямого производственного персонала относительно штатного расписания и штатной расстановки.
При формировании прогноза проекта РП должен был указать перечень и количество должностей сотрудников, которые ему необходимы на данном проекте.
Это потребовало настроить интеграцию ЗУП и УХ по части данных об окладах и штатном расписании по отдельным организациям. Однако по политике заказчика РП не имел доступа к данным об окладах и не мог сориентироваться по наименованиям должностей без дополнительного фильтра по подразделениям/ЦФО.
В результате, чтобы реализовать механизм автоматизированного расчёта расходов на ФОТ, мы сделали следующее:
— Привели в соответствие справочники «Организационные единицы» УХ «Структура предприятия» в ЗУП.
— Провели анализ и ревизию позиций штатного расписания в ЗУП на предмет дублей и повторных записей.
— Провели технический анализ на возможность установления интеграции и безошибочного обмена данными между серверами, где хранятся базы ЗУП и УХ.
— Доработали карточки сотрудников для внесения дополнительных параметров, необходимых в моделях расчёта ФОТ в УХ.
— Разработали механизмы интеграции для получения разрезов данных, необходимых для расчёта.
— Разработали и зафиксировали бланки отчётов, которые ограничивают доступ РП окладам (в том числе и при расшифровке расчётов)
— Установили жесткий контроль за отсутствием доступов к отдельным видам и бланкам отчётов для отдельных групп пользователей.
Решив эти проблемы, мы решили и задачу автоматизированного расчёта ФОТ при формировании потребности в конкретных специалистах.
- Последовательное применение правил расчёта.
Типовой функционал УХ позволяет и нормально работает с последовательным применением правил расчёта. Но в случае разработки нетипового функционала постоянно возникали неожиданные и неочевидные проблемы.
К примеру, в соответствии с согласованной бизнес-моделью потребовалось предварительно затянуть в экземпляры отчёта исторические данные, а после запустить механизмы расчёта по другому правилу. С учётом продолжительной длительности проектов заказчика, требовалось заполнить исторические данные на определённую дату, а все последующие периоды оставить доступными для ручного внесения.
Это требование вылилось в целый комплекс технических задач:
— Правило подъёма исторических данных требовал настройки операнды в ячейках, которые должны были заполняться вручную в правиле расчёта «Прогноз». Последовательное применение этих правил либо затирало предыдущие данные, либо приводило к некорректному поведению системы.
— Регистр «Значения показателей отчетов» в некоторых ситуациях некорректно записывал данные. Одной из причин этой проблемы стал неочевидная необходимость записи параметра «Правило расчёта» в этом регистре, которое должно соответствовать правилу конечному правилу расчёта. То есть, в данном случае - правилу «Прогноз».
— В случае включённого булево «Сохранять историю изменений» в настройках вида отчёта, система периодически некорректно записывала данные в регистры «Значения показателей отчетов». Такие ошибки выводили данные в экземпляры с ошибками.
— Использование сводных таблиц для внесения и расчёта данных в сложных моделях отчётов часто приводило к ошибкам работы внутренних алгоритмов. То, что работало на обычных бланках, могло выдавать ошибку на сводных таблицах.
Таким образом, при разработке дополнительного функционала АРМ при использовании типовых механизмов бюджетирования в 1С:УХ нам пришлось исправлять и корректировать «типовые негибкости» системы и алгоритмов.
Рекомендации при разработке АРМ бюджетирования
Резюмируя всё вышеописанное, я сформулировал такие рекомендации при разработке дополнительного функционала типа АРМ:
1. Прежде чем приступать к разработке, настаивайте на обновлении системы до максимально возможной версии. Как показала практика, далеко не все реально внесённые исправления описаны в документации к релизу. Например, версия 3.3. кардинально отличается от версии 3.2.10.
2. Разделяйте сложные расчёты на несколько видов отчётов. Бюджетирование 1С:УХ проблематично воспринимает последовательный запуск одного и того же правила расчёта. То, что работало в бюджетировании 1С:ERP, в 1С:УХ не работает. По крайней мере в текущих релизах.
3. При работе с историческими данными настаивайте на выведение их в отдельный сценарий. Данные из отдельного сценария кратно проще обработать, чем затянуть их из регистра с сохранением возможности дальнейшего редактирования в дальнейших периодах.
4. При разработке дополнительного нетипового функционала лучше потратить время на разработку и утверждение модели с клиентом до старта разработки.
5. Более эффективным вариантом разработки АРМ было бы формирование отдельного регистра накопления со всеми необходимыми аналитиками. Бюджетные отчёты 1С:УХ весьма эффективно работают с данными регистров, значительно проще получать данные из них, чем иметь дело со сложными расчётами внутри отчётов.
6. В случае проектного бизнеса заказчика стоит рассмотреть внедрение дополнительного блока, например «Управление проектами». Это потребовало бы дополнительного обучения пользователей, но существенно повысило бы эффективность работы всей организации.
7. Любой инструмент должен разрабатываться так, чтобы упростить и систематизировать работу исполнителей на местах. Формирование конечной отчётности всегда зависит от корректного формирования массива данных.
Вместо итогов
Успешно вовлечь производственный персонал в механизмы 1С возможно, если этот инструмент упростит им жизнь, станет помощником по хранению данных, информации и процессов, а не дополнительной рутинной обязанностью. Задача команды разработки при этом — качественно настроить сложные экономические модели расчёта и формирования бюджетов, опираясь на потребности бизнеса. Да, кастомизированная настройка систем бюджетирования 1С:УХ более сложна и трудоёмка в реализации, но всегда возможна:)
