Впервые статья была опубликована в периодическом издании «Accounting Report», издаваемом Международным центром реформы системы бухгалтерского учёта МЦРСБУ за сентябрь/октябрь 1999 года.
Введение
Современные быстро меняющиеся условия оказывают постоянное давление на все предприятия, начиная с семейного производства и кончая крупными международными корпорациями. Сокращение затрат и повышение качества обслуживания клиентов невозможны без точной, полной и своевременной управленческой информации. Управленческие информационные системы призваны помочь в достижении данных целей. Однако процесс внедрения таких систем сопряжен со многими проблемами, в том числе с технологическими, психологическими и законодательными аспектами, а также с необходимостью управления изменениями и т.д. Одним из основных факторов успеха является четкое понимание как проблем, так и экономических выгод от реализации системы.
Кроме того, к проектам по внедрению управленческих информационных систем в России предъявляется ряд особых требований, таких как возможность ведения бухгалтерского учета по двум стандартам (российским и международным) и в двух валютах. Наш опыт показывает, что есть целый ряд причин, в силу которых у российских компаний возникает потребность использовать и российские принципы учета, и Международные стандарты финансовой отчетности (МСФО):
- российские принципы учета главным образом нацелены на подготовку отчетности для налоговых и прочих государственных органов, они не позволяют получать адекватные отчеты, отвечающие требованиям управленческого учета. Таким образом, организация может использовать МСФО в целях повышения качества управленческой отчетности;
- необходимость представления отчетности в штаб-квартиру транснациональной корпорации;
- стремление привлечь инвестиции. Качественным образом настроенная управленческая информационная система не только решит проблему автоматизации и избавит от необходимости многократного ввода одних и тех же данных, тем самым ускорив процесс хозяйственной деятельности, но и обеспечит прозрачность всей технологической цепочки и контроль за ее функционированием. Это облегчит процесс принятия решений и, в конечном итоге, поможет в привлечении инвесторов.
Технические решения для ведения учета по двум стандартам
Потенциальным пользователям следует осознавать, что ни один программный комплекс не может сам по себе обеспечить автоматический ввод проводок согласно МСФО, GAAP или какому-либо иному стандарту отчетности. Они только помогают в данном процессе. Обычно система поддерживает наборы взаимосвязанных таблиц и параметров, которые необходимо заполнить и настроить в соответствии с конкретными требованиями предприятия. В ряде систем могут существовать типовые планы счетов с базовой конфигурацией. Тем не менее, окончательная адаптация к конкретному предприятию в любом случае входит в обязанности группы, осуществляющей внедрение системы.
Прежде чем перейти к подробному рассмотрению конкретных вопросов, связанных с внедрением учета по двум стандартам, следует привести краткий обзор возможных технических решений. На практике выбор одного из них зависит от целого ряда факторов, в том числе от требуемого уровня детализации, предусмотренного бюджета, технических возможностей системы, срока осуществления проекта и наличия достаточного числа сотрудников с соответствующими навыками.
Краткий обзор возможных решений
Имеются следующие варианты:
- В относительно простых системах может использоваться единая база данных для учета по российским и международным стандартам. В этом случае в системе фактически функционирует только российский план счетов. Счета МСФО отражаются как коды аналитического учета или реализуются в виде субсчетов. Каждая операция, вводимая в систему, отражается на российских счетах, но при этом учет ведется в нескольких валютах. В идеальном случае должна быть предусмотрена возможность отражения операций в рублях, во второй валюте отчетности (чаще всего в долларах США) и в фактической валюте сделки. Впоследствии отчетность по МСФО можно получить из системы с помощью функций генератора отчетов.
- В системах средней сложности, например, в SunSystems, первоначально осуществляется ввод операций в единую базу данных, при этом применяется только российский план счетов. В конце отчетного периода производится трансформация, т.е. автоматический пересчет сумм операций по соответствующим обменным курсам валют с последующим переносом в базу данных по МСФО. Операции, характерные исключительно для российского учета и не отражаемые в учете по МСФО, не переносятся. Что касается операций, характерных исключительно для учета по МСФО, то они впоследствии вводятся в базу данных по МСФО в виде корректирующих проводок.
- Многие системы обеспечивают поддержку двух и более баз данных, которые могут использоваться для параллельного ведения учета в соответствии с несколькими стандартами в различных валютах. Размеры и функциональные возможности систем, функционирующих по данной схеме, варьируются весьма существенно: от «1С» до системы SAP R/3. В каждом случае конкретное техническое решение и выполняемые функции могут различаться, но основной базовый принцип – ввод данных одновременно в оба журнала – остается характерной особенностью данного подхода. В этом случае для целей учета по двум стандартам в двух параллельных базах данных следует вести, по крайней мере, два плана счетов – российский и международный. Обычно российский план счетов выступает в качестве основного, при этом каждому его счету ставится в соответствие счет из международного плана счетов. При вводе операции в один журнал осуществляется ее одновременный перенос во второй.
Преимущества и недостатки
Каждый из рассмотренных выше вариантов имеет свои преимущества и недостатки.
Несмотря на то, что первое решение представляется наиболее дешевым, оно может оказаться неадекватным и достаточно трудно реализуемым на практике. При относительно простой структуре и настройках для реализации данного решения требуются достаточно сложные отчеты, генерация которых может оказаться затруднительной, не говоря уже об их поддержке в будущем. Кроме того, необходимо уделить особое внимание корректировкам в соответствии с МСФО.
Более жизнеспособной является вторая альтернатива с использованием трансформации в конце отчетного периода. Один из основных недостатков заключается в том, что информацию, подготовленную по МСФО, можно получить только в конце периода, причем после завершения основного процесса трансформации приходится еще вносить корректировки. С другой стороны, процесс трансформации (после соответствующей настройки) может осуществляться автоматически либо полностью, либо частично. Ответственность за проведение трансформации и внесение соответствующих корректировок при этом может быть возложена на одного человека, хорошо знакомого с правилами ведения учета по МСФО. Преимуществом этого подхода является то, что рядовым сотрудникам бухгалтерии, осуществляющим ежедневный учет операций, не нужно обладать навыками работы по МСФО.
Ситуация меняется кардинальным образом при выборе третьей альтернативы. Данное решение позволяет обеспечить в любой момент времени наибольшую детализацию информации для учета по МСФО. Однако использование этого подхода приводит к более сложной структуре планов счетов и предварительно настроенных типовых операций. В отдельных случаях сотрудникам бухгалтерии, отвечающим за ввод операций, потребуется хорошее знание различий между российским учетом и МСФО. Кроме того, данный подход не решает проблему необходимости дублирования записи операций по МСФО, которые нельзя напрямую трансформировать из операций по российским стандартам, например, при учете основных средств.
Окончательный выбор альтернативы зависит от различных факторов, в том числе от стоимости программного обеспечения и его реализации, специфики предприятия и т.д. Однако перед тем, как выбирать конкретный подход, следует взвесить все преимущества и недостатки альтернативных вариантов.
Проблемы внедрения систем, связанные с различиями между российскими стандартами и МСФО
В результате реформирования российских стандартов в соответствии с МСФО должно исчезнуть большинство проблем, возникающих при реализации учета по двум стандартам. Однако в настоящее время проблема все еще стоит на повестке дня. Ниже перечислены основные различия между российскими стандартами и МСФО, которые важно учитывать при внедрении систем и особенно при использовании третьего подхода.
- В первую очередь, трудности возникают в связи с различным уровнем детализации российского и международного планов счетов. Часто несколько российских счетов соответствуют одному счету, предусмотренному по МСФО, и наоборот. Не все системы способны поддерживать связи, не обеспечивающие взаимно однозначное соответствие. В этом случае приходится разбивать счета на несколько субсчетов даже при осуществлении одних и тех же достаточно простых операций.
Другая проблема связана с различными временными рамками и методикой учета в конце периода. Дело в том, что по российским стандартам и МСФО возможно использование не только различных отчетных периодов, но и разной методики закрытия счетов в конце периода. В этом случае приходится осуществлять процедуры закрытия счетов отдельно в двух базах данных. - Учет основных средств также представляет проблему. В учете по российским стандартам и МСФО могут использоваться различные методы и нормы амортизации. В результате складывается ситуация, когда в одном журнале продолжает производиться амортизация актива после его выбытия в другом журнале, поэтому непосредственная трансформация соответствующих счетов не представляется возможной. Таким образом, следует вести отдельный учет основных средств в каждой базе данных. Для этого используются либо забалансовые счета, либо отдельные проводки в обоих журналах.
- То же самое относится к учету МБП (малоценных и быстро изнашивающихся предметов): согласно МСФО они могут полностью относиться на расходы в момент приобретения, а по российским стандартам – амортизироваться при передаче в эксплуатацию.
- Осуществление дублирования ввода операций одного и того же вида в две базы данных само по себе не представляет техническую проблему. Однако наш опыт показывает, что люди, как правило, отрицательно относятся к «двойной» работе. Кроме того, они часто забывают об этом или делают ошибки, если, по их мнению, задача не имеет большого значения для их повседневной работы: проводки по МСФО не нужны для представления отчетности в российские налоговые органы.
- Еще одна проблема связана с признанием задолженности по российским стандартам и МСФО. Например, при выставлении счета на предоплату при учете по МСФО на счетах появляется соответствующая проводка. Однако проформа-инвойс по российским стандартам не является обязательным документом, поэтому при его выставлении никакие проводки на российские счета не вводятся. Задолженность признается только при выставлении счета-фактуры. Аналогичная проблема существует при учете денежных средств: согласно российским стандартам счета денежных средств обновляются на основе банковской выписки, а по МСФО – на основе полученного или выданного платежного поручения.
- Прочие проблемы связаны с оценкой материально-производственных запасов. Методы оценки запасов могут отличаться в учете по МСФО и российским стандартам. В идеальном случае система должна обеспечивать учет запасов в двух функциональных валютах для упрощения и повышения эффективности отчетности.
- Возникает также и ряд специфических проблем при настройке операций по счетам дебиторов и кредиторов для учета в двух валютах. Может потребоваться вручную производить дополнительные корректировки в момент соотнесения выставленного счета и полученного платежа. При закрытии счета в одной валюте следует также закрывать его во втором учетном регистре, и в этом момент могут возникать расхождения из-за разных курсов валют, действовавших в момент выставления счета и получения оплаты.
Перечень различий между российским учетом и МСФО, оказывающих существенное влияние на процесс внедрения системы, может быть продолжен и далее. В связи с этим данную сферу необходимо рассматривать как сопряженную с риском и требующую особого внимания со стороны консультантов, которые осуществляют внедрение системы, а также активного участия главного бухгалтера и других специалистов предприятия.
Общие проблемы внедрения и роль консультантов
Список проблем, возникающих в ходе проекта по внедрению системы и после начала ее эксплуатации, не ограничивается описанными выше. У всех проектов по внедрению управленческих информационных систем имеются общие элементы, которые, на наш взгляд, так же нуждаются в кратком анализе.
Управление проектом
Во-первых, хотя внедрение системы и выглядит как задача чисто технического характера, крайне опасно недооценивать значимость человеческого фактора. Воздействие изменений, негативное отношение людей к изменениям и конфликтующие интересы различных групп следует учитывать и оценивать на наиболее ранней стадии с тем, чтобы обеспечить разработку стратегии, которая позволяет преодолеть любые ситуации, препятствующие успешному осуществлению проекта.
Обеспечение достаточно высокой степени участия сотрудников компании-клиента всегда представляет проблему в ходе подобного рода проектов. Какой бы высокой ни была квалификация консультантов, участие ключевых сотрудников самой компании является обязательным. Одна из задач менеджера проекта – контроль за сроками окончания отдельных этапов и организация процесса таким образом, чтобы предотвратить постоянные переносы сроков завершения проекта в связи с окончанием месяца, отчетного года, отпусками, больничными листами, прочими реальными и мнимыми предлогами.
Организация и управление проектом представляет собой сложную задачу, для выполнения которой необходим разносторонний опыт работы не только в технической области, но и в сфере управления персоналом. Принять решение о том, какую стратегию использовать, совсем не просто, учитывая то, что консультанты зачастую оказываются в ситуации, когда им приходится оказывать определенное давление на сотрудников фирмы-клиента, хотя статус им этого не позволяет.
Определение потребностей предприятия
Еще одной важной задачей является определение реальных потребностей предприятия. Очень часто пользователи предъявляют завышенные требования, стремясь автоматизировать и формализовать каждый шаг в новой системе. Если бы проектная группа пошла по данному пути, ей пришлось бы создавать слишком сложную систему, настройка, управление и эксплуатация которой были бы весьма трудной задачей. Поэтому здесь всегда нужен определенный компромисс, который невозможен без глубокого понимания основ функционирования предприятия. Кроме того, до внедрения системы зачастую бывает необходимо провести диагностику предприятия и оптимизацию ключевых бизнес-процессов.
Управление изменениями и контроль за обновлением версий
Впоследствии в ходе проекта следует предусмотреть процедуры управления изменениями, которые обеспечили бы своевременный анализ целесообразности и оценку стоимости каждого изменения в дизайне системы, осуществляемого по запросу пользователей. Часто такие запросы возникают в связи с изменением нормативных требований, пересмотром российских или международных стандартов финансовой отчетности. Иногда в систему приходится вносить массу корректировок даже при незначительном изменении стандартов. Тем не менее, современные управленческие информационные системы обычно отличаются достаточной гибкостью и способны отражать изменения внешних условий.
То же самое относится к установке новых версий системы. Обычно это делается в целях расширения функциональных возможностей системы и корректировки недостатков более ранних версий программного обеспечения. Однако при каждом последующем обновлении проектная группа рискует столкнуться с необходимостью повторной настройки и тестирования параметров системы.
Обучение пользователей
Обучение пользователей является еще одним важным фактором успешной реализации всего проекта. Следует разработать соответствующую стратегию с учетом объема работ и затрат на их проведение. Проектной группе необходимо решить, как организовать весь процесс обучения: для всех сотрудников или только для ключевых пользователей, которые затем обменяются полученными знаниями с остальным персоналом.
Перенос данных
Перенос данных из старой системы в новую – важная задача, имеющая большое значение для успешного осуществления всего проекта. Обычно к моменту внедрения новой системы у предприятия уже накоплены данные о хозяйственных операциях за длительный промежуток времени, которые следует загрузить в новые базы данных. При выполнении данной задачи необходимо найти компромисс между стремлением осуществить как можно более плавный переход на новую систему, которая содержала бы все имеющиеся данные, и обеспечить минимум затрат на ввод такого рода информации. Таким образом, важно определить реальные потребности в отношении начальных данных (их вид, степень детализации, охватываемый период, возможность ограничиться только вводом входящих сальдо).
Кроме того, следует рассмотреть вопрос достоверности данных и их верификации, особенно если раньше в компании не использовалась качественная интегрированная система. В частности, различные отделы могли работать с разными программными продуктами, при этом одни из них являлись стандартными и относительно простыми, а другие могли быть разработаны на самом предприятии. Такая организация работы обычно влечет за собой увеличение объемов документации и необходимость повторного ввода одних и тех же данных в различные системы, что в свою очередь приводит к росту числа ошибок. Кроме того, при переносе данных может потребоваться сбор дополнительной информации, так как новая система способна обеспечить поддержку большего количества системных параметров и главных файлов (например, дополнительные уровни классификации покупателей и поставщиков, несколько пунктов назначения, различные центры калькулирования затрат и т.п.).
После определения требований и объемов работы следует изучить различные подходы к вводу данных. Существуют следующие варианты:
- ввод данных вручную; основные недостатки: более высокая вероятность появления опечаток и более длительный период ввода информации; данный вариант следует использовать в случае незначительного объема информации, когда дешевле ввести ее вручную, чем изменять конфигурацию системы в целях автоматического ввода данных;
- использование функциональных возможностей или специального инструментария обеих систем в области экспортирования / импортирования данных (для старой системы требуется экспортирование, для новой – импортирование); основные проблемы – требуется наличие вышеупомянутых функциональных возможностей и совместимость форматов;
- разработка адаптированных программ, которые обеспечивают загрузку информации либо непосредственно в файлы базы данных (что может быть чрезвычайно рискованным и почти не используется на практике), либо через имитацию ввода информации с клавиатуры.
Какой бы ни был выбран вариант, для его осуществления потребуется координация работы всей проектной группы.
Поддержка системы после запуска в эксплуатацию
После завершения настройки и тестирования системы, а также после обучения всех пользователей остаются еще две задачи – организовать запуск новой системы и обеспечить наличие соответствующих средств поддержки ее функционирования после ухода консультантов.
Существуют два варианта запуска системы: либо параллельная работа вместе со старой системой, либо полный запуск новой системы после того, как «все мосты сожжены», т.е. когда старая система полностью прекращает работу. В первом случае сбой новой системы менее опасен для всего предприятия, однако, будет гораздо труднее приступить к ее полномасштабному использованию. Кроме того, дополнительному давлению подвергаются конечные пользователи, так как им приходится проделывать двойную работу в обеих системах.
Второй вариант может оказаться более рискованным, если не была обеспечена высокая степень надежности работы новой системы. В случае неудачи, если компании придется вернуться к старой системе, вряд ли в скором будущем у нее появится еще одна возможность запуска новой системы. Чувство общего разочарования и неудовлетворенности окажут гораздо более негативное воздействие, чем любые технические проблемы. Для предотвращения подобной ситуации следует провести тестирование системы до начала ее эксплуатации.
И последняя, но отнюдь не менее важная задача заключается в обеспечении поддержки системы после ухода консультантов. Наш опыт показывает, что в самой компании должен быть человек, отвечающий за поддержку и дальнейшее развитие системы. Им может стать новый, специально нанятый специалист, однако в идеале этот человек должен принимать участие в работе проектной группы с самых ранних этапов проекта. Это наиболее оптимальный подход, так как клиенту в будущем не придется целиком и полностью зависеть от консультантов, , как это ни печально для последних.