В проектной практике последних лет прослеживается тренд на сближение налогового, бухгалтерского, управленческого и МСФО учетов. Начнем с базы: как так сложилось, что учеты отличаются? Есть несколько групп пользователей, и у каждой свои требования к отчетности. Для ФНС и регуляторов, бухгалтерии, менеджмента, а также акционеров, собственников и банков системе приходится вести четыре версии учета одной и той же хозяйственной операции.
Сближение необходимо в первую очередь, чтобы минимизировать корректировки, сверки разных видов отчетности и расшифровки расхождений, которые вынуждено проводить финансовое подразделение компании. Они отнимают время на расчеты и проверку, раздувают штат и снижают качество работы. Триггером для старта проекта сближения может послужить несколько факторов: от проектов Fast Close и смены ключевых пользователей до изменений внешних условий и выхода на IPO.
Для ускорения подготовки отчетности, сокращения расходов и рутинных операций финансистов необходимо провести глубокие методологические работы. Затем готовую методологию важно качественно приземлить на учетную систему: максимально использовать коробочные инструменты и исключить дублирование работы пользователей. Мы выделяем три основных роли в проекте автоматизации:
Функциональные заказчики — это пользователи отчетности: менеджмент, руководители подразделений, финансовый департамент, внешние пользователи. Их задача — сформулировать функциональные требования к отчетности, учету и контролю, то есть определить, какие показатели и с какой детализацией они хотят видеть в системе.
Методологи разрабатывают варианты отражения требований в учете и порядок организации бизнес-процессов. Они сравнивают запросы пользователей с лучшими практиками и согласуют противоречивые требования между подразделениями заказчика. В результате деятельности методологов мы получаем учетные политики, положения, методики, согласованные и формализованные функциональные требования.
Интегратор реализует функциональные требования в ИТ-системах с учетом их возможностей и ограничений. В его обязанности входит составление технического задания, проектирование интеграций и разработка. Специалисты интегратора подготавливают все для ввода новой платформы в действие и проводят запуск.
Ключевое значение в успехе ИТ-проекта имеет организация качественного взаимодействия всех сторон. Разберем, кем роли могут быть закрыты, варианты конфигураций и их особенности.
- Методологи и интеграторы являются частью ИТ-команды компании-заказчика. Это редкая ситуация, так как проект — временное предприятие, требующее большого количества ресурсов. Оперативно выделить на долгий срок специалистов из штата, причем профессионально занимающихся внедрением, трудная задача.
Нередко в корпорациях существует специальное проектное подразделение, а крупнейшие группы компаний создают дочернее предприятие в качестве отдельного бизнес-направления для решения ИТ-задач. Успешные кейсы на рынке есть, но даже так чаще всего привлекаются подрядчики.
- Подрядчик одновременно закрывает методологические и внедренческие задачи. Это один из наиболее удобных вариантов для заказчика, так как такая конфигурация позволяет получить сервис из одних рук. Кроме того, снижается вероятность многих рисков: несостыковка методологии и системы, банальные недопонимания и разногласия между командами.
- Два одноранговых подрядчика: один отвечает за методологию, другой — за запуск системы. Довольно сложная конфигурация, которая требует наличия особых компетенций у функционального заказчика. Он должен взять на себя организацию совместной работы: необходимо синхронизировать методологов и интеграторов, контролировать качество, бюджет и сроки. Этот вариант взаимодействия подходит компаниям с сильными командами по ИТ и финансам.
- Методолог выступает в качестве генерального подрядчика и организует работу с одним или несколькими интеграторами. В этом случае все риски ложатся на методолога. Именно он сдает систему «под ключ» и полностью отвечает за итоговый результат.
- Генеральным подрядчиком является интегратор. Главный риск заключается в том, что разработка методологии может растянуться по срокам. Тогда генеральному подрядчику приходится пересматривать договоренности и в некоторых случаях даже менять методолога.
- Автоматизация финансового учета в крупном алкогольном производстве превратилась в огромное количество доработок и затягивание сроков, а также потребовала от заказчика увеличения бюджета. Все потому что методология была разработана в отрыве от системы и не учитывала ее особенностей и ограничений.
- Команда методологов приняла решение считать себестоимость продукции внутри финансовой системы для сети кафе. Однако «1С:Управление холдингом» не предназначена для таких расчетов в отличие от «1С:ERP». Система не взлетела по производительности, и проект был закрыт.
- В кейсе крупного производства с несколькими фабриками заказчик включил 300 человек в рабочую группу по формированию требований. Отсутствовали четкие сроки задач методологии, а подразделения не были готовы договариваться между собой. В итоге процессы согласования занимали месяцы. Несмотря на то, что качество не пострадало, методологическая разработка длилась в 2 раза дольше плана.
Мы рекомендуем подойти к задаче разработки методологии в финансовом проекте с максимальной отдачей со стороны заказчика и партнера на каждом этапе. Доработки неизбежны, но некоторые фишки, а также вовлеченность, внимательность и настойчивость участников позволят значительно сократить их количество.
