Программа не заменит человека

- kbrbank

Программа не заменит человека

Неприятности внедрения автоматизированных совокупностей по МСФО. // Игорь Козлов. Новые совокупности денежного учета № 4, апрель 2007 г.

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

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

Это обусловлено тем, что его создание связано с определенными сложностями.

Сначала разглядим неприятности на этапе разработке программы.

Отсутствие квалифицированных кадров.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Помимо этого, в состав команды должны быть включены представители всех трех вышеперечисленных групп экспертов.

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

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

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

Не всегда вероятно досконально обрисовать языком формул все виды расчетов со всеми вероятными вариантами.

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

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

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

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

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

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

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

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

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

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

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

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

Внедрение автоматической совокупности изменения отчетности по русским стандартам в отчетность по МСФО.

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

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

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

К примеру, актив баланса обязан сходиться с пассивом, что нужно машинально контролировать при выгрузке, и при несоблюдении разрешённого равенства выдавать предупреждение либо по большому счету запрещать выгрузку.

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

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

Но с уверенностью возможно заявить, что лишь при заинтересованности всех участников проекта в том, дабы продукт оказался качественный, возможно рассчитывать на успех.

10 профессий, в которых роботы заменят людей уже через 20 лет

Интересные записи

Похожие статьи, которые вам, наверника будут интересны: