Проблемы внедрения автоматизированных систем по МСФО

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

2. Специалисты, формирующие техническое задание – документ, на основании которого программисты пишут код программы. Помимо знания платформы (1С, Axapta и т.д.), для создания качественного продукта совершенно необходимо, чтобы специалисты, формирующие задачу для программистов, умели составлять отчетность по МСФО или, как минимум, были в курсе основных принципов и требований международных стандартов. В противном случае проект может увязнуть в постоянных переделках и согласованиях с методологами. Программисты будут утверждать, что все, прописанное в техническом задании, сделано, а методологи – что идеология программы не отвечает требованиям МСФО или же программа просто неудобна в работе. При этом обе стороны будут правы каждая по-своему. Разработанный в результате программный продукт обычно представляет собой компромиссный вариант между тем, что было нужно методологам, и тем, что посчитали возможным сделать программисты.

Задача данной группы специалистов, помимо всего прочего, – взять на себя функцию посредника между методологами и программистами. Сначала на этапе постановки задачи, они должны объяснить методологам, что можно сделать в программе, а что нет (например, если в 1С нельзя запрограммировать закрепление столбцов, то ставить такую задачу перед программистами бессмысленно). Далее, когда задача поставлена, данная группа специалистов должна пояснить программистам, как лучше реализовать в программе идеологию, заложенную в нее методологами. Увы, в настоящее время такие специалисты – большая редкость…

3. Программисты, пишущие код программы. Сложность поиска таких специалистов и стоимость их услуг зависят от платформы, на которой планируется автоматизировать подготовку отчетности. Тем не менее, найти таких специалистов, как правило, значительно проще, чем специалистов из предыдущей группы.

Выбор исполнителя для проекта.

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

Проведение работ с помощью внутренних ресурсов.

Первая и самая главная проблема при таком решении – найти необходимые внутренние ресурсы. Это чревато большими затратами на оплату труда персонала, поэтому следует оценить, оправданны ли они. Для такой оценки необходимо ответить себе на следующий вопрос: «Понадобятся ли такие специалисты и в таком количестве по окончании проекта?» Если ответ будет скорее положительный, чем отрицательный, то это будет мощным аргументом в пользу проведения работ по автоматизации собственными силами. Однако в большинстве случаев ответ отрицательный. Поэтому компании обычно предпочитают вариант с привлечением подрядчика. Кроме того, еще одна проблема реализации проекта собственными силами состоит в том, что при таком варианте документация (техническое задание, инструкции и т. д.) имеет тенденцию быть неполной, а иногда и вовсе отсутствовать. Это может быть связано как с нехваткой у программистов-разработчиков времени, так и с желанием «привязать» к себе работодателя за счет эксклюзивности получившейся программы. Грамотная документация необходима для поддержания функционирования программы, внесения в нее изменений и для передачи дел от одного человека, работающего с программой, другому.

Привлечение подрядчика

Если собственные ресурсы отсутствуют, а набирать соответствующий персонал нецелесообразно, то для выполнения работ по автоматизации подготовки отчетности по МСФО можно привлечь стороннюю организацию. Однако здесь тоже есть свои сложности.

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

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

Специфика решаемой задачи.

Составление отчетности по МСФО сопряжено с принятием решений, основанием для которых служит профессиональное суждение составителей. Запрограммировать его невозможно. Даже с учетом имеющейся в любой автоматизированной системе возможности вводить ручные корректировки и исправлять посчитанные системой цифры, возникнут определенные сложности, ограничения. Пример последних – невозможность изменения формулы, «зашитой» в код программы. Не всегда возможно досконально описать языком формул все виды расчетов со всеми возможными вариантами.

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

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

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

Внедрение системы параллельного учета.

Основной принцип системы параллельного учета – это введение в систему учета по РСБУ дополнительных признаков, на основании которых впоследствии составляется отчетность по МСФО.

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

Первая сложность – это снова подбор персонала. Для работы в такой системе можно нанять бухгалтеров, имеющих представление об МСФО, а можно научить уже имеющихся бухгалтеров проставлять те или иные признаки в системе. Первый вариант для составления отчетности идеален за исключением того, что платить им придется существенно больше, чем обычным бухгалтерам. При втором варианте значительно возрастает риск ошибок, поскольку работающий с программой параллельного учета ставит тот или иной признак или сумму не на основании своего понимания того, как это должно быть отражено в отчетности по МСФО, а просто потому, что это прописано в инструкции. При этом прописать в инструкции все возможные варианты учета каждой операции довольно трудно.

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

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

Внедрение автоматической системы трансформации отчетности по российским стандартам в отчетность по МСФО.

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

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

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

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